Cómo prevenir el caos en el software creado con IA

Cómo se ve el vibe coding

El vibe coding consiste en construir software dándole prompts a la IA sin criterio de ingeniería ni supervisión de la arquitectura. No es malo en sí mismo. Los prototipos construidos así avanzan rápido. Pero cuando la velocidad se convierte en la única métrica, aparecen modos de falla específicos.

El ingeniero se sienta frente al teclado y describe en lenguaje natural lo que quiere. Claude, Cursor, ChatGPT o v0 generan código que parece correcto. Compila. Se ejecuta. Resuelve el problema inmediato. Nadie pregunta por qué se construyó así, qué concesiones se hicieron ni si encaja en la estrategia de producto más amplia. El código se fusiona y se lanza.

Esto se repite decenas de veces. Cada funcionalidad funciona por separado. Pero la base de código no tiene una forma coherente. No hay un entendimiento compartido de cómo encajan las piezas. Cuando se incorpora un ingeniero nuevo, lee código que una IA generó a partir de un prompt vago y tiene que reconstruir la intención con ingeniería inversa. A veces la intención era la correcta. A veces la IA resolvió con total seguridad el problema equivocado.

Para cuando se da cuenta de que el sistema no se puede mantener, ya lleva seis meses en una base de código que habría que reescribir. Vulnerabilidades de seguridad que debieron detectarse en la revisión de código llegaron a producción. Modelos de datos que parecían razonables por separado se rompen al escalar. Integraciones que funcionaron una vez fallan en silencio en producción porque nadie documentó sus supuestos.

Los cinco modos de falla

El vibe coding produce cinco tipos específicos de falla que se agravan con el tiempo.

El colapso del contexto ocurre cuando la IA genera código a partir de prompts incompletos o vagos en lugar de un entendimiento estructurado del producto. La IA responde con mucha seguridad y el código es sintácticamente correcto, pero resuelve el problema equivocado o parte de supuestos que contradicen otras partes del sistema. Para cuando lo descubre, ya está en producción.

La erosión de las decisiones ocurre cuando las decisiones técnicas se toman de forma implícita en los prompts de la IA y no de forma explícita por parte del equipo. Nadie documenta por qué el sistema usa paginación en lugar de desplazamiento infinito, por qué la autenticación pasa por un servicio en particular o por qué el modelo de datos tiene esa desnormalización. Seis meses después, un ingeniero nuevo quiere refactorizar algo y no tiene idea de qué problema resolvía.

La automatización sin control significa que la IA se aplica a áreas de alto riesgo sin una supervisión proporcional. Un desarrollador le pide a una IA "generar el esquema de base de datos para las cuentas de usuario" y obtiene código que funciona, pero que no cifra los datos en reposo, no valida las entradas y expone información de identificación personal (PII) en las bitácoras. La IA nunca señaló estos puntos como problemas porque el prompt no pedía seguridad. Pero la seguridad no debería depender de que el desarrollador se acuerde de pedirla.

El aprendizaje perdido es la acumulación de los mismos errores en toda la base de código. El equipo se topa con un problema, lo resuelve con IA, lo lanza y sigue adelante. La siguiente vez que aparece el problema (y siempre aparece), lo vuelve a resolver de la misma manera, a veces peor. No hay ningún mecanismo para registrar qué funcionó, qué no y por qué. La mejora se pierde.

La entrega desalineada se da cuando el código es correcto pero sirve a un propósito equivocado. Una IA genera una funcionalidad que funciona perfectamente pero resuelve un problema que el producto ya no tiene, o lo resuelve de una forma que contradice la estrategia de producto. Para cuando se descubre la desalineación, la funcionalidad ya está en producción y otro código depende de ella.

Por qué importa en la operación

Los sistemas hechos con vibe coding fallan en silencio, hasta que la falla deja de ser silenciosa. Un prototipo que funciona parece un producto. Un inversionista o un cliente ve software funcionando y supone que está listo para escalar. Pero la primera vez que necesita agregar una funcionalidad que toca la arquitectura central, soportar 10x la carga o integrarse con otro sistema, la base de código se convierte en un pasivo.

El impacto en el negocio es predecible: inversión de ingeniería desperdiciada, reconstrucciones desde cero, incidentes de seguridad, caídas que afectan a los clientes y plazos incumplidos mientras los ingenieros luchan con código imposible de mantener en lugar de crear valor nuevo. En los peores casos, los equipos terminan reconstruyendo gran parte de un sistema que les tomó seis o doce meses crear.

Los fundadores que construyeron con herramientas de IA no lo hacen a propósito. Avanzan rápido porque lo necesitan. Usan las mejores herramientas disponibles. Pero sin estructura, la velocidad se convierte en desperdicio.

La solución: CRAFT

CRAFT (Context, Rationale, Automate, Fortify, Telemetry) es el sistema operativo de InTech, la gobernanza que sostiene la estrategia, la ingeniería de producto y las operaciones gestionadas. Pro-Neering es la filosofía que lo respalda. En el desarrollo asistido por IA, CRAFT previene estos modos de falla. No se trata de ir más despacio. Se trata de hacer visibles las decisiones correctas y hacerlas cumplir antes de escribir el código.

Context (contexto) previene el colapso del contexto. Antes de empezar a escribir código, el equipo acuerda un Intent Contract. Un Intent Contract es una declaración breve y aprobada del resultado, el alcance, las métricas de éxito, las restricciones, los límites de la autoridad humana y los criterios de aceptación. No es un acuerdo legal; las condiciones comerciales se establecen en el contrato del proyecto. Lo aprueban las personas que entienden el negocio y el producto. Este documento es la referencia compartida que evita que los prompts vagos generen disparates con total seguridad. Cuando un agente de IA tiene todo el contexto, genera código que realmente resuelve el problema.

Rationale (fundamento) previene la erosión de las decisiones. Cada decisión técnica importante queda registrada en un Decision Record, con su razonamiento. ¿Por qué elegimos este proveedor de autenticación? ¿Qué concesión aceptamos? ¿Cuáles eran las alternativas? No son documentos de diseño detallados. Son un registro permanente de por qué las cosas se construyeron como se construyeron. Los ingenieros nuevos los leen y entienden la intención. Cuando más adelante necesite refactorizar, sabrá qué problema está resolviendo.

Automate (automatización) significa usar la IA donde es más fuerte (generación de código, refactorización, código repetitivo), pero con supervisión. La automatización sin criterio es la vía por la que llegan a producción vulnerabilidades de seguridad y malos patrones. La automatización con revisión de código, controles de calidad y revisión de arquitectura previene los peores modos de falla. La IA hace el trabajo pesado. Los ingenieros aportan el criterio.

Fortify (fortalecimiento) evita que se lance código defectuoso o inseguro. Los controles de calidad son obligatorios antes del despliegue. Incluyen revisión de código, análisis de seguridad, pruebas de rendimiento y pruebas de integración. No son revisiones opcionales que los equipos ocupados se saltan. Son controles que hay que aprobar. Si un fragmento de código no cumple los estándares, no se lanza. Cuanto antes se aplique esto, menos desperdicio habrá.

Telemetry (telemetría) previene el aprendizaje perdido. Todo sistema en producción cuenta con observabilidad: bitácoras, métricas, alertas y grabaciones de sesiones. Cuando algo falla, usted sabe qué pasó y por qué. Cuando una funcionalidad no se usa, lo ve en los datos. El equipo registra lo que funciona y aprende de lo que no. Así se genera una mejora acumulativa, en lugar de que los mismos problemas se repitan.

Cómo se ve el desarrollo estructurado asistido por IA

En la práctica, el desarrollo estructurado asistido por IA es más rápido que el vibe coding a largo plazo porque evita el desperdicio.

Primero, el equipo acuerda un Intent Contract. Normalmente toma días, no semanas, y surge de la evaluación cuando la hay. Obliga a tener las conversaciones difíciles. ¿Qué intentamos lograr? ¿Qué no vamos a hacer? ¿Cómo se ve el éxito? ¿Qué nos llevaría a cancelar este esfuerzo? Al final, todos están de acuerdo en la forma del trabajo.

Después, los desarrolladores usan la IA como herramienta para escribir código más rápido. Le dan el Intent Contract a Claude o a Cursor como contexto. Escriben prompts que hacen referencia a decisiones y restricciones específicas. La IA genera código alineado con la estrategia de producto y con las decisiones de arquitectura, no solo algo que encaje con una descripción vaga.

Antes de fusionar cualquier cambio, la revisión de código detecta los problemas de alineación. ¿Este código es coherente con la arquitectura? ¿Sigue los patrones que estableció el equipo? ¿Cumple con el Intent Contract? Si no, se corrige antes de llegar a la base de código. Corregir un problema de arquitectura en este punto cuesta horas. Corregirlo seis meses después cuesta semanas.

El sistema se despliega cuando aprueba los controles de calidad. La observabilidad le indica al equipo si funciona y cómo se está usando. Las decisiones quedan registradas. La siguiente vez que aparece un problema similar, el equipo consulta el Decision Record, evalúa si la solución anterior sigue siendo válida y la reutiliza o documenta una nueva decisión.

Esto no es burocracia. Es lo contrario. Es evitar el desperdicio que surge de construir sin estructura. Es avanzar rápido en lo que importa y evitar el desperdicio en lo que no.

Rescate de proyectos de vibe coding

Muchos equipos usaron herramientas de IA para construir algo rápido y ahora necesitan ingeniería de verdad para que sea confiable. A esto se le llama rescate de proyectos de vibe coding.

Así suele manifestarse (un escenario hipotético para mostrar el patrón). Un fundador construye un prototipo con v0 en dos semanas. Funciona, y los inversionistas quieren el producto en dos meses. Seis meses después, se han acumulado decenas de miles de líneas de código. Las nuevas funcionalidades tardan más en lanzarse que en el segundo mes. El equipo discute sobre la arquitectura porque nadie documentó por qué se construyó cada cosa como se construyó. El código es lento y tiene vulnerabilidades de seguridad.

Cuando una base de código se construyó rápido y sin estructura, una evaluación de transición gestionada establece qué conservar, qué reconstruir y cuál es el primer Intent Contract. A partir de ahí, el trabajo consiste en registrar las decisiones que importan, documentar la arquitectura, implementar controles de calidad y enseñar al equipo a construir con estructura.

Conservar lo que funciona suele ser más barato y más rápido que reconstruir desde cero. También es una señal de que la siguiente etapa de crecimiento requiere disciplina de ingeniería. El equipo aprende a construir de otra manera.