Treinta ingenieros en una sala. Una característica que hay que desarrollar. Al final del día, tenían una especificación validada, código funcional y configuración de infraestructura, todo generado a partir de un documento de intención estructurada que escribieron juntos esa misma mañana.

En la encuesta de feedback, el equipo calificó la experiencia con un 9,7 sobre 10. Todos los encuestados mostraron interés en un piloto guiado. Cero rechazos. Cuando se les preguntó qué sección era más valiosa, el 41% eligió Elaboración de Mob (el ritual humano colaborativo) en lugar de Construcción de Mob (la generación de código impulsada por IA, con un 24%).

Ese último número es el que importa. Los humanos en la sala reconocieron de inmediato que el cuello de botella nunca fue generación de código. Era la definición de intención, y la metodología les daba una forma estructurada de resolverlo juntos.

Así es como se ve el AI-DLC cuando un equipo realmente lo ejecuta. No un ejercicio de pizarra blanca, ni una charla en una conferencia, ni una entrada de blog sobre principios. Una sesión de trabajo donde la metodología lleva el proceso y los humanos llevan el juicio.

Cómo se desarrolla una sesión

Un equipo tiene una nueva función que construir: un servicio de preferencias de notificaciones al cliente.

Primero la intención. El equipo redacta un documento de intención de una página describiendo lo que quieren construir y por qué. No es una especificación ni historias de usuario, solo la intención de negocio en lenguaje claro: «Necesitamos que los clientes controlen qué notificaciones reciben, a través de qué canales, con una gestión de consentimiento conforme al GRPD.»

Elaboración de la mafia. El agente de IA lee la intención, las barreras de gobernanza y el contexto del proyecto. Genera: una descomposición de unidades (cómo se divide la característica en partes entregables), historias de usuario con criterios de aceptación para cada unidad, requisitos no funcionales con umbrales medibles, un registro de riesgo y un plan de bolts (la secuencia de sesiones de construcción necesarias para entregar la funcionalidad).

El equipo revisa todo. Desafían los límites, añaden casos límite que la IA pasó por alto, señalan requisitos regulatorios que la IA desconocía. La IA revisa. En dos horas, tienen una especificación validada que habría llevado días en producir manualmente.

Construye bolt a bolt. Cada bolt pasa por cuatro etapas: modelado de dominio, diseño lógico, generación de código y validación de pruebas. La IA genera los artefactos de cada nivel, el equipo valida en cada punto de control y nada avanza hasta que el equipo aprueba. Las barreras de gobernanza están activas en todo momento: la IA comprueba cada artefacto frente a las líneas base de seguridad, restricciones de cumplimiento y estándares arquitectónicos antes de presentarlo al equipo.

Entregar La salida de cada bolt es una unidad de despliegue: código probado, configuración de infraestructura y documentación, todo generado a partir de la especificación validada y todo cumpliendo con las barreras de seguridad.

Lo que el equipo se lleva

Tras una sesión de un día completo, el equipo dispone de artefactos concretos que puede usar de inmediato. Un modelo de dominio validado que nombra los contextos acotados y sus relaciones. Ocho a doce historias de usuario con criterios de aceptación lo suficientemente específicos como para que un agente de IA pueda ejecutarlas sin ambigüedades. Un registro de decisiones arquitectónicas que documenta uno o dos compromisos que el equipo debatió y resolvió durante la elaboración, de modo que el razonamiento sobreviva incluso si las personas rotan. Requisitos no funcionales con umbrales medibles: no «el sistema debe ser rápido» sino «latencia P95 inferior a 200ms en 500 usuarios concurrentes.» Y un plan de bolts que secuencia los trabajos de construcción en entregables diarios que el equipo pueda seguir.

Ninguno de estos artefactos es novedoso por separado. Lo que cambia es que existen antes de que se genere la primera línea de código, son validados colectivamente por el equipo y se convierten en el contexto operativo de la IA para cada paso de la generación siguiente. La especificación limita el espacio de generación. La IA produce resultados diferentes cuando tiene un modelo de dominio validado y NFRs explícitos que cuando tiene un prompt de un párrafo y buenas intenciones.

Qué sale mal sin estructura

Cada equipo que dirige el taller reconoce al menos uno de estos modos de fallo por su propia experiencia.

Fatiga por aprobación. La IA genera una especificación que parece internamente coherente, el equipo la revisa y, como se lee bien, la aprueba sin cuestionar las suposiciones que hay debajo. Tres sprints después, descubren que el modelo de dominio era incorrecto desde el principio. La coherencia interna generada por IA crea una falsa sensación de corrección. El ritual de Elaboración de Mob impide esto obligando al equipo a desafiar cada límite antes de que la IA pase a la construcción.

Secado rapido La salida de la IA se solidifica antes de que nadie la verifique. Un desarrollador solicita a la IA, consigue que el código funcione en veinte minutos, lo hace commit y sigue adelante. Por la tarde, otros tres componentes dependen de decisiones arquitectónicas que nadie revisó. Deshacerlas cuesta más que construirlas correctamente. La estructura de cerrojos lo impide restringiendo el ritmo de generación al ritmo de validación: nada avanza hasta que el equipo lo aprueba.

Deuda de comprensión. Seis meses después de que salga una función, nadie puede explicar por qué el código funciona como lo hace. El desarrollador que impulsó la IA se fue, el razonamiento nunca se documentó, y la base de código funciona pero existe fuera del modelo mental de cualquiera. La metodología evita esto generando registros de decisiones arquitectónicas y documentación de intenciones junto al código, de modo que el «por qué» sobrevive independientemente de las personas que estaban en la sala.

Estos no son riesgos hipotéticos. Son los patrones que veo en organizaciones que adoptaron herramientas de codificación con IA sin una metodología estructurada. Las herramientas funcionan. La brecha metodológica es lo que rompe.

¿Qué hace que esto sea diferente de «simplemente pedir mejor»?

Tres cosas separan el desarrollo estructurado de IA del consejo de «escribir mejores prompts» que llena todos los hilos de productividad de IA.

La metodología se recuerda a sí misma. No necesitas recordar si estás en elaboración o construcción, en qué etapa de la construcción te encuentras o cuáles son los criterios de salida. El proceso rastrea dónde estás y le dice a la IA qué hacer a continuación. Esta es la diferencia entre una metodología que tienes que recordar y una metodología que se sostiene sola.

La gobernanza está incrustada, no añadida. Al final, los estándares de seguridad, cumplimiento y arquitectura no son una barrera de revisión. Forman parte del contexto de generación de la IA desde el primer artefacto. La IA genera código conforme porque las restricciones forman parte de su entrada, no porque alguien revise la salida tres semanas después.

La estructura se adapta a la obra. Una aplicación greenfield tiene rituales y límites de calidad diferentes a una modernización brownfield o una evaluación de gobernanza cloud. La metodología se adapta al dominio manteniendo el mismo principio fundamental: intención antes de la generación, validación antes del avance, gobernanza en todo momento.

La curva de adopción que he observado

Los equipos que adoptan un desarrollo estructurado de IA pasan por una secuencia predecible. La primera sesión se siente lenta porque están aprendiendo la estructura del ritual. La segunda sesión es más rápida porque el agente de IA ya tiene contexto de los artefactos de la primera sesión. Para la tercera sesión, el equipo deja de pensar en la metodología y empieza a pensar en el problema.

Su principal obstáculo para la adopción es la preparación de habilidades, no el escepticismo o la resistencia: el 53% dijo «necesitamos identificar el proyecto adecuado» y el 29% ya tenía uno en mente. Creían que funcionaba después de verlo una vez. Solo necesitaban un camino guiado desde el taller hasta la producción.

Un equipo más pequeño con el que trabajé recientemente, seis ingenieros de una empresa fintech, ejecutó la metodología en un problema brownfield: modernizar un servicio de conciliación de pagos que había acumulado tres años de reglas empresariales no documentadas. Primero usaron la Elevación de Código para hacer legible la base de código existente para el agente de IA, luego ejecutaron Mob Elaboration contra el contexto elevado. El líder del equipo me dijo después que la fase de elevación sacó a la luz doce reglas implícitas de negocio que nadie en el equipo actual sabía que existían. Habían estado manteniendo un código que imponía restricciones que no podían explicar. La metodología hacía visible lo invisible antes de que empezaran a cambiar nada.

Los adoptantes más rápidos ya probaron el desarrollo asistido por IA sin estructura y se toparon con los muros que describí en El desajuste entre asistentes de código de IA y desarrollo de software empresarial. Ya saben lo que cuesta el desarrollo de IA no estructurada. No necesitan que se les convenza de que el problema existe. Necesitan una solución que no les obligue a convertirse primero en expertos en metodología.

Un desarrollador con el que trabajo probó la metodología manualmente antes de que tuviéramos el proceso estructurado. Escribía documentos de intención a mano, los descomponía en unidades, redactaba historias con criterios de aceptación y luego introducía todo a su agente de IA como contexto. Le llevó cuatro horas producir lo que la metodología genera en cuarenta minutos. Las historias eran buenas, la estructura era correcta, pero mantenerla manualmente en un proyecto real era agotador. Su segundo proyecto, con la metodología completa apoyándole, le llevó de la intención a la función principal en tres días.

Ya hemos desarrollado las herramientas, el andamiaje de procesos y las plantillas de gobernanza que hacen que esto sea repetible entre equipos empresariales. La metodología no es un concepto esperando a ser implementado. Es un sistema funcional con vías estructuradas de incorporación diseñadas para llevar a los equipos desde la primera sesión hasta la ejecución autónoma sin necesidad de construir la infraestructura por sí mismos.

Qué significa esto para los líderes de ingeniería

Si lideras un equipo que utiliza herramientas de codificación por IA, ya has tomado una decisión sobre la metodología, seas consciente de ello o no. La ausencia de un enfoque estructurado es en sí misma una metodología: es codificación de vibración con pasos adicionales.

La evidencia de la comunidad, de la brecha de revisión de arquitectura y de la paradoja de gobernanza apunta en la misma dirección. Tu equipo necesita una estructura en torno al desarrollo asistido por IA.

Si quieres ver la metodología en acción, organizo talleres donde los equipos pasan de la intención a la especificación validada y al código funcionando en un solo día. La respuesta que más escucho después no es «concepto interesante». Es «¿con qué proyecto empezamos?»

Ricardo