AI-DLC: el ciclo de vida de desarrollo impulsado por IA de AWS

En re:Invent 2025, Andy Jassy contó una anécdota que resume por qué todo el mundo en AWS está hablando de esto: un equipo de seis ingenieros reconstruyó por completo el motor de inferencia de Amazon Bedrock en 76 días, usando Kiro como copiloto agéntico. La estimación original con el proceso tradicional era de 40 ingenieros trabajando un año completo. No es una charla de marketing sobre "IA que ayuda a programar" — es un cambio real en cómo se organiza el trabajo de desarrollo cuando los agentes dejan de ser autocompletado y pasan a ejecutar tareas completas.

La metodología detrás de ese salto tiene nombre: AI-DLC (AI-Driven Development Life Cycle). AWS la publicó en su blog de DevOps en julio de 2025, liberó las reglas de flujo de trabajo como open source en noviembre, y la presentó formalmente en re:Invent 2025 con la promesa de ganancias de productividad de 10 a 15 veces. Para mediados de 2026 ya se convirtió en el modelo de referencia de facto para equipos que adoptan agentes de código a escala.

¿Qué es AI-DLC?

AI-DLC es la metodología de AWS para construir software donde la IA es una colaboradora central en todo el ciclo de vida del producto, no solo en la etapa de escribir código. En la práctica: los agentes redactan planes, código, tests e infraestructura como código, y los humanos validan cada paso antes de que se ejecute. Esa última parte es la que cambia todo — no es "deja que la IA haga lo que quiera", es un proceso estructurado de propuesta-revisión-ejecución.

El reemplazo más visible es al sprint tradicional. En vez de ciclos de dos semanas, AI-DLC trabaja en "bolts": ciclos de trabajo medidos en horas o días, no semanas. Como la IA puede producir un borrador de arquitectura, código funcional y tests en minutos, el cuello de botella deja de ser "cuánto tarda en escribirse" y pasa a ser "cuánto tarda el equipo en validarlo" — de ahí que los ciclos se acorten drásticamente.

Las tres fases

AI-DLC organiza el trabajo en tres fases, cada una con su propio mecanismo de validación en grupo (lo que AWS llama "Mob"):

1. Inception — qué construir y por qué

La IA convierte la intención de negocio en requerimientos, historias de usuario y unidades de trabajo concretas. El mecanismo de validación se llama Mob Elaboration: todo el equipo revisa en conjunto las preguntas y propuestas que hace la IA antes de avanzar. Aquí se deciden cosas que en apariencia son de producto, pero que en realidad son decisiones de seguridad: qué servicios de AWS se van a usar, qué datos va a tocar el sistema, qué modelo de identidad va a seguir.

2. Construction — cómo construirlo

Con el contexto validado en Inception, la IA propone una arquitectura lógica, modelos de dominio, código y tests. El equivalente aquí es Mob Construction: el equipo aclara decisiones técnicas en tiempo real mientras los agentes escriben código, generan tests, crean plantillas de infraestructura como código (IaC) y arman configuraciones de CI/CD. Los humanos revisan, dirigen y aprueban en puntos de control definidos — no después de que todo ya se desplegó.

3. Operations — desplegarlo con supervisión

La fase final aplica todo el contexto acumulado en las dos fases anteriores a la infraestructura como código y el despliegue real, siempre con supervisión del equipo. El contexto que se generó en Inception y Construction no se pierde — es lo que le da a los agentes la "memoria" para tomar decisiones coherentes en producción.

Herramientas: Kiro y Amazon Q Developer

Kiro es el agente que AWS usa como referencia para ejecutar AI-DLC (ahí corrió el caso de Bedrock que mencioné arriba), y ya existe un servidor MCP de AI-DLC corriendo dentro de Kiro que estructura el flujo Inception → Construction → Operations directamente en el editor. Amazon Q Developer también se integra como agente dentro del mismo flujo. Si ya leíste mi post sobre Kiro Crew, esto es la metodología que le da estructura a lo que ese sistema multi-agente ejecuta por debajo.

La perspectiva de seguridad (que a nadie le cuentan primero)

Acá es donde este post se separa de un simple "mira la herramienta nueva". Dejar que agentes escriban código, tests e infraestructura con supervisión humana reducida no es gratis en términos de riesgo, y AWS lo sabe — por eso publicó una Agentic AI Lens dentro del Well-Architected Framework, con una práctica específica (AGENTSEC04-BP01) sobre implementar guardrails y controles de alineación para este tipo de flujos.

Los controles reales que sostienen AI-DLC en producción se apoyan en tres capas:

• Human-in-the-loop (HITL): se interponen pasos de confirmación explícitos entre la decisión del agente y la ejecución de operaciones sensibles — exactamente lo que representan los checkpoints de Mob Elaboration y Mob Construction. No es opcional decorativo: es el mecanismo que evita que un agente con una mala interpretación de un parámetro ejecute algo destructivo sin que nadie lo vea antes.
• Guardrails de contenido: Amazon Bedrock Guardrails actúa como filtro central — detecta intentos de jailbreak, prompt injection y fuga de prompts, además de contenido dañino, antes de que lleguen a influir en lo que el agente decide hacer.
• Controles de IAM deterministas: el patrón que más me convence en la práctica es el de blast radius acotado — herramientas de solo lectura por defecto, combinadas con políticas IAM tipo DenyAllDestructive que hacen que, aunque el agente "quiera" hacer algo destructivo, literalmente no tenga el permiso IAM para lograrlo.

Lo importante es que estas tres capas son de naturaleza distinta: dos son deterministas (IAM, validación de esquemas) y una es probabilística (Guardrails basados en modelos). Esa combinación importa porque reduce la dependencia de que el agente simplemente "siga instrucciones" — si una capa falla o se evade, las otras siguen ahí. Es el mismo principio de defensa en profundidad que ya conocés, aplicado a agentes en vez de a infraestructura tradicional.

Riesgos reales que hay que vigilar

• Saltarse los "Mob" por presión de tiempo: todo el valor de seguridad de AI-DLC depende de que los checkpoints de validación humana se respeten. Un equipo que aprueba en automático para ir más rápido está tirando por la ventana la razón por la que el modelo es seguro en primer lugar.
• Confiar por defecto en IaC generado por IA: una plantilla de Terraform o CDK escrita por un agente necesita el mismo rigor de revisión de cambios que una escrita por una persona — más, mientras el equipo todavía no tiene calibrado qué tipo de errores comete el agente.
• Decisiones de Inception sin ojo de seguridad: si nadie con criterio de seguridad participa en Mob Elaboration, las decisiones de qué servicios y qué modelo de identidad usar quedan sin revisar hasta que ya es tarde y costoso cambiarlas.
• Prompt injection en el propio flujo de desarrollo: si el agente lee tickets, PRs o documentación externa como parte de su contexto, esa superficie es un vector de inyección de instrucciones — el mismo problema que ya cubrí en mi post sobre MCP RAT, aplicado ahora al propio pipeline de desarrollo.

Checklist antes de adoptar AI-DLC

1. ¿Tenés a alguien con criterio de seguridad participando en Mob Elaboration, no solo revisando código al final?
2. ¿Las herramientas del agente tienen permisos IAM acotados (solo lectura por defecto, deny explícito a acciones destructivas)?
3. ¿Tenés Guardrails o un mecanismo equivalente activo contra prompt injection y jailbreaks en el flujo del agente?
4. ¿El IaC generado por el agente pasa por el mismo proceso de revisión de cambios que el escrito por humanos?
5. ¿Los checkpoints humanos son reales (alguien lee y decide) o se volvieron un "aprobar" automático por presión de entrega?
6. ¿Tenés forma de auditar qué decidió el agente y por qué, después del hecho?

Conclusión

AI-DLC no es una promesa de "la IA reemplaza al equipo" — es una metodología concreta para que agentes ejecuten trabajo real (código, tests, infraestructura) dentro de un marco donde el humano sigue validando antes de que algo se ejecute. El caso de Bedrock (6 personas, 76 días, lo que antes tomaba 40 personas un año) es la prueba de que el salto de productividad es real. Pero ese salto solo es seguro si los checkpoints de Mob Elaboration y Mob Construction se toman en serio, y si los controles de IAM y guardrails están puestos desde el día uno, no agregados después de un incidente.

Si estás evaluando meter agentes de código en tu flujo de trabajo, la pregunta no es solo "¿qué tan rápido va a ir?" — es "¿quién está mirando cada paso, y qué puede hacer el agente si algo sale mal?".