El término vibe coding empezó describiendo una cosa genuina y útil: dejar que un agente escriba código mientras tú diriges por sensación, apenas leyendo el output, persiguiendo una idea a la velocidad de una conversación. Addy Osmani trazó la distinción útil que se me ha quedado, entre ese modo y algo que él llama ingeniería asistida por IA. Los dos usan los mismos modelos y los mismos editores. No son la misma actividad, y confundirlas está detrás de mucho sufrimiento.
Quiero hacer esa línea concreta, porque “ingeniería” puede sonar a reprimenda, como si la respuesta fuera solo ser más serio y escribir más tests. No va de seriedad. Va de una cosa concreta que haces o no haces, y todo lo demás se deriva de ella.
La línea no está donde la gente cree
La gente intenta ubicar la diferencia en los sitios equivocados, y cada sitio equivocado lleva a una mala conclusión.
No son las herramientas. La misma sesión de Cursor puede producir cualquiera de los dos modos. No es la velocidad. La ingeniería asistida por IA no es vibe coding más lento con más ceremonia atornillada, y tratarla así solo hace que odies la ceremonia. Ni siquiera es si escribes tests, porque puedes escribir tests que no demuestran nada y seguir haciendo vibe coding con pasos extra.
La línea es la aceptación. El vibe coding acepta el código generado porque parece funcionar. La ingeniería acepta el código generado porque se ha demostrado que cumple un contrato que definiste. Esa es la distinción entera, y es más pequeña y más afilada de lo que sugiere el marco habitual. Uno confía en el output. El otro lo verifica contra algo enunciado por adelantado.
Todo lo que la gente asocia con los dos modos se deriva de esa única diferencia. El vibe coding se siente rápido y libre porque confiar es más rápido que verificar. La ingeniería se siente más deliberada porque existe un contrato y el código tiene que superarlo. Mismo paso de generación, distinta puerta al final.
Por qué el vibe coding no es el enemigo
No estoy construyendo hacia “vibe coding malo, ingeniería buena”. Ese marco es a la vez incorrecto e inútil.
El vibe coding es el modo correcto para un conjunto grande y legítimo de trabajo. Explorar una idea, montar un prototipo para ver si algo merece la pena, scripts desechables, cualquier cosa donde equivocarse es barato y aprender rápido es el objetivo. En esa zona, pararse a definir contratos y verificar contra ellos es puro sobrecoste. Estarías haciendo ingeniería de algo que estás a punto de borrar, que es su propio tipo de desperdicio. La velocidad de confiar en el output es exactamente lo que quieres cuando lo que está en juego en ese output es casi cero.
El fallo no es el vibe coding. El fallo es el vibe coding pasado de fecha de caducidad: quedarte en el modo de confiar-en-el-output después de que el output empezó a importar. Es la transición exacta que intento trazar al ir del vibe coding a producción. El modo que era correcto para el prototipo se vuelve peligroso para el producto, y nadie te manda una notificación cuando cruzas la línea.
Qué cambia cuando cruzas
En el momento en que el código empieza a importar, lo más barato que puedes añadir no son tests ni tipos. Es un contrato: una declaración, antes de que el agente construya, de qué debe hacer el cambio y cómo reconocerás un resultado correcto. Es el núcleo del desarrollo guiado por especificaciones, y es la cosa más pequeña posible que convierte el vibe coding en ingeniería, porque le da a la aceptación algo contra lo que comprobar.
Con un contrato en su sitio, la verificación deja de ser sensaciones. “Funciona” se convierte en “cumple el contrato, y aquí está la evidencia”. Sin uno, incluso una suite de tests que pasa es solo una sensación más elaborada, porque los tests describen lo que el código resultó hacer en vez de lo que se suponía que hacía. El contrato es lo que le da a la palabra “hecho” algún significado.
También es por eso que el modo de ingeniería es más caro, y por eso ese gasto es el punto. Definir el contrato es trabajo real. Es el trabajo que la IA no eliminó. Generar el código se abarató, así que la actividad escasa y valiosa se movió a decidir qué significa correcto y demostrar que el código lo cumple. En el modo de ingeniería estás haciendo ese trabajo escaso. En el modo vibe te lo saltas, lo que está bien hasta que no.
Los dos modos y la deuda
La diferencia práctica más clara aparece después, en lo que cada modo deja atrás. El vibe coding acumula deuda en tres capas, comprensión, verificación y arquitectura, precisamente porque nada se verificó contra un contrato sobre la marcha. La ingeniería paga un coste pequeño por adelantado, el contrato y la evidencia, y arrastra mucha menos de esa deuda.
Así que la elección entre los modos es en realidad una elección sobre cuándo pagas. El vibe coding lo aplaza todo a un ajuste de cuentas futuro. La ingeniería paga un poco de forma continua. Ninguno es universalmente correcto. En un prototipo, aplazar es correcto. En un producto, la factura aplazada es el colapso de los 90 días con el que todo el mundo acaba topando. Saber en qué modo estás es saber a qué calendario de pagos te apuntaste.
Y explica un miedo del que he escrito en otro sitio. La razón de que la gente acabe con miedo a tocar su propio código casi siempre es que se quedó en modo vibe demasiado tiempo. No hay contrato contra el que comprobar un cambio ni evidencia de que nada funcione, así que cada edición es un salto. El miedo es la experiencia sentida de haber aceptado mucho código sin verificar ninguno.
Sigues siendo tú quien decide
Aquí está la parte que ninguno de los dos modos elimina. Confíes o verifiques, hagas vibe o ingeniería, eres tú quien toma esa decisión, cambio a cambio. El agente no sabe si este código importa. No puede distinguir si estás prototipando o publicando. Ese juicio es tuyo, y es el trabajo de verdad ahora.
Es lo que quiero decir cuando afirmo que tú eres el runtime. El agente genera. Tú decides qué modo pide el momento, defines el contrato cuando hace falta uno, y aguantas la línea de la evidencia cuando importa. La línea entre vibe coding e ingeniería no la dibujan tus herramientas. La dibujas tú, cada vez que decides si “funciona” es suficiente.
Dónde encaja PaellaDoc
La parte difícil de vivir en el lado correcto de esta línea es que el contrato y la evidencia tienen que existir en algún sitio duradero, o el modo de ingeniería se degrada en silencio hasta volver a ser vibe coding. Un contrato en un chat cerrado no es un contrato. Evidencia que no guardaste no es evidencia.
PaellaDoc existe para hacer del modo de ingeniería el camino de menor resistencia: un sitio donde enunciar el contrato antes de que el agente construya, un vínculo de ese contrato al código que lo implementa, y la evidencia de que se cumplió, todo junto en local en vez de repartido. No te impide hacer vibe coding cuando el vibe coding es lo correcto. Hace que cruzar a la ingeniería sea lo bastante barato como para que de verdad lo hagas cuando el código empieza a importar.
Preguntas frecuentes
¿El vibe coding es malo? No. Es el modo correcto para exploración, prototipos y cualquier trabajo donde equivocarse es barato. Solo se vuelve un problema cuando te quedas en él después de que el código empieza a importar, lo que convierte la verificación saltada en riesgo acumulado.
¿Qué separa de verdad el vibe coding de la ingeniería asistida por IA? La aceptación. El vibe coding acepta el código generado porque parece funcionar. La ingeniería lo acepta porque se ha demostrado que cumple un contrato definido por adelantado. Las herramientas, los modelos y la velocidad son los mismos.
¿Tengo que elegir un modo para todo el proyecto? No. El modo es una decisión por cambio. Prototipa una feature por sensaciones y cambia a ingeniería cuando esa feature pase a sostener peso. La habilidad es saber cuál pide el momento.