Vibe coding es describir lo que quieres en lenguaje normal y dejar que un modelo escriba el código, sin leer la mayor parte. Guías por el resultado: lo ejecutas, ves si te encaja, pides cambios, lo vuelves a ejecutar. El código es el medio, el comportamiento es el objetivo, y casi nunca miras debajo del capó.
Andrej Karpathy le puso nombre a principios de 2025, describiendo una forma de trabajar en la que “te entregas del todo a las vibes” y te olvidas de que el código existe. Lo dijo en parte como broma sobre proyectos de fin de semana. El término cuajó porque describía algo que mucha gente ya hacía y no tenía palabra para nombrarlo.
Vale la pena definirlo con claridad, porque el término se usa de dos maneras: como medalla por quien publica cosas reales rápido, y como insulto por quien piensa que todo es una temeridad. Ambos se pierden la línea de verdad.
Qué es el vibe coding en realidad
Quítale el misticismo y es un bucle:
- Describes un cambio o una feature en lenguaje natural.
- Un agente escribe o edita el código.
- Lo ejecutas y miras el resultado, no el diff.
- Describes qué está mal o qué toca después.
- Repites.
El rasgo que lo define es el paso 3. En el desarrollo clásico lees el código para saber que está bien. En vibe coding lees el comportamiento. Esa única sustitución es lo que lo hace rápido, y es también toda la fuente de sus límites.
Esto es distinto de la ingeniería asistida por IA, donde sigues leyendo y siendo dueño del diff y el modelo es un acelerador. El vibe coding delega también la lectura. La distinción no es esnobismo: decide para qué es seguro usar el resultado.
Para qué es genuinamente bueno
No vengo a despreciarlo. La técnica es real y se gana su sitio:
Prototipos. Cuando el objetivo es ver si una idea encaja, el vibe coding te da una respuesta clicable en una tarde en vez de en una semana. Eso es un superpoder legítimo.
Herramientas de usar y tirar. Un script que ejecutarás una vez, una utilidad interna para ti, algo que no necesita sobrevivir al contacto con otra gente. Que la corrección caduque mañana da igual cuando terminas hoy.
Aprender viendo. Ver cómo una idea se convierte en una pantalla que funciona te enseña más sobre si vale la pena construirla que cualquier cantidad de planificación.
El primer borrador de algo real. Incluso cosas que serán productos suelen empezar aquí, y deben. El error no es empezar con vibe coding. Es no darte cuenta de cuándo saliste de su terreno.
Dónde deja de funcionar
El límite no es un nivel de dificultad. Es un cambio en lo que necesitas del resultado. El vibe coding deja de funcionar en cuanto el código tiene que sobrevivir a cosas que una demo nunca prueba:
Cuando tiene que seguir funcionando mientras lo cambias. Los comportamientos de un prototipo funcionaron una vez. Los de un producto tienen que seguir funcionando a través de cada cambio futuro, lo que significa que algo tiene que atraparlos cuando un cambio los rompe. El vibe coding no produce esa red.
Cuando otra persona depende de ello. En cuanto el dinero, los datos o el tiempo de un usuario real dependen de la app, “funcionó cuando le di al clic” deja de bastar. Necesitas saber que funciona, no sentirlo. Un build en verde no es una feature correcta, y “corrió en mi pantalla” es aún más débil que un build en verde.
Cuando crece más de lo que te cabe en la cabeza. Por debajo de cierto tamaño puedes tener la app entera en memoria y guiar por vibes. Pasado ese punto no puedes, y como nunca leíste el código, ahora eres dueño de un software que no sabes navegar. Ese es el ajuste de cuentas que la mayoría de apps vibe-coded viven hacia el mes 3.
Cuando las features empiezan a chocar. Cada feature se generó asumiendo que el resto de la app se queda quieta. Junta suficientes y las nuevas empiezan a romper las viejas, porque nada obligó a que la asunción se cumpliera.
Ninguna de estas significa que la técnica fallara. Significan que el prototipo tuvo tanto éxito que dejó de ser un prototipo. Ese es el buen problema, y tiene nombre: el prototipo se convirtió en el producto, y pasó antes de que decidieras dejarlo.
Por qué vale la pena deshacer la confusión
Esto importa porque la gente discute sobre el vibe coding como si fuera una sola cosa que es buena o mala. No lo es. Es una herramienta con una forma, y la forma es justo esta: convierte lenguaje natural en comportamiento que funciona a gran velocidad, a cambio de que tú no sepas cómo se sostiene ese comportamiento.
Para un prototipo, ese trato es una ganga. Quieres velocidad y las tripas te dan igual, porque todo el trabajo del prototipo es responder una pregunta y luego quitarse de en medio. Para un producto, el mismo trato es un veneno de acción lenta. Sigues recibiendo la velocidad por adelantado, pero ahora las tripas que nunca miraste son lo que tienes que mantener, y no puedes mantener lo que nunca viste.
Así que la técnica no es buena ni mala. Está bien o mal aplicada. Aplicada a algo de usar y tirar, roza la magia. Aplicada a algo de lo que depende gente, sin devolver nunca la estructura, es un préstamo a alto interés que vence, de forma fiable, un par de meses después.
Qué aspecto tiene “pasada la línea” en la práctica
En concreto, sabes que cruzaste la línea cuando tu relación con el código cambia. En terreno de prototipo, pides un cambio y aceptas lo que venga, porque la única prueba es si se ve bien al ejecutarlo. Pasada la línea, empiezas a necesitar saber cosas que no puedes ver: ¿este cambio rompió lo que publiqué la semana pasada?, ¿este número es correcto o solo plausible?, ¿por qué lo hizo así? Las preguntas que el código no puede responder son la señal de que el vibe coding te ha llevado tan lejos como puede.
Eso no es un fracaso y no es motivo para sentirte tonto. Es el resultado predecible de que la técnica funcione. El error está solo en no darse cuenta, y seguir añadiendo features por vibes sobre una base que nadie entiende, que es como un arranque rápido se convierte en una app imposible de cambiar hacia el mes 3.
La línea, en una frase
El vibe coding vale hasta que algo tiene que ser cierto sobre tu código que no puedes verificar personalmente haciendo clic. En esa línea no necesitas abandonar la app ni reescribirla. Necesitas devolver la estructura que un prototipo se salta: un mapa legible, una spec escrita, una red de seguridad. Ese cruce es una disciplina entera de por sí, y despliego la ruta completa en de vibe coding a producción.
Usa el vibe coding para lo que es bueno sin pedir perdón. Solo vigila la línea, porque llega en silencio, y el coste de no verla se paga después, con intereses.
Preguntas frecuentes
¿Quién acuñó el término vibe coding? Andrej Karpathy, a principios de 2025, describiendo una forma de construir en la que te apoyas en el modelo y dejas de seguir el propio código. Le puso nombre a una práctica que mucha gente ya hacía.
¿El vibe coding es malo? No. Es excelente para prototipos, herramientas de usar y tirar y primeros borradores. Solo se vuelve un problema cuando su resultado se usa como si fuera software de producción, sin la estructura que producción exige.
¿Cuál es la diferencia entre vibe coding e ingeniería asistida por IA? En el vibe coding guías por el comportamiento y no lees el código. En la ingeniería asistida por IA sigues leyendo y siendo dueño del diff. La diferencia decide si es seguro depender del resultado.