¿Qué es el vibe coding? Definición de Karpathy, herramientas y la realidad de seguridad explicadas (2026)

En febrero de 2025, el cofundador de OpenAI y antiguo responsable de IA en Tesla Andrej Karpathy publicó una sola frase en X que dio la vuelta al mundo con un término nuevo: vibe coding.

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Un año después, en 2026, el término se sitúa en el centro de un debate polarizado. El propio Karpathy ha propuesto renombrarlo, las empresas observan un repunte de incidentes de seguridad y, sin embargo, para desarrolladores indie, startups y herramientas internas se ha asentado como un estilo estándar de programar. Este artículo recorre la definición y el debate más reciente apoyándose en fuentes oficiales y datos del sector.

1. ¿Qué es el vibe coding?

El vibe coding es un estilo de programación construido sobre la idea de hablar de lo que el código debería hacer, en lugar de escribirlo o leerlo. Le describes a una IA (Claude, GPT, Cursor Composer, etc.) lo que quieres en lenguaje natural, lo ejecutas y le pides correcciones sin leer el código generado.

Hay tres ideas en el núcleo:

• Soltar el apego al código: abandona la sensación de propiedad sobre "el código que escribí".
• Si funciona, vale: una vez que arranca, entender las tripas viene después, o nunca.
• Conducirlo por conversación: cuando aparecen bugs o errores, basta con decirle a la IA "arréglalo". Pegar el stack trace es suficiente.

Un ejemplo típico: un desarrollador indie pide "construye un Tetris en Pygame" → Claude devuelve 500 líneas de código → lo ejecuta → la pieza no cae, así que dice "los bloques no rotan" → recibe una versión corregida. Listo, sin escribir una sola línea propia.

2. Karpathy lo acuñó y un año después propuso renombrarlo

La expresión "vibe coding" fue acuñada por Andrej Karpathy en X (antes Twitter) en febrero de 2025. La utilizó para describir la experiencia de combinar Cursor Composer (que entonces corría con Sonnet) y SuperWhisper (entrada por voz) para construir aplicaciones casi enteramente hablando.

Lo que ocurrió a lo largo del año siguiente:

• Agosto de 2025: los principales LLM superaron el 60 % en SWE-bench y el vibe coding empezó a sentirse real.
• Diciembre de 2025: Karpathy informó de un giro drástico en su propio flujo de trabajo: 80 % escrito a mano en noviembre, 80 % generado por IA en diciembre.
• Febrero de 2026: Karpathy propuso abandonar el nombre "vibe coding" y sustituirlo por "agentic engineering". La distinción: vibe = decir lo que quieres y aceptar lo que venga; agentic engineering = diseñar el sistema, especificar restricciones y usar la IA para acelerar una implementación que ya has pensado.

De ahí la posición rara del vibe coding: el término que popularizó el concepto, pero la persona que lo creó ya no lo recomienda. El mercado lo sigue usando igualmente, porque ninguna otra palabra captura el mismo matiz de "casual" y "liberado de leer código".

3. El flujo de trabajo típico

Basta de abstracción: este es el bucle real que se ejecuta.

4. Las herramientas líderes

A mayo de 2026, estas son las herramientas en las que el estilo vibe coding funciona especialmente bien.

Si no eres ingeniero y lo usas para aprender o prototipar, mira Lovable, v0 y Bolt.new. Si eres ingeniero profesional trabajando sobre código existente, los referentes actuales son Claude Code, Cursor y Codex CLI.

5. El lado oscuro: la realidad de seguridad y calidad

"El vibe coding sienta de maravilla. Llevarlo a producción es otra historia." Esa brecha se hizo imposible de ignorar en 2026, y los números de terceros no perdonan.

Esto no es una historia de "la IA es mala": es un problema estructural de un estilo de desarrollo que empuja a producción código sin leer. La misma IA, con humanos que añaden revisión y verificación, registra tasas de incidentes drásticamente más bajas.

6. Vibe vs agentic engineering

La propuesta de renombrado de Karpathy en 2026 vale la pena entenderla: aclara la decisión operativa que hay que tomar.

Puedes usar las mismas herramientas (Claude Code, Cursor) y convertirlas en vibe coding o agentic engineering según la postura que adoptes. Lo importante es saber conscientemente "¿en qué modo estoy ahora mismo?" y cambiar de forma deliberada.

7. "Vibe & Verify": las reglas para ponerlo en práctica

La buena práctica que se está estandarizando en 2026 es el "Vibe & Verify": conservar la ligereza de dejar que la IA escriba, pero insertar siempre verificación al final.

(1) Cambia de modo según la apuesta

• Apuesta baja (herramientas personales, aprendizaje, scripts): vibe completo, sin problema.
• Apuesta media (herramientas internas, MVPs, prototipos desechables): vibe + un smoke test + un escaneo rápido de seguridad.
• Apuesta alta (producción, datos de cliente, cualquier cosa de cara al público): el modo agentic engineering es obligatorio. Aunque lo hayas escrito en modo vibe, no hagas push sin revisión humana + escaneos automáticos de seguridad + tests añadidos.

(2) Tres cosas que siempre hay que hacer con código generado por IA

1. Mira el diff: saltarse cada línea es aceptable para código desechable. Para código compartido, al menos echa un vistazo al diff.
2. Pasa un linter de seguridad: semgrep, bandit, truffleHog, etc. Las comprobaciones mecánicas de secretos, SSRF y XSS son innegociables.
3. Haz que la IA escriba tests: añade siempre "ahora escribe tests para esto" a la misma IA. Código sin tests no cuenta ni siquiera como vibe coding.

(3) No pierdas la habilidad de leer código

Si te acostumbras demasiado al vibe coding, en cuanto la IA se equivoque o te toque retomar código de otra persona, descubrirás que no puedes leerlo. El propio Karpathy ha insistido varias veces en que la capacidad de entender el código generado por IA al detalle importa. Incluso vibeando, construye el hábito de detenerte de vez en cuando para leer realmente el código; a largo plazo, ahí se forma la diferencia de habilidad.

(4) No vibees con tus secretos

API keys, contraseñas de bases de datos, tokens de acceso a producción: nunca se los entregues a la IA ni dejes que los escriba en el código. La disciplina de .env + .gitignore + variables de entorno no es negociable, vibe o no. Esas 400 exposiciones que encontró Escape.tech eran exactamente los casos en los que esta higiene básica falló.

8. Quién debería hacer vibe coding, en qué y hasta dónde

Resumen

• El vibe coding es el estilo "deja que la IA se encargue sin leer el código" propuesto por Karpathy en febrero de 2025.
• El propio Karpathy ha propuesto desde entonces renombrarlo como "agentic engineering" en 2026: el trabajo de producción necesita diseño, restricciones y juicio humano.
• Herramientas principales: Claude Code, Cursor Composer, Codex CLI, Lovable, v0, Bolt.new, Devin.
• Realidad de seguridad: entre el 40 % y el 62 % del código de IA contiene vulnerabilidades, se encontró SSRF en los 5 grandes agentes y los CVEs crecieron 6x en tres meses.
• Vibe & Verify: cambia de modo según la apuesta, mira los diffs, pasa escaneos de seguridad, haz que la IA escriba tests, no vibees con tus secretos.
• No abandones "la capacidad de leer código": cuanto más vibees, más se convierte en diferenciador a largo plazo el detenerse de vez en cuando a entender qué está pasando.

FAQ

Q1. Si Karpathy lo renombró, ¿es "vibe coding" un término ya muerto?

Se sigue usando ampliamente en el mercado, porque ninguna otra expresión captura el matiz de "déjaselo a la IA con tranquilidad". El movimiento pragmático es tratarlos como complementarios: "modo de exploración casual = vibe coding", "modo de producción = agentic engineering".

Q2. ¿Está bien que un principiante empiece con vibe coding?

Sí, pero lee el código también. Si solo vibes, no tendrás criterio al que recurrir cuando la IA se equivoque. Un camino realista es usar la alegría de "tengo código que funciona" como motivación al principio y, gradualmente, subir la proporción de tiempo que dedicas a entender de verdad el código.

Q3. ¿Cómo le vendo el vibe coding a mi jefe en el trabajo?

Lleva tres cosas: (1) reglas operativas de Vibe & Verify, (2) escaneo de seguridad integrado en CI y (3) las code reviews siguen siendo tan estrictas como antes. En cuanto puedas decir con claridad "subimos la velocidad sin bajar las defensas", la mayoría de las organizaciones dará el visto bueno.

Q4. ¿En qué se diferencia el vibe coding de la "programación asistida por IA" anterior (Copilot, etc.)?

La diferencia está en quién lleva el volante. Copilot es un modelo de "pair programming": el humano escribe código mientras la IA lo completa. El vibe coding hace de la IA el actor principal, con el humano solo conversando y confirmando. La frontera es difusa y, en la práctica, muchos desarrolladores se mueven entre ambos.

Q5. ¿Con qué herramienta debería empezar?

Para desarrollo indie o aprendizaje, prueba Lovable, Bolt.new o v0 (solo navegador, sin nada que instalar). Para desarrollo de software en serio, prueba Claude Code o Cursor: Claude Code es CLI, Cursor está integrado en el IDE; elige por gusto. La elección de Karpathy es Cursor Composer.

Q6. ¿Qué pasa con los derechos de autor del código escrito por IA?

A mayo de 2026, la base tanto en EE. UU. como en Japón es que el código generado únicamente por IA no está protegido por derechos de autor. El código que un humano ha modificado o curado de forma sustancial sí puede llegar a ser protegible. El mayor riesgo de uso comercial es la contaminación de licencias: que la IA reemita en tu código fuente código bajo GPL u otras licencias; añade un comprobador de licencias a tu CI.

Q7. ¿El vibe coding "le quitará el trabajo a los ingenieros"?

El precio de mercado de "ingenieros que solo escriben código" va a la baja. Por otro lado, el valor del diseño de specs, las decisiones de arquitectura, la seguridad y la operación de producción ha, si acaso, subido por la difusión del vibe coding. La gente capaz de "leer, juzgar y arreglar" el gran volumen de código que produce la IA escasea a mayo de 2026.