Ingeniería asistida por IA, no vibe coding: la diferencia que importa

Vibe coding, un término que se extendió en 2025, significa describirle a una IA lo que quieres, aceptar lo que produzca, e iterar por instinto hasta que el resultado se vea bien. Es una forma legítima de explorar una idea. Es rápido, barato y genuinamente divertido. Lo que no es, es ingeniería, porque nada en el circuito verifica que el software se comporte correctamente, se mantenga seguro, o se pueda cambiar de forma segura el mes que viene. El resultado se juzga a ojo, y el proceso no deja registro de qué cambió, por qué, o si alguien lo comprobó.

La ingeniería asistida por IA conserva la velocidad y elimina la conjetura. La IA sigue escribiendo el código, pero cada cambio cae dentro de una disciplina de entrega: se versiona en una rama, se verifica contra políticas, se ejercita con tests automatizados, se analiza y sondea por problemas de seguridad, y se despliega a través de un pipeline controlado con una ruta de rollback. Un humano aprueba los cambios que llevan consecuencias, y un registro de auditoría registra que lo hizo. El prompt es el mismo. Todo lo que pasa después del prompt es distinto.

La distinción no es académica. Determina si lo que construiste puede contener datos de clientes, pasar una revisión de seguridad, sobrevivir a que su autor se vaya, o entregarse a un segundo equipo. Si la respuesta a cualquiera de esas necesita ser sí, el modo de construcción, no el modelo que construye, es lo que lo decide.

El término empezó como un cumplido, una forma de nombrar lo sin esfuerzo que se había vuelto la generación, y se convirtió en una etiqueta de advertencia cuando la primera ola de apps construidas con IA se encontró con usuarios reales. Nada en la advertencia es anti-IA. Los modelos no son el problema; el sistema faltante alrededor de ellos sí lo es, y el mismo modelo colocado en un circuito de entrega gobernado produce software que un negocio puede respaldar. Por eso el argumento aquí es sobre arquitectura de proceso, no elección de modelo, y por qué aplica sin importar qué IA de qué proveedor prefieras. También aplica en cualquier tamaño: una startup de dos personas puede hacer vibe coding responsablemente sabiendo de qué lado de la línea está; un banco no puede permitirse no saberlo.

La mayoría de equipos se encuentran con este problema en el momento de la entrega. Alguien en marketing, operaciones o producto hace vibe coding de una herramienta que funciona lo bastante bien como para que la gente empiece a depender de ella. Luego necesita SSO. Luego almacena algo personal. Luego un director pregunta quién revisa los cambios, y la respuesta honesta es nadie. En ese punto las opciones son feas: reconstruirla adecuadamente, adoptarla tal cual y heredar riesgo desconocido, o matar una herramienta que la gente ya usa.

El coste se manifiesta en tres libros. Primero, retrabajo: los prototipos que no pueden graduarse se reconstruyen desde cero, lo que significa que la vía rápida fue en realidad la vía lenta. Segundo, exposición de seguridad: el código generado sin revisar va a producción con los patrones de acceso y dependencias que el modelo eligió, y nadie puede decir qué hay dentro. Tercero, cuellos de botella de revisión: cuando la IA multiplica el volumen de cambio pero la capacidad de revisión y prueba se mantiene plana, o la publicación se ralentiza al ritmo antiguo o el escrutinio baja en silencio. Ninguno es el resultado por el que nadie compró una herramienta de IA.

También hay un coste organizacional que rara vez llega a la presentación: la confianza. La primera herramienta de vibe coding que corrompe datos o filtra un registro hace más difícil de aprobar cada futura propuesta construida con IA. Los equipos que establecen disciplina temprano conservan su permiso para moverse rápido. Los equipos que se la saltan suelen tener un incidente, luego una moratoria.

Si lideras ingeniería, la versión más aguda del dolor es la asimetría de la culpa. El negocio celebra la velocidad de las herramientas construidas con IA justo hasta que una falla, y el fallo cae en ingeniería, incluso cuando ingeniería nunca vio la herramienta. Esa dinámica hace que una vía gobernada sea el movimiento interesado, no solo el responsable: la única respuesta duradera a la construcción no sancionada es una forma sancionada de construir que sea igual de rápida. Las prohibiciones no sobreviven al contacto con una herramienta que resuelve el problema del lunes por la mañana de alguien; los valores por defecto mejores sí.

Una autoevaluación rápida. ¿Puedes nombrar los últimos tres cambios en la app y quién los aprobó? Si la app se rompiera ahora mismo, ¿algo más aparte de un usuario te lo diría? ¿Podría un colega revertir el cambio de ayer sin que estés en la sala? ¿Algo detiene automáticamente una publicación cuando se rompe un flujo de login? Si respondiste no más de una vez, estás haciendo vibe coding, sea cual sea el nombre de tu herramienta.

Nada de esto es un argumento contra prototipar por instinto. La exploración es de donde vienen los buenos productos, y forzar disciplina completa sobre un experimento desechable desperdicia el tiempo de todos. El patrón de fallo no es prototipar; es que los prototipos se conviertan en silencio en producción porque nadie trazó la línea. Decide dónde está la línea antes de que la herramienta la cruce, y haz que cruzarla sea un acto deliberado con una lista de verificación, no una acumulación gradual de usuarios. Si quieres una versión estructurada de esa autoevaluación, el vibe coding risk scorecard la recorre pregunta por pregunta.

Ejecuta la misma prueba también a nivel de portafolio. La mayoría de organizaciones no tienen una app construida con IA; tienen docenas, en distintos estados de disciplina, y ninguna lista. Un inventario con propietarios nombrados, incluso una hoja de cálculo tosca, convierte un riesgo desconocido en uno gestionado, y normalmente saca a la luz dos o tres herramientas que en silencio se volvieron críticas mientras nadie miraba. Esos son tus primeros candidatos para la vía gobernada, clasificados por sensibilidad de datos y número de usuarios en lugar de por quién grita más fuerte.

Ciao se construyó para que la vía rápida y la vía disciplinada sean la misma vía. Describes la app en lenguaje sencillo y Ciao genera aplicaciones reales de React, TypeScript y Supabase que posees, pero cada cambio cae dentro del circuito de entrega en lugar de al lado. Guardrails mapea el código en áreas de negocio, detecta cambios de riesgo, aplica políticas en lenguaje sencillo, registra la revisión humana y deja un registro de auditoría tras cada merge. QA ejecuta réplicas deterministas del navegador, tests autorreparables, smoke gates antes de publicar y comprobaciones de producción después de publicar. Security ejecuta análisis estático, comprobación de dependencias y pruebas de control de acceso, y confirma vulnerabilidades contra la app en vivo antes de señalarlas.

El resultado es que un prototipo y una app de producción no son dos artefactos distintos en Ciao, son el mismo artefacto a distintos niveles de escrutinio, con el escrutinio aplicado por la plataforma en lugar de por quien lo recuerde. El código es React, TypeScript y Tailwind estándar, exportable a tu propio repositorio en cualquier momento, así la disciplina nunca se convierte en una jaula. Para equipos que ejecutan programas de producción serios, ese es el argumento en una línea: ingeniería asistida por IA, no vibe coding. Los programas de desarrollo serios empiezan en 10.000 USD al año; una demo es la forma más rápida de ver correr el circuito de principio a fin.

Una nota de honestidad: ninguna plataforma hace gratis la disciplina. Las políticas todavía tienen que escribirse, las zonas protegidas declararse, y alguien todavía posee las decisiones de juicio sobre los cambios señalados. Lo que cambia una plataforma es el valor por defecto: en Ciao la vía sin disciplina es la que requiere esfuerzo extra, lo opuesto a cómo funciona la mayoría de herramientas. En la práctica, esa inversión es lo que decide si los estándares de un equipo sobreviven al contacto con una fecha límite.