¿Qué es el Vibe Coding, realmente?

El término "vibe coding" se propagó rápidamente en 2024-2025 porque nombra algo que muchos desarrolladores ya estaban haciendo en silencio: describir lo que quieren en inglés plano a un modelo como GPT-4, Claude, o una herramienta como Cursor o GitHub Copilot, y dejar que genere la mayor parte del código real. El programador se mantiene en el ciclo, pero el ciclo se ve diferente del código tradicional.

La definición real

Andrej Karpathy acuñó la frase, describiendo un flujo de trabajo donde "cedes completamente a las vibes" — haces un prompt, aceptas sugerencias, ejecutas el código, ves qué se rompe, y haces prompt de nuevo. No estás leyendo cada diff línea por línea. Estás navegando por resultado: ¿la app hace lo que se supone?, ¿pasa el test?, ¿se renderiza la página correctamente?. La habilidad se desplaza de escribir sintaxis a describir la intención claramente y reconocer cuándo la salida es incorrecta.

Esto es diferente de simplemente usar autocompletar. Las sugerencias inline estilo Copilot aún asumen que estás escribiendo la función tú mismo con ayuda para terminar líneas. Vibe coding asume que el modelo escribe la función, el archivo, a veces toda la característica, y estás revisando y redirigiendo en lugar de crear desde cero.

Cómo se ve una sesión real

Un ciclo típico de vibe coding con una herramienta como Cursor o Agent mode de Replit es algo así:

1. Prompt: "Añade un rate limiter a este API de Express, 100 requests por 15 minutos por IP, devuelve 429 con un cuerpo de error JSON."
2. El modelo edita middleware/rateLimit.js, lo conecta en app.js, tal vez trae express-rate-limit.
3. Ejecutas npm test o golpeas el endpoint con curl en un bucle para verificar que el 429 dispare.
4. Algo no está bien — el limiter se reinicia en cada deploy porque está en memoria. Lo dices.
5. El modelo intercambia por un store respaldado por Redis, añade la dependencia ioredis, actualiza el archivo docker-compose.
6. Vuelves a testear, funciona, haces commit.

Ninguna línea de ese middleware fue escrita a mano. Pero seis o siete decisiones de juicio fueron tomadas por un humano: cuál debería ser el límite, que el almacenamiento en memoria era incorrecto para producción, que el archivo docker-compose también necesitaba actualización.

Donde funciona bien

Vibe coding es fuerte para trabajo pesado de boilerplate: endpoints CRUD, validación de formularios, scaffolding de tests, archivos de config, código pegante entre dos APIs que ya entiendes. También es bueno para prototipar — crear una demo funcional de una idea en una hora en lugar de un día, y luego decidir si vale la pena construirla correctamente.

Es genuinamente rápido para devs individuales y equipos pequeños enviando herramientas internas o MVPs donde el costo de un bug es bajo y la velocidad de iteración importa más que la pureza arquitectónica.

Donde se desmorona

El modo de falla que la gente no habla lo suficiente: los modelos producen código que se ejecuta pero es sutilmente incorrecto de formas que no aparecen hasta después. Una query SQL generada podría funcionar para el camino feliz pero ser vulnerable a inyección porque la concatenación de strings se veía bien al modelo. Una verificación de auth generada podría pasar tests pero saltar una verificación de rol en una ruta. Si no estás leyendo el código, no lo vas a detectar — solo vas a ver los tests pasar y lo enviarás.

Esto importa más en código sensible a seguridad que casi en ningún otro lado. Simon Willison y otros han señalado que proyectos vibe-coded con datos de usuarios reales necesitan el mismo rigor de revisión que cualquier otro código, argumentablemente más, porque la persona que lo "escribió" podría no ser capaz de explicar qué hace línea por línea.

Sistemas complejos con mucho estado implícito — concurrencia, transacciones distribuidas, cualquier cosa con bugs sutiles de timing — también son un mal ajuste. Los modelos tienden a generar código que se ve plausible para estos casos que falla de formas difíciles de depurar precisamente porque nadie, humano o modelo, modeló completamente los casos extremos de antemano.

La habilidad que realmente importa ahora

Si estás haciendo vibe coding, la habilidad valiosa no es velocidad de escritura, es especificación. Los prompts vagos generan código vago y buggy. Los prompts específicos — con nombres exactos de librerías, expectativas de manejo de errores, y casos extremos llamados — generan mucha mejor salida. La segunda habilidad más valiosa es leer código lo suficientemente rápido para detectar qué está mal, lo que significa que aún necesitas entender el lenguaje y el dominio aunque no estés escribiendo cada carácter.

Trata el código generado por IA como tratarías un pull request de un dev junior que es rápido pero ocasionalmente demasiado confiado: útil, a menudo correcto, pero vale la pena una revisión real antes de que toque producción.

¿Quieres profundizar en escribir código con herramientas de IA sin perder el control de la calidad? Revisa los segmentos de IA y Python de Korra Studio para walkthroughs prácticos.