AI-DLC 2: qué cambió y qué dejó obsoleto
AWS reescribió AI-DLC. La versión 2 llega como un motor determinístico que le quita al modelo la ruta, la evaluación y el estado: 5 fases, 33 etapas, 14 agentes, 11 perfiles de workflow, un loop de aprendizaje y checkpoints de construcción verificados. Qué cambió desde la versión 1, qué capas caseras dejó obsoletas y qué sobrevivió.
AWS no subió AI-DLC a la versión 2. Lo reescribió, y en una sola release la mayor parte de la plomería que los equipos habían construido sobre la versión 1 dejó de valer el mantenimiento.
AI-DLC 2 es la segunda generación del AI-Driven Development Life Cycle de AWS. La primera release estable de la línea 2.x, la 2.7.0, salió el 1 de septiembre de 2026. Tres semanas después ya estaba la 2.10.0. La versión 1 era un conjunto de archivos de reglas que le decía al agente cómo guiarte por un proyecto. La versión 2 es un motor: un comando nativo, aidlc, que instala un workflow determinístico en siete agentes de código, con 5 fases, 33 etapas, 14 agentes, 11 perfiles de workflow y un loop que convierte tus correcciones en reglas.
Si el método en sí es nuevo para ti, empieza por qué es AI-DLC. Este artículo es para quienes ya conocen la versión 1, o para quienes están decidiendo si empezar directo en la versión 2.
Seguí la versión 1 de AI-DLC dentro de una gran organización de ingeniería, de los squads piloto a un programa de formación. Los equipos hicieron lo que hace todo adoptante serio con un framework joven: construyeron capas encima para cubrir lo que le faltaba. Después AI-DLC 2 entregó la mayor parte de esas capas como funciones nativas. Ver eso me enseñó más sobre adoptar frameworks de IA que el propio framework, así que la segunda mitad de este artículo trata de eso.
De archivos de reglas a un motor en catorce meses
Cómo llegó AI-DLC a la versión 2
- jul. 2025El whitepaper
Raja SP publica la definición del método AI-DLC y AWS lo anuncia en el blog de DevOps. Diez principios, tres fases, nada de código.
- nov. 2025Open source como archivos de reglas
AWS libera los workflows como reglas de Amazon Q Developer y steering files de Kiro. El agente lee las reglas y sigue el ciclo.
- ene. a abr. 2026La serie 0.1
Nueve releases endurecen el workflow guiado por reglas.
- 19 jun. 2026Versión 1.0.0
La primera release estable. La 1.0.1 llega el 30 de junio y queda como la última de la línea.
- 1 sept. 2026Versión 2.7.0
La primera release estable de la línea 2.x. La línea 2.x se construyó aparte; ninguna release de 2.0 a 2.6 salió como estable.
- 24 sept. 2026Versión 2.10.0
Checkpoints de construcción más fuertes, harnesses que conviven en el mismo proyecto, arreglos de worktree. Las previews de la 2.10.1 salen casi todos los días.
El número de versión ya cuenta una historia. AWS saltó directo de la 1.0.1 a la 2.7.0, lo que significa que la línea 2.x pasó meses madurando en paralelo antes de que a alguien se le pidiera depender de ella. Cuando llegó a la rama principal ya iba por su séptima versión minor.
AI-DLC 2.10.0 en números
- 33
- etapasen 5 fases
- 14
- agentes11 especialistas, 2 revisores, 1 composer
- 11
- perfiles de workflowmás un composer para rutas a medida
- 108
- tipos de evento de auditoríaen un log de solo agregado
El motor decide, el modelo ejecuta
De todo lo que cambió en la versión 2, este es el cambio que yo pondría en la caja. La versión 1 eran archivos de reglas: prosa que el agente leía y en la que se confiaba que la seguiría. El agente decidía qué etapa venía después, si se podía saltar un paso, si su propia salida era lo bastante buena y qué decía el archivo de estado. Cuando se desviaba, nada lo frenaba salvo una persona cansada en un gate. De ahí nace el slop: un modelo que elige su propia ruta, se corrige su propia tarea y edita sus propios registros.
La versión 2 divide el trabajo en dos. Un motor determinístico, código común con un puñado de subcomandos, es dueño de la ruta: qué etapa corre después, qué perfil aplica, cuándo parar, qué está esperando un gate. Emite una instrucción tipada, y el conductor (la sesión de /aidlc, que es el LLM) la ejecuta y reporta. El modelo sigue haciendo el razonamiento dentro de la etapa. Lo que ya no decide es la forma del proceso. La propia documentación de AWS lo resume en una frase: el motor es dueño de la ruta, el conductor es dueño de la calidad de la ejecución.
Poderes que el modelo tenía en la versión 1, y quién los tiene en la versión 2
| En la versión 1 el modelo podía | En la versión 2 |
|---|---|
| Decidir qué etapa sigue, o saltarse una | El motor enruta desde un grafo de etapas compilado cuando empieza el workflow. Una etapa saltada queda registrada como saltada. |
| Decir que las pruebas pasaron | Una Unit solo queda verificada por el comando de chequeo que aprobó una persona, y solo mediante un recibo que escribe la herramienta. Un archivo de prueba escrito a mano no verifica una Unit. |
| Evaluar su propio artefacto | Agentes revisores separados lo juzgan, atados a una huella digital del artefacto, así que el trabajo modificado no hereda una aprobación anterior. Sensores determinísticos (linters, chequeo de tipos) se disparan sobre la salida. |
| Editar el estado del workflow | Un guard impide que las herramientas del modelo escriban los registros de sesión y de aprobación de planes. El estado avanza a través del motor. |
| Aprobar su propio gate | Un gate que se te presenta necesita un mensaje real tuyo. El guard de presencia humana no se puede bajar por workflow. |
| Cambiar las reglas a mitad de camino | Reglas, etapas y sensores se compilan una vez por workflow. Una regla nueva aplica la próxima vez. |
| Perder los vínculos entre artefactos | Gates de verificación automáticos chequean la trazabilidad entre fases antes de que la siguiente construya encima. |
Nada de esto hace más inteligente al modelo. Hace que el proceso dependa menos de que el modelo se porte bien, que es un objetivo distinto y mejor. Es la misma lección a la que siempre llego en harness engineering: un chequeo determinístico que rompe el build vale más que un párrafo de instrucciones que el agente puede ignorar. AWS solo lo aplicó al ciclo completo. Hasta el empaquetado sigue la regla: cada harness recibe el mismo motor, y el build que produce las siete distribuciones corre dos veces y compara la salida byte a byte.
El ciclo de vida sumó dos fases
La versión 1 tenía las tres fases del whitepaper. Inception convertía una intención en requisitos, historias y Units de trabajo. Construction convertía cada Unit en diseño, código y pruebas. Operations desplegaba y vigilaba el sistema en marcha. Una persona aprobaba cada paso.
AI-DLC versión 1
- 01
Inception
Mob Elaboration: la IA propone, el equipo refina.
- Workspace detection
- Reverse engineering (brownfield)
- Requirements analysis
- User stories
- Workflow planning
- Application design
- Units generation
Gate: Aprobación humana por etapa
- 02
Construction
Mob Construction, por Unit.
- Functional design
- NFR requirements
- NFR design
- Infrastructure design
- Code generation
- Build and test
Gate: Aprobación humana por etapa
- 03
Operations
El whitepaper describe despliegue, monitoreo y acciones de runbook aprobadas. Las reglas de la versión 1 la entregaron como placeholder.
La versión 2 mantiene esas tres y las envuelve. Initialization corre primero, sin ninguna persona, y arma el workspace en menos de un segundo. Ideation corre antes de Inception y pregunta si vale la pena construir la cosa: captura de la intención, investigación de mercado, viabilidad, alcance, formación del equipo, mockups preliminares y una aprobación para seguir. Entre fases, un gate de verificación ahora chequea la trazabilidad solo, así que un requisito huérfano o una historia que no apunta a nada se detecta antes de que la fase siguiente construya encima.
AI-DLC versión 2
- 0.1 a 0.3
Initialization
Workspace, detección, estado. Automático.
- 3 etapas, sin gate
- 1.1 a 1.7
Ideation
¿Vale la pena construir esto?
- Intent Capture
- Feasibility
- Scope Definition
- y 4 más
Gate: Gate de verificación 1
- 2.1 a 2.9
Inception
Requisitos, diseño, Units.
- Reverse Engineering
- Practices Discovery
- Requirements Analysis
- Units Generation
- y 5 más
Gate: Gate de verificación 2
- 3.1 a 3.7
Construction
Diseño, código y pruebas por Unit.
- Functional Design
- NFR Design
- Code Generation
- Build and Test
- y 3 más
Gate: Gate de verificación 3
- 4.1 a 4.7
Operation
Despliegue, observabilidad, retroalimentación.
- Deployment Pipeline
- Observability Setup
- Incident Response
- y 4 más
La etapa nueva de Inception que vale la pena mirar es Practices Discovery. Antes de escribir requisitos, el agente mira cómo ya trabaja tu equipo (postura de pruebas, hábitos de despliegue, estilo de código), lo redacta, pone a otros tres agentes a inspeccionar el borrador por separado, te entrevista sobre los huecos y guarda el resultado en la memoria del equipo. La versión 1 aprendía tus convenciones a fuerza de correcciones. La versión 2 pregunta antes.
Catorce agentes en lugar de una sola voz
La versión 1 era un agente siguiendo steering rules y haciendo los roles que las reglas le indicaban. La versión 2 trae 14 agentes con nombre: 11 especialistas de dominio (producto, diseño, entrega, arquitectura, plataforma AWS, compliance, DevSecOps, desarrollo, calidad, pipeline y despliegue, operaciones), dos revisores y un composer.
AWS llama a la filosofía “Small Mob, Broad Agents”. La alternativa era obvia y equivocada: treinta especialistas angostos, cada uno dueño de un artefacto, pasándose el trabajo en cadena. Eso es waterfall con pasos extra, y cada traspaso pierde contexto. Once agentes amplios que trabajan en varias etapas llevan consigo más del panorama.
La mayoría de las etapas sigue corriendo inline, en tu conversación. Cuatro despachan trabajo: Reverse Engineering como pipeline de dos pasos (un agente de desarrollo recorre el código, un agente de arquitectura escribe la síntesis), Practices Discovery y Code Generation como subagents, y User Stories como mob, donde los agentes de diseño, desarrollo y calidad escriben en paralelo. La cuenta en la 2.10.0 es 29 inline, 2 subagent, 1 pipeline, 1 mob.
Los dos revisores importan más que la cantidad de agentes. Después de que una etapa produce su artefacto, el revisor de producto juzga requisitos e historias, y el revisor de arquitectura juzga el diseño técnico. Una revisión adversarial puede devolver el trabajo hasta dos veces. Y ahí se detiene y te entrega los hallazgos, porque el revisor nunca bloquea. Decide la persona. Esa regla es el método entero en una línea, y me alegra que AWS la haya escrito en el motor en lugar de dejarla a la buena voluntad.
Perfiles en lugar del ciclo de talla única
El décimo principio del whitepaper decía que ningún workflow debía ser rígido: la IA propone la profundidad, la persona la ajusta. La versión 1 lo implementó como un juicio dentro de las reglas. La versión 2 lo convirtió en 11 perfiles de workflow con nombre (el motor los llama scopes), cada uno una ruta fija por las 33 etapas, con profundidad y estrategia de pruebas por defecto.
Los perfiles que vas a usar primero
| Perfil | Etapas | Para qué sirve |
|---|---|---|
| Classic | 18 / 33 | La ceremonia de la versión 1: Inception y Construction, una aprobación por etapa. El valor por defecto del motor si no eliges nada. |
| Express | 10 / 33 | Requisitos ya entendidos. El camino más corto a código y pruebas. |
| Feature | 33 / 33 | Una feature de producción por todo el ciclo, con profundidad estándar. |
| Bugfix | 9 / 33 | Un defecto conocido, una reparación enfocada, una prueba de regresión y el despliegue. |
Classic es el camino de migración, y AWS lo hizo el valor por defecto a propósito. Un equipo que conoce la versión 1 puede empezar en la versión 2 sin aprender una ceremonia nueva. Profundidad y estrategia de pruebas ahora son perillas separadas (Minimal, Standard, Comprehensive), y puedes girar cualquiera sin cambiar de perfil.
Las correcciones se vuelven reglas: el loop de aprendizaje
Esta es la función por la que yo habría pagado. La versión 1 olvidaba. Corregías al agente el lunes, y el jueves, en un workflow nuevo, cometía el mismo error, porque nada llevaba la corrección hacia adelante salvo tu propia memoria.
La versión 2 lleva un diario por cada etapa, un archivo llamado memory.md, con cuatro secciones: Interpretations, Deviations, Tradeoffs y Open questions. Cuando el agente toma una decisión que las instrucciones de la etapa no cubrían, la anota. En el gate de aprobación, el motor te muestra esas líneas tal cual y pregunta si quieres conservar alguna, más un campo libre: “Anything to add for next time?”.
Cómo una corrección se vuelve regla
Entrada
Corriges al agente durante una etapa
- DIARYEl agente registra la decisión que tomó
El memory.md de la etapa suma una entrada en Interpretations, Deviations, Tradeoffs u Open questions.
- GATEEl gate te muestra los candidatos
Las líneas aparecen tal como se escribieron, sin paráfrasis. Marcas las que vale la pena conservar y puedes sumar las tuyas.
- CHECKUn chequeo de conflicto contra las reglas de la organización
Si la línea nueva contradice una regla de la organización, la revisas, la descartas o la escalas.
- WRITELa línea conservada va a la memoria del proyecto
Va a project.md, y un clic la promueve a team.md. Las Open questions nunca se vuelven reglas.
Salida
La regla aplica desde la primera etapa del próximo workflow. Nunca a mitad del actual.
La documentación recorre un ejemplo real. En un proyecto bancario, una nota de un stakeholder decía “la transacción no debería duplicarse en un reintento”. El agente de producto leyó “transacción” como transacción de base de datos y escribió un requisito ACID. La persona se refería a un pago y lo corrigió, el diario registró la interpretación y la regla conservada fijó el término para todos los workflows siguientes.
El último detalle es el que muestra que alguien lo pensó. Un aprendizaje nunca cambia las reglas a mitad de la corrida. El motor compila etapas, reglas y chequeos una vez, cuando empieza el workflow, y mantiene esa vista compilada hasta el final. Los gates que aprobaste antes certificaron un conjunto estable de reglas, y el piso no se mueve debajo de un workflow en curso.
Reglas y sensores: AWS ahora habla de harness engineering
La versión 2 divide la conducción en dos mitades. Las reglas son instrucciones en prosa que se cargan antes del trabajo (feedforward). Los sensores son chequeos determinísticos que se disparan sobre la salida, como un linter o un chequeo de tipos (feedback). AWS llama al par control loop.
Las reglas se resuelven en cinco capas, y el modelo es estrictamente aditivo: todas las capas aplicables están en el contexto a la vez, y nada pisa a nada en silencio.
Las cinco capas de reglas
- ORG
Organización
Valores por defecto del framework y de la empresa: trunk-based development, postura de pruebas, política de walking skeleton.
- TEAM
Equipo
Prácticas que tu equipo confirmó, incluidas las que encontró Practices Discovery.
- PROJ
Proyecto
La especialización de este proyecto. Es donde escribe el loop de aprendizaje por defecto.
- PHASE
Fase
Reglas para todas las etapas de una fase, como documentar dos alternativas para cada decisión de arquitectura en Inception.
- STAGE
Etapa
Reservada para una release futura.
El repositorio incluso trae una Harness Engineer Guide para remodelar etapas, agentes, reglas, sensores y conocimiento sin tocar el código del motor. Hace meses que sostengo que el harness es donde vive tu ventaja. Fue bueno ver a AWS poner la palabra en su propia documentación.
Construction ganó checkpoints verificados
La versión 1 pedía aprobar cada etapa de Construction en cada Unit. En una feature con seis Units y cinco etapas cada una, son treinta aprobaciones, la mayoría sobre documentos de diseño que nadie leería dos veces. La fatiga de aprobación fue una de las primeras cosas que se rompieron en los pilotos que seguí.
La versión 2 cambió el valor por defecto para el trabajo solo nuevo con Units. Construye una Unit a la vez, en orden de dependencias, y te pide aprobar cada Unit terminada en un checkpoint verificado en lugar de aprobar cada documento intermedio. Verificado significa algo concreto: en Delivery Planning, el agente propone un chequeo real del proyecto (bun test, pytest, make check), tú apruebas ese comando exacto, y el motor lo reutiliza en cada checkpoint. Cambiarlo después requiere tu aprobación de nuevo. Un archivo de prueba escrito a mano no verifica una Unit.
Lo que Construction te pregunta en la versión 2
- Obligatorio:Aprobar el plan de cada Unit antes de generar código.La aprobación de plan sigue siendo humana en cualquier modo.
- Obligatorio:Aprobar el comando de verificación, una vez.Se reutiliza en cada checkpoint. Cambiarlo requiere una nueva aprobación humana.
- Obligatorio:Aprobar el walking skeleton, cuando está activado.La primera Unit es la porción más chica que funciona de punta a punta, verificada por el comando antes de que empiecen las demás.
- Opcional:Elegir: seguir automáticamente o revisar cada checkpoint.El modo automático se salta las preguntas de rutina al terminar. Nunca se salta la aprobación de plan, el comando ni las fallas.
- Obligatorio:Decidir ante cada falla.Una Unit que falla detiene Construction y ofrece retry, skip o abort, incluso en modo automático.
También existe un modo de equipo. Con la propiedad de las Units configurada como de equipo, las personas reclaman Units y las construyen en sus propios checkouts al mismo tiempo, cada una con su ritmo de gates. La versión 1 no tenía nada parecido. Los equipos que querían construcción en paralelo tenían que inventarla.
Guards, y quién puede bajarlos
La versión 2 agrega una Guard Policy por pieza de trabajo, con tres valores: strict, relaxed y off. Controla cinco cercas: aprobación de plan, congelamiento de review, transición de estado, alcance de lectura del revisor y presencia humana. Enterprise viene en strict. Los demás perfiles vienen en off, lo que deja que cuatro de las cercas se hagan a un lado en el trabajo sin dirección explícita, y cada vez que una cerca se hace a un lado el log de auditoría lo registra.
La quinta cerca es la interesante. La presencia humana no se puede bajar para un workflow puntual. Un gate que se te presenta necesita un mensaje real tuyo. La única forma de evitarlo es una variable de entorno que vale para toda la máquina, que es el nivel justo de fricción para “que el agente apruebe su propio trabajo”.
Multi-repo ahora es nativo
La versión 1 era de repositorio único. Una feature real casi nunca lo es: un back-end, un front-end, tal vez una app móvil, cada uno en su repo. Los equipos que seguí lo resolvían corriendo una sesión por stack y apuntando al agente al directorio del otro repo como material de referencia, con el contrato entre ellos acordado a mano de antemano.
La versión 2 soporta intents multi-repo. Declaras el conjunto de repositorios al crear la intent (o dejas que el motor descubra los repositorios hermanos), Construction ancla cada operación de git a un repo específico, y Reverse Engineering tiene que completar una cadena de escaneo entera por repositorio antes de que se pueda aprobar la etapa. El parche se volvió una flag.
El registro ahora es algo que puedes consultar
Cada intent tiene su propia carpeta de registro en aidlc/spaces/<space>/intents/. Adentro: el archivo de estado, con un checkbox de seis estados por etapa (sin empezar, en curso, esperando aprobación, en revisión, completada, saltada), todos los artefactos, todos los archivos de preguntas y un log de auditoría de solo agregado con 108 tipos de evento. La versión 1 también tenía archivo de estado y archivo de auditoría. La versión 2 los convirtió en la fuente de verdad del motor y sumó un runtime graph compilado a partir del log de auditoría en cada transición.
Eso vuelve medible el workflow sin herramientas nuevas. /aidlc-session-cost muestra duración, resultado de las etapas y aprendizajes. /aidlc-replay narra la sesión para quienes no estuvieron. aidlc attest te dice si el contenido de un commit sigue coincidiendo con lo que aprobó un revisor. Escribí sobre cómo usar esos datos en después de los story points.
Qué dejó obsoleto AI-DLC 2
Ahora la parte que las notas de release no cuentan.
El equipo que seguí más de cerca mantenía un overlay sobre la versión 1: un conjunto de extensiones, comandos y parches que adaptaban el método a la organización. Era buen trabajo, hecho por gente que corría el método todos los días y arreglaba lo que dolía. Después llegó AI-DLC 2 y entregó la mayor parte como nativo.
Lo que los equipos construyeron sobre la versión 1, y lo que trae la versión 2
| Capa casera sobre la versión 1 | Nativo en la versión 2 |
|---|---|
| Un archivo de estado compartido que cada skill personalizada leía y actualizaba, para que una sesión nueva pudiera retomar después de limpiar el contexto | Una máquina de estados con checkboxes de seis estados, un breadcrumb de recuperación antes de la compactación y /aidlc --resume |
| Parches inyectados en las reglas del core sin hacer fork | Un sistema de plugins que solo agrega, nunca edita el core, con comandos de validate, build y sync |
| Una retrospectiva automática después de Build and Test que buscaba dónde había fallado la IA | El loop de aprendizaje: diarios por etapa, candidatos en el gate, reglas que aplican en el próximo workflow |
| Un plan para paralelizar la construcción con git worktrees | Ejecución en swarm con un worktree por Unit, y modo de equipo con reclamo de Units |
| Correr una sesión por stack y apuntar al otro repo a mano | Intents multi-repo con reverse engineering por repositorio |
| Archivar los artefactos de cada tarea terminada para arrancar la siguiente en limpio | Carpetas de registro por intent, spaces y comandos de archivo de intents |
Esto pasa con cada capa de plomería que construyes sobre un framework que se mueve rápido. Si el hueco es genérico, el proveedor ve el mismo hueco en todos sus clientes y lo entrega. Tu traspaso de estado ingenioso se vuelve su función, y tu código se vuelve trabajo de migración.
Qué sobrevivió a la reescritura
Esta es la lista de lo que no fue absorbido, y es la lista que yo protegería.
Lo que la versión 2 no reemplazó
- Obligatorio:Las reglas contra el vibe coding.Nunca editar a mano el código generado. Pedir el impacto antes de un cambio grande. Pedir la crítica en un contexto limpio. Nacieron de ver fallar al agente, y ningún motor las codifica por ti.
- Obligatorio:El ritual antes del código.Cómo toma forma una intención antes de que AI-DLC la vea: el documento de entrada, las fuentes curadas, el triage de complejidad. Ideation ayuda. Igual asume que alguien conoce el problema.
- Obligatorio:Quién se sienta en el mob.Solo quien tiene poder de decisión sobre alguna dimensión del trabajo. La versión 2 tiene una etapa de Team Formation; no sabe quién decide en tu empresa.
- Obligatorio:El ritmo.Sesiones de una hora, managers en los primeros mobs, pausas entre gates. La versión 2 mejoró los gates. La gente cansada sigue aprobando cualquier cosa.
- Obligatorio:El conocimiento propio de la organización.Las librerías internas que hay que inyectar antes de generar código, los registros de decisiones, dónde vive la documentación confiable.
- Obligatorio:Saber cuándo no usarlo.Un cambio de una línea no necesita AI-DLC, en ninguna versión.
Entonces la lección para quien adopta un framework de IA en 2026: construye criterio, alquila plomería. Invierte tu tiempo de ingeniería en las partes que codifican cómo decide tu organización, y mantén delgada la maquinaria genérica, porque el proveedor está a punto de entregarla. Es el argumento de no adoptes AI-DLC, róbale, y la versión 2 es su prueba más fuerte.
¿Conviene migrar desde la versión 1?
Si tienes un workflow en curso en la versión 1, termínalo, y empieza la próxima intent en la versión 2. La propia versión 2 se niega a actualizar un proyecto mientras haya un workflow activo, lo que dice mucho de cómo piensa AWS sobre mover el piso debajo del trabajo en curso.
Elige Classic para esa primera corrida. Reproduce la ceremonia de la versión 1 en 18 de las 33 etapas, así que tu equipo aprende el motor nuevo sin aprender además un proceso nuevo. Cuando Classic se vuelva rutina, prueba Feature en un cambio real de producción y activa el walking skeleton.
Y antes de portar tus capas caseras, sepáralas en las dos listas de arriba. La plomería probablemente ya tiene un equivalente nativo; bórrala. El criterio no; llévalo a reglas, a la memoria del equipo o a un plugin que solo agrega. El setup en sí está en AI-DLC con Claude Code, y si tu código es viejo y grande, lee antes AI-DLC en brownfield.
Preguntas frecuentes
¿Cuándo salió AI-DLC 2?
La primera release estable de la línea 2.x, AI-DLC 2.7.0, se publicó el 1 de septiembre de 2026. La 2.8.0 llegó el 8 de septiembre, la 2.9.0 el 15 de septiembre y la 2.10.0 el 24 de septiembre. Las versiones 2.0 a 2.6 nunca salieron como releases estables.
¿AI-DLC 2 es compatible con los workflows de la versión 1?
No como reemplazo directo. La versión 2 es otra instalación, un comando nativo aidlc más los runtimes de cada harness, y guarda el estado en carpetas de registro por intent.
Termina los workflows de la versión 1 que están en curso donde están y empieza las intents nuevas en la versión 2. El perfil Classic reproduce la ceremonia de la versión 1, así que el proceso se siente familiar.
¿Cuál es la diferencia entre los perfiles Classic y Feature?
Classic corre 18 de las 33 etapas: Inception y Construction con una aprobación por etapa, saltándose Ideation y Operation, como en la versión 1. Feature corre las 33 etapas con profundidad estándar, desde la captura de la intención hasta el despliegue y la retroalimentación.
¿AI-DLC 2 todavía requiere Kiro o Amazon Q?
No. La versión 2 corre un solo motor en siete harnesses: Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode y GitHub Copilot. El README recomienda Claude Opus 4.8 como modelo.
¿Qué es el loop de aprendizaje de AI-DLC?
Cada etapa lleva un diario de las decisiones que tomó el agente. En el gate de aprobación eliges cuáles conservar, y las conservadas se vuelven reglas en la memoria del proyecto o del equipo. Aplican desde el inicio del próximo workflow, nunca a mitad del actual.
¿AI-DLC 2 es open source?
Sí. Los workflows están publicados en github.com/awslabs/aidlc-workflows bajo la licencia MIT-0. Solo pagas el modelo que usa tu agente de código.
A dónde ir ahora
AI-DLC 2 ya es un motor de verdad, y cerró la mayoría de los huecos que hacían difícil correr la versión 1 a escala. Úsalo. Pero fíjate en lo que absorbió y en lo que dejó afuera, porque esa línea te dice adónde debe ir tu propio trabajo.
La newsletter
Don’t Code, Specify. Cada semana, agentes de IA en producción de verdad. Sin hype: lo que funcionó y lo que se rompió.
Suscríbete en Substack (se abre en una pestaña nueva)