Hice vibe coding y monté una app funcional en 40 minutos, y fue glorioso. Luego intenté añadir una segunda funcionalidad y todo se vino abajo como una torre de Jenga. Si has lanzado algo real con un agente de IA, sabes exactamente esta sensación. El vibe coding es increíble para el primer 80% y una pesadilla para la parte que realmente importa.
Déjame definir el término para que no acabemos hablando de cosas distintas. El vibe coding es cuando describes lo que quieres en lenguaje natural, dejas que el agente lo escriba, echas un vistazo al resultado y sigues tirando a golpe de intuición — sin revisión real, sin arquitectura, pura inercia y vibraciones. Es rápido. Es divertido. Y no escala más allá de la demo. Esa es la opinión polémica, y la defenderé.
Por qué la primera hora parece magia
La fase inicial de cualquier proyecto no tiene restricciones. No hay código existente que romper, ni convenciones que respetar, ni usuarios que dependan del comportamiento de ayer. El agente recibe un lienzo en blanco y lo rellena. Por supuesto que va rápido. No le estás pidiendo que sea cuidadoso, le estás pidiendo que genere, y generar es en lo que estos modelos son mejores.
Esto tiene valor real, por cierto. Para un prototipo, un spike, un proof-of-concept desechable, el vibe coding es la herramienta correcta. Lleva la idea a la pantalla, comprueba si vale la pena construirla, y tírala. Hago esto cada semana. Sin apuntes.
El error está en creer que esa velocidad de prototipo se mantiene. No es así.
Dónde se rompe todo
En el momento en que el codebase tiene estado — patrones existentes, datos reales, una funcionalidad de la que alguien depende — el cálculo se invierte. Ahora cada cambio tiene que ser coherente con lo que ya hay. Y el vibe coding no tiene ningún mecanismo para la coherencia, porque nunca miraste con suficiente atención para saber qué significa "coherente".
He visto a un agente, ya tres funcionalidades adentro, inventar su tercera forma diferente de manejar errores de API. No porque sea tonto. Sino porque nadie le dijo que las otras dos existían, y cuando vas a vibras no te das cuenta hasta que algo falla de una manera irritante de rastrear. El codebase se convierte en una excavación arqueológica — seis estilos, cuatro enfoques de gestión de estado, dos librerías de fechas y una función llamada handleStuff que hace autenticación.
Los bugs son la peor parte. Los bugs del vibe-coded se esconden. El código parece correcto — el modelo escribe código plausible y seguro de sí mismo — así que lo revisas por encima, compila, el happy path funciona, sigues adelante. El bug aparece tres funcionalidades después cuando el caso límite finalmente se dispara, y ahora estás depurando código que nunca llegaste a leer. Ni siquiera tienes el contexto de haberlo escrito.
La revisión que te saltaste es la factura que pagarás
Esto es lo que nadie quiere escuchar: la velocidad del vibe coding está en parte tomada a préstamo del futuro. No te estás saltando el trabajo de revisión. Lo estás aplazando, con intereses. Cada diff sin revisar es un pequeño préstamo. La demo se lanza rápido porque pediste muchos préstamos. El producto se paraliza porque los pagos vencen todos a la vez, normalmente en el peor momento.
Por eso los equipos chocan contra un muro hacia la tercera semana de un proyecto hecho a base de vibe coding. Las primeras funcionalidades volaron. Ahora la velocidad cae y nadie sabe por qué. Son los intereses. El codebase no tiene forma, y los codebases sin forma se vuelven cada vez más difíciles de cambiar, no más fáciles.
Lo que hago yo cuando ya es un producto real
Sigo usando el agente para casi todo. Solo dejo de ir a vibras en el momento en que aquello se convierte en un producto. El cambio tiene esta pinta:
- Leo cada diff antes de que llegue al código. No lo escaneo. Lo leo. Si no lo entiendo, no se lanza.
- Mantengo un
CLAUDE.mdo equivalente que fija las convenciones — cómo manejamos los errores, cómo manejamos el estado, qué librerías están aprobadas. El agente lo lee. La coherencia deja de ser cuestión de suerte. - Le hago escribir tests para todo lo que no sea trivial, y los ejecuto. Un test que pasa es la diferencia entre "parece correcto" y "es correcto".
- Trabajo en trozos pequeños y revisables. Una funcionalidad, un diff claro, una revisión. No "construye todo el dashboard" en un único prompt febril.
Nada de esto es lento, exactamente. Es deliberado. El agente sigue escribiendo el código. Yo simplemente he vuelto al bucle como la persona que realmente sabe lo que está pasando.
El encuadre honesto
Aquí hay un comando que ejecuto constantemente cuando me hago cargo de un desastre hecho a base de vibe coding:
git log --oneline -20 && git diff HEAD~5 --stat
Necesito ver qué cambió y cuánto, porque a golpe de vibras nadie lo estaba rastreando. Lo primero que hago en un proyecto de vibe coding es reintroducir la responsabilidad — ante el diff, ante los tests, ante las convenciones.
El vibe coding no es malo. Es una fase. Es la lluvia de ideas, no el manuscrito. Los builders que se queman son los que nunca pasan de ahí — los que tratan el workflow del prototipo como el workflow de producción y se preguntan por qué su app se convirtió en sopa.
Usa las vibras para descubrir qué construir. Luego pon las manos de vuelta en el volante para construirlo de verdad. La demo te querrá de todas formas. El producto solo te querrá si lees el código.