La tesis en una frase: generar una app «a vibras» —describes lo que quieres y la IA te escribe el código— es maravilloso para prototipar y un desastre para gobernar en producción. No porque el código salga mal: hoy sale sorprendentemente bien. Es porque una app viva no es el código que se ve en la demo; es todo lo que no se ve —los tests que avisan cuando algo se rompe, la observabilidad que te dice por qué, la seguridad que impide que un cliente vea los datos de otro, y una persona que responde cuando falla a las tres de la mañana—. Eso es el 70% aburrido, y es justo lo que el vibe coding no te da con el mismo gesto con el que te da la pantalla bonita.
Qué es el vibe coding en producción y por qué engaña tanto
El término lo popularizó Andrej Karpathy a principios de 2025 para describir algo que ya hacíamos todos: dejarte llevar, describirle a la IA lo que quieres y aceptar el código que devuelve sin leerlo línea a línea. Y funciona: en una tarde tienes una aplicación que arranca, que hace login, que guarda cosas en una base de datos y que enseñas en una reunión y todo el mundo aplaude. El problema no es esa tarde. El problema es la conclusión que casi todo el mundo saca de esa tarde: «si esto lo he montado en una tarde, el sistema entero está a una semana». No lo está. Lo que has montado es la parte que se ve, y la parte que se ve es la barata.
Es el mismo espejismo de siempre, con ropa nueva. Una demo que funciona con datos limpios, un solo usuario y cero tráfico real no dice nada sobre lo que pasa cuando entran mil personas, la mitad de los datos vienen a medias y alguien intenta colarse donde no debe. La demo es una promesa; producción es el cobro de esa promesa. Y entre una y otra está el trabajo del que nadie habla en la llamada de venta porque no luce en una pantalla.
Lo que el vibe coding no genera (y es lo que separa la demo del sistema)
No es que la IA escriba código flojo. Es que un sistema en producción es mucho más que código, y esas otras capas no salen de un prompt bonito. Estas son las que faltan casi siempre:
- Tests que avisan antes que el cliente. El código generado hace lo que le pediste el día que lo pediste. Nadie garantiza que lo siga haciendo cuando toques otra cosa dentro de tres semanas. Sin una red de tests, cada cambio es una apuesta y el que descubre que rompiste algo es tu usuario.
- Observabilidad: saber qué pasa cuando pasa. En la demo, si algo falla, lo ves en tu pantalla. En producción, falla en el móvil de un cliente a 800 km y tú no te enteras salvo que hayas montado logs, métricas y alertas. Sin eso, tu primera fuente de monitorización es un correo enfadado.
- Seguridad y aislamiento de datos. El vibe coding te monta el login; lo que rara vez te monta bien es que el usuario A no pueda, tocando la URL, ver los datos del usuario B. Los permisos, el aislamiento entre clientes y el manejo de datos personales son precisamente donde una app improvisada se convierte en una brecha.
- Un dueño y un proceso. Un sistema vivo necesita quien lo despliegue con criterio, quien decida qué se toca y qué no, y quien esté cuando se caiga. El código sin dueño no es un sistema: es una bomba de relojería que funciona hasta que deja de hacerlo y nadie sabe por qué.
Cada uno de estos puntos es invisible en la demo y determinante en producción. Y ninguno se arregla con un prompt mejor: se construye con oficio, que es justo lo que el vibe coding te tienta a saltarte porque «ya funciona».
Entonces, ¿el vibe coding no sirve para nada? Al contrario
Sirve, y mucho, si lo pones en el sitio correcto. Como herramienta de prototipado es de lo mejor que ha llegado en años: valida una idea en una tarde en vez de en dos semanas, te deja enseñar algo tocable en una reunión, y descarta lo que no tiene sentido antes de gastar un euro en construirlo bien. El error no es usar vibe coding; el error es confundir el prototipo con el producto y mandar a producción lo que nació para tirar a la basura.
| Vibe coding es genial para | Y peligroso para |
|---|---|
| Validar una idea antes de invertir | Guardar datos reales de clientes |
| Prototipos internos y demos | Cualquier cosa con usuarios de fuera |
| Explorar cómo se sentiría una función | Procesos de los que depende el negocio |
| Aprender y hacer pruebas rápidas | Nada que tenga que aguantar un lunes por la mañana |
La regla es simple: usa el vibe coding para decidir qué construir, no para construirlo. El prototipo te dice si la idea merece la pena; a partir de ahí, lo que aguanta en producción se levanta con lo aburrido —el mismo oficio que hace falta para automatizar un proceso del negocio sin que se rompa a la primera o para poner un agente de IA a funcionar de verdad dentro de una empresa—. Ese trabajo no es más lento por capricho: es lo que separa una demo aplaudida de un sistema que sigue en pie el martes.
Qué hacer con un prototipo que funciona
Si generaste algo «a vibras» y de verdad resuelve un dolor, la buena noticia es que ya tienes lo más difícil: la certeza de que la idea vale. Lo que viene después no es reescribirlo por gusto, es darle lo que le falta para vivir fuera de tu pantalla —red de tests, monitorización, seguridad, despliegue con criterio y alguien que responda—. Es la parte que tratamos como lo que es, infraestructura, en la infraestructura de IA para empresa: coger lo que valida el prototipo y dejarlo funcionando sin que dependa de que nadie lo mire.
Así que sí al vibe coding —para prototipar, para validar, para descartar rápido—. Y no al vibe coding en producción, no porque la IA escriba mal, sino porque producción es el 70% que la IA no te genera con el prompt: los tests, la observabilidad, la seguridad y el dueño. La IA no se presenta en una demo con datos de mentira. Se implementa sobre lo real, y lo real exige lo aburrido. Ese es el trabajo, y es justo el que no se ve.