El vibe coding consiste en describir en lenguaje natural lo que quieres y aceptar lo que produzca el modelo, sin leerlo con atención. Para un prototipo, un script o una herramienta hecha en una tarde, es una forma de trabajar realmente buena. Yo la uso así.
El problema empieza cuando eso que hiciste con vibe coding pasa a producción y empieza a guardar datos de otras personas. No porque el código sea malo —a menudo es limpio, idiomático y está bien nombrado—. El problema es lo que nadie escribió.
Un modelo responde a la pregunta que le hiciste
Pides un formulario de reservas y obtienes un formulario de reservas. Validará el correo. Probablemente quedará mejor que el que yo habría escrito a mano.
Lo que no hará es plantearte las preguntas que deciden si eso sobrevive al contacto con usuarios reales. ¿Qué pasa si dos personas reservan la última plaza en el mismo segundo? ¿Qué pasa si la pasarela de pago expira después de cobrar pero antes de que tu código se entere? ¿Quién puede ver esta reserva: el cliente, cualquier usuario autenticado, cualquiera con el enlace? Cuando el cliente pide borrar sus datos, ¿qué más hay que borrar con ellos y qué hay que conservar por ley?
No son preguntas de programación. Son decisiones sobre tu negocio, y el modelo no puede tomarlas porque nunca le han contado los hechos que necesitaría. Produce algo plausible para cada una, en silencio, y sigue adelante. El código compila. El formulario funciona cuando lo pruebas. La decisión sigue sin tomarla nadie.
La demo siempre funciona
Esta es la trampa concreta, y también pilla a gente con experiencia.
Una funcionalidad hecha con vibe coding se prueba como se construyó: una persona, un navegador, un único camino feliz, sin carga y sin adversario. En esas condiciones pasa casi cualquier cosa. Los fallos viven exactamente en las condiciones que no se te ocurrió crear: concurrencia, fallo parcial, entrada hostil, el segundo cliente, la fila diez mil, el usuario que ya no tiene sesión pero cuyo token sigue funcionando.
Así que el ciclo de retroalimentación te miente. Publicas, funciona, publicas otra vez más rápido. La confianza crece justo mientras crece la superficie sin examinar. Nada te avisa hasta que algo lo hace, en público.
Seis cosas que faltan sistemáticamente
La autorización, frente a la autenticación. Los modelos son buenos con el login. Son mucho más flojos con «este usuario puede leer exactamente esta fila». La vulnerabilidad más frecuente del vibe coding, con diferencia, es un endpoint que comprueba que has iniciado sesión y nunca comprueba quién eres.
Todo lo que debe ser correcto bajo concurrencia. Inventario, reservas de asientos, números de factura, saldos. Código evidentemente correcto leído de arriba abajo suele estar mal cuando se ejecutan dos copias a la vez.
El modo de fallo de cada llamada externa. Todo tercero del que dependes estará caído en algún momento. Si eso debe detener a tu cliente es una decisión de negocio. El código generado la toma por accidente, normalmente rompiéndose.
Datos que no puedes permitirte perder. Migraciones que eliminan columnas, borrados sin borrado lógico, ninguna copia de seguridad que hayas restaurado de verdad. Nadie se da cuenta hasta el día en que importa, y ese día es irrecuperable, no incómodo.
El back office. El vibe coding produce las pantallas que describiste. Describiste las de cara al cliente, porque son las que te imaginas. Después tu equipo vive ocho horas al día en lo que quedó.
La coherencia entre funcionalidades. Cada sesión empieza de cero. Diez funcionalidades construidas en diez sesiones te dan diez convenciones, tres formas de tratar las fechas, dos patrones de autenticación y ningún vocabulario común. Por separado, bien. Como sistema, imposible de mantener, incluso para el siguiente modelo al que se lo pongas delante.
Lo que esto cuesta realmente
El argumento a favor del vibe coding es la velocidad, y la velocidad es real. Lo que aplaza es el coste de entender, y ese coste no desaparece: lo paga más tarde quien tenga que cambiar el sistema.
Cambiar software con seguridad exige alguien capaz de predecir qué romperá un cambio. Esa persona construye su modelo del sistema tomando las decisiones. Si nadie tomó las decisiones, nadie tiene el modelo, y cada cambio posterior es una conjetura con un despliegue adjunto.
Me llaman a estos proyectos con regularidad. El rescate casi nunca es reescribir: el código suele ser aprovechable. Lo que lleva tiempo es reconstruir la intención: leer cada camino para deducir qué debía hacer el sistema, porque no me lo puede decir nadie, incluida la persona que lo publicó.
Lo que pienso de verdad
La IA es la mayor ganancia de productividad que ha visto mi oficio y no trabajaría sin ella. Es un instrumento excelente en manos de alguien que sabe leer su resultado con criterio y sabe qué preguntas no se hicieron.
No sustituye a esa persona. La hace más rápida. El criterio sobre qué no puede equivocarse nunca en tu sistema no es una tarea de programación, y es justo la parte por la que estás pagando.
Úsala para prototipos, scripts internos, cosas desechables, el primer borrador de cualquier cosa. Para el sistema del que vive tu negocio, ten a alguien que lo entienda de principio a fin, lo haya escrito o lo haya revisado línea a línea.