El incidente siempre tiene la misma forma. Una funcionalidad desplegada hace tres semanas. Funcionaba. Los tests estaban verdes. Luego algo adyacente se rompe — una conversión de divisa, una comprobación de permisos, un retry que se traga los errores en silencio — y cuando alguien finalmente abre el archivo, nadie en el equipo reconoce ese código. No porque sea mal código. Porque nadie lo escribió. Fue generado, ojeado, aprobado y mergeado.
Esta es la parte de la historia del vibe coding que no llega a las demos. Dirijo la ingeniería de un portafolio de productos enterprise y en los últimos dieciocho meses he visto el mismo patrón repetirse en una docena de codebases: la ganancia de velocidad es real, es grande, y se paga después — con intereses — a menos que alguien ponga guardrails estructurales antes.
Quiero ser preciso sobre mi posición, porque se malinterpreta en ambas direcciones. No estoy en contra del vibe coding. En Lasting Dynamics nuestros equipos usan asistentes de IA todos los días y no volvería atrás. Cada ingeniero que contratamos pasa por LD Academy, donde programar con agentes de IA forma parte del programa desde el primer día. Pero hay una diferencia entre usar IA para escribir código y dejar que la IA decida tu arquitectura, y la mayoría de los equipos enterprise no ha trazado esa línea en ningún sitio todavía.
La Opinión de Michele
La pregunta no es si tu equipo debería hacer vibe coding. Ya lo está haciendo — con o sin tu política. La única pregunta real es si el código producido así puede llegar a producción sin pasar por un gate del que sea responsable una persona. Si la respuesta es sí, no tienes una estrategia de IA. Tienes un pasivo sin contabilizar.
Qué Significa Realmente el Vibe Coding en Contexto Enterprise
El vibe coding es la práctica de construir software describiendo la intención en lenguaje natural y aceptando el código que produce un modelo de IA, con revisión línea por línea limitada o inexistente. El término nació para builders individuales que lanzan prototipos a gran velocidad, y en ese contexto es algo genuinamente maravilloso. El problema es que la práctica migró a las codebases enterprise sin que la definición migrara con ella.
En un entorno enterprise, el vibe coding se entiende mejor como un desplazamiento del lugar donde se aplica el juicio de ingeniería. No ha desaparecido: se ha movido. Antes vivía en el acto de escribir. Ahora tiene que vivir en el acto de especificar, restringir y verificar. Los equipos que hicieron esa transición de forma consciente entregan más rápido y con menos defectos. Los que no lo hicieron simplemente eliminaron el juicio del pipeline y lo llamaron productividad.
Bajo la misma etiqueta caben tres comportamientos distintos, y tratarlos igual es donde empieza la mayoría de los fallos de governance:
- Escritura asistida — el desarrollador sabe lo que quiere, usa IA para escribirlo más rápido y lee cada línea. Riesgo bajo. Es simplemente un teclado mejor.
- Implementación delegada — el desarrollador especifica el comportamiento, la IA produce un módulo completo, el desarrollador revisa la interfaz y comprueba por muestreo las partes internas. Riesgo medio. Manejable con los gates correctos.
- Generación no supervisada — un prompt produce código funcional, los tests pasan, se mergea. Nadie tiene un modelo mental de su funcionamiento interno. Aquí se acumula el coste real, y es el único de los tres que merece alarma de verdad.
Casi todas las políticas que he revisado prohíben los tres o permiten los tres. Ambas son respuestas equivocadas, y ambas son síntoma del mismo error: tratar el vibe coding como una cuestión de tooling en lugar de una cuestión de clasificación de riesgo.
El Número Que Todos Citan — y el Que Nadie Cita
El número que aparece en cada presentación es el experimento controlado de GitHub con 95 desarrolladores: alrededor de un 55% más de velocidad en completar tareas con un asistente de IA. Es un resultado real y no tengo nada que objetar. Mi objeción es que mide una sola dimensión — el tiempo hasta la primera implementación funcional — y el software enterprise no se juzga en esa dimensión.
Este es el cuadro más completo, extraído de lo que observo realmente cuando un equipo adopta asistentes de IA sin cambiar nada más en su forma de trabajar:
| Dimensión | Dirección | Qué ocurre realmente |
|---|---|---|
| Tiempo al primer código funcional | Mucho mejor | El 55% se sostiene. Esta parte no es discutible. |
| Volumen de código producido | Muy arriba | Más código, diffs más grandes, más superficie por pull request. |
| Calidad de la revisión de código | Abajo | Los revisores enfrentan diffs 3–4 veces mayores con el mismo tiempo. Aprobar se convierte en ojear. |
| Coherencia arquitectónica | Abajo | Cada generación resuelve su problema localmente. Los patrones divergen en silencio entre módulos. |
| Defectos que se escapan | Arriba | Bugs que pasan los tests pero violan invariantes no declaradas — la categoría cara. |
| Tiempo para entender el código después | Muy arriba | Nadie tiene un modelo mental. El debug empieza de cero cada vez. |
Leída en conjunto, la tabla no deja dudas. El vibe coding no elimina el trabajo de ingeniería: lo reubica aguas abajo, de escribir a revisar, depurar y mantener. Si tu organización no ha reforzado en la misma medida su capacidad de revisión, depuración y mantenimiento, no has logrado una ganancia de productividad. Has firmado un préstamo.
La Métrica Que Lo Delata
Deja de medir velocity y empieza a medir el tiempo medio de comprensión: cuando un ingeniero que no conoce ese código abre un archivo en producción, ¿cuánto tarda hasta poder modificarlo con seguridad? Es la única métrica que detecta la deuda por vibe coding, porque es la única que empeora a medida que sube el volumen generado. Si empeora mientras tus story points mejoran, ya tienes la respuesta.
Las Cuatro Formas en Que el Vibe Coding Rompe una Codebase Enterprise
No son hipótesis. Cada uno de los cuatro es algo que me han llamado a diagnosticar, y ninguno se anuncia con antelación — que es precisamente lo que los hace caros.
1. Deriva arquitectónica
Un modelo de IA optimiza para el prompt que tiene delante, no para las diecisiete convenciones que tu codebase ha acumulado. Pides una capa de caché y obtienes una buena capa de caché — que ignora la abstracción que ya usan otros tres módulos. Repítelo cuarenta veces y ya no tienes una arquitectura. Tienes una colección de decisiones localmente razonables que nadie puede sostener en la cabeza a la vez. Es un fallo lento, silencioso, y cuando se hace visible cuesta una reescritura.
2. Agujeros de seguridad que parecen código limpio
El código generado es estilísticamente excelente, y ahí está exactamente el problema: no parece sospechoso. Los casos que veo repetirse son comprobaciones de autorización que verifican la autenticación pero nunca el permiso, validación de entrada sobre la forma pero no sobre el rango, manejadores de error que filtran detalles internos en las respuestas, y elecciones de dependencias basadas en la popularidad en los datos de entrenamiento en lugar del estado de mantenimiento. Un revisor que busca olores no encuentra ninguno, porque no hay olor. Por eso la seguridad por diseño deja de ser opcional en el momento en que adoptas IA a escala.
3. Tests que validan la implementación, no el requisito
Es el fallo del que menos se habla y, según mi experiencia, el más peligroso. Cuando el mismo modelo escribe el código y sus tests, los tests describen lo que el código hace — no lo que el negocio necesita. La cobertura parece excelente. La suite está verde. Y es estructuralmente incapaz de detectar la clase de bug que más importa, porque el malentendido está presente de forma idéntica en ambos artefactos. Tests verdes escritos por el autor del bug no demuestran nada.
4. El vacío de conocimiento
Históricamente, escribir un módulo era también la forma en que un ingeniero llegaba a entenderlo: el esfuerzo era el aprendizaje. Quita el esfuerzo y te queda el artefacto pero pierdes la comprensión. Seis meses después, la persona que lo desplegó no sabe explicarlo, y la capacidad real de la organización es mucho menor de lo que sugiere su historial de commits. Este es el que peor se acumula con el tiempo, porque degrada precisamente la capacidad que necesitas para arreglar los otros tres.
La Arquitectura de Guardrails: Seis Capas Que Funcionan
Esto es lo que implemento cuando un equipo quiere conservar la velocidad de la IA sin aceptar su coste aguas abajo. Es deliberadamente aburrido, no es caro, y el orden importa — cada capa asume que la anterior ya está en pie.
- Codifica tus convenciones en formato legible por máquina. Decisiones arquitectónicas, reglas de naming, librerías aprobadas y patrones prohibidos van en un archivo que la IA lee en cada petición. Desde el punto de vista de un modelo, una convención no documentada es una convención que no existe. Este único paso elimina la mayor parte de la deriva arquitectónica con un día de trabajo.
- Separa al autor del código del autor de los tests. Si la IA genera la implementación, los criterios de aceptación los escribe antes una persona — o un modelo distinto escribe los tests partiendo del requisito, nunca del código. Rompe la correlación y los tests recuperan la capacidad de fallar de forma útil.
- Pon los gates en el blast radius, no en el volumen. El tamaño del diff es un indicador de riesgo terrible. Lo que el código puede alcanzar — dinero, datos personales, autenticación, contratos externos, migraciones — sí es un buen indicador. La siguiente sección lo aborda como es debido, porque hace más trabajo que las otras cinco capas juntas.
- Haz obligatoria y adversarial la revisión de código con IA. Pasa un segundo modelo por cada diff con la instrucción explícita de encontrar fallos de seguridad, casos límite ausentes y violaciones de convenciones — no de resumir. Es barato, rápido, y detecta una parte significativa de lo que se le escapa a una persona que está ojeando. Complementa la revisión humana; nunca la sustituye.
- Fija un umbral mínimo de comprensión humana, e imponlo en el ritual. La regla que usamos: un ingeniero no puede aprobar un diff que no sabría defender en una design review. No es un eslogan — es una pregunta que se hace de verdad. Es el único control que aborda directamente el vacío de conocimiento.
- Instrumenta las invariantes, porque los tests no lo harán. Verifica tus reglas de negocio en producción: los saldos cuadran, los totales no son negativos, cada acción privilegiada tiene un registro de auditoría. El código generado por IA falla en las suposiciones no declaradas, y las assertions en runtime son la única capa que detecta lo que nadie pensó en escribir.
Empieza por las Capas 1 y 3
Si este trimestre no implementas nada más, haz el archivo de convenciones legible por máquina y la clasificación por blast radius. Juntas son unos dos días de trabajo y abordan los dos fallos — deriva arquitectónica y acceso sin revisar a rutas críticas — que causan los incidentes por los que realmente te van a llamar.
El Blast Radius Es la Única Regla Que Realmente Importa
Casi todas las políticas de AI coding que leo están escritas como permisos generales: la IA está permitida, o no lo está, o está permitida “con revisión”. Las tres son inútiles, porque tratan una página de marketing y un ledger de pagos como el mismo objeto. El enfoque que funciona es clasificar tu codebase según lo que el código puede dañar, y poner el gate por nivel.
| Nivel | Qué contiene | Política de vibe coding |
|---|---|---|
| Verde | Herramientas internas, prototipos, vistas admin, scripts, tests de rutas no críticas, documentación | Sin restricciones. Despliega. No añadas proceso aquí — es donde se gana la velocidad. |
| Amarillo | Funcionalidades de producto, UI, APIs no críticas, integraciones sin datos financieros o personales | Generación permitida, revisión humana obligatoria con el umbral de comprensión aplicado. |
| Rojo | Autenticación y permisos, pagos y ledgers, datos personales o sanitarios, migraciones, contratos externos, audit logging | La IA puede proponer un borrador. Una persona con nombre y apellido es responsable, reescribe y firma línea por línea. Sin excepciones y sin presión temporal sobre este gate. |
En la práctica, la clasificación honesta de una codebase enterprise típica se sitúa cerca del 70% verde, 25% amarillo, 5% rojo. Y ahí está toda la idea: puedes hacer vibe coding en la inmensa mayoría de tu sistema sin ninguna ceremonia, precisamente porque has hecho que ese 5% sea de verdad no negociable. Las políticas generales fallan porque o estrangulan el 70% o exponen el 5%. La clasificación por niveles es lo que te permite dejar de elegir.
“Los equipos que más valor obtienen de la IA no son los que tienen las reglas más laxas ni los más estrictos. Son los que saben exactamente qué 5% de su codebase debe seguir en manos de una persona.”
— Michele Cimmino · CEO & Fundador, Lasting Dynamics
Cómo Se Ve Esto en un Equipo Real
Algo de detalle operativo, porque a los frameworks es fácil asentir y difícil hacerlos funcionar. En nuestros equipos en Lasting Dynamics la clasificación vive en el propio repositorio: reglas basadas en paths en CI, de modo que una pull request que toca un directorio de nivel rojo requiere automáticamente al owner designado y no puede ser mergeada por nadie más. La política no es un documento que la gente deba recordar. Es un pipeline que se niega.
El archivo de convenciones se trata como código de producción: revisado, versionado y actualizado en el momento en que cambia una decisión arquitectónica. Cuando la deriva aparece en revisión, la corrección casi nunca es una reprimenda al ingeniero — es una línea que falta en ese archivo. Ese cambio de encuadre importa más de lo que parece, porque convierte un problema de disciplina en un problema de documentación, y los problemas de documentación se resuelven.
El umbral de comprensión, en cambio, se impone socialmente, no técnicamente. En design review elegimos al azar un archivo mergeado recientemente y pedimos a quien lo aprobó que lo explique. Nadie es castigado si no puede — pero el incentivo se corrige casi de inmediato, y a las dos semanas las aprobaciones por ojeo desaparecieron. Es el control más barato de la lista y el que más hace por la capacidad a largo plazo. Es el mismo argumento que sostengo sobre poseer tus sistemas en lugar de alquilarlos: el valor está en la comprensión que acumulas, no solo en el artefacto que acabas teniendo.
Si te interesa el panorama más amplio de cómo la IA está reescribiendo la economía de la entrega y no solo la revisión de código, escribí una versión orientada a fundadores en mi guía sin hype sobre IA en el desarrollo de software. Este artículo es la contraparte enterprise de governance: la misma tecnología, otra pregunta.
El Despliegue en 30 Días
No necesitas un programa de transformación. Necesitas cuatro semanas y alguien con autoridad para decir no.
- Semana 1 — Clasifica la codebase. Reúne a tus ingenieros senior y clasifica cada directorio de primer nivel como verde, amarillo o rojo. Debate los límites: la discusión es la parte valiosa. Registra el resultado en el repositorio.
- Semana 2 — Escribe el archivo de convenciones. Decisiones arquitectónicas, dependencias aprobadas, patrones prohibidos, naming, manejo de errores. Conéctalo al tooling de IA que usa el equipo para que se cargue automáticamente en lugar de recordarse.
- Semana 3 — Conecta los gates. Reglas de CI basadas en paths para la ownership del nivel rojo, un paso de revisión adversarial con IA en cada pull request y assertions en runtime sobre tus tres invariantes de negocio más importantes.
- Semana 4 — Instala el ritual y la baseline. Arranca la explicación aleatoria en design review y mide ahora el tiempo medio de comprensión, para tener un número con el que comparar en un trimestre.
La Parte Que Nadie Quiere Oír
El vibe coding no es una fase y no va a prohibirse internamente. Tus ingenieros lo están usando ahora mismo, la ganancia de productividad es real, y cualquier política construida sobre la prohibición será simplemente esquivada — en silencio, por buenas personas, bajo presión de plazos. No es un fallo de disciplina. Es lo que pasa cuando una política hace a la gente más lenta en su trabajo real.
Pero las empresas que en tres años sigan siendo capaces de modificar su software no serán las que más código generaron. Serán las que siguieron siendo capaces de entenderlo. La comprensión es el recurso escaso ahora — no la velocidad de escritura, no el volumen de commits, no los story points. Todo en este playbook sirve en última instancia para protegerla.
La buena noticia es que nada de esto es caro ni lento. Seis capas, cuatro semanas y una conversación incómoda sobre qué 5% de tu sistema debe seguir en manos de una persona. Las organizaciones que tengan esa conversación ahora seguirán entregando igual de rápido en dos años. Las que la posterguen pasarán esos dos años explicando incidentes en código que nadie escribió.
La Opinión de Michele
Si te llevas una sola cosa: el objetivo no es frenar la IA. Es hacer que la velocidad sea sostenible. Los guardrails no son el impuesto que pagas por usar IA — son la razón por la que puedes seguir usándola de forma agresiva sin una revisión trimestral de incidentes. Clasifica tu codebase, protege el 5% y deja que tu equipo vuele en el resto.