No adoptes AI-DLC. Róbale.

El framework más maduro para construir con agentes se diseñó para otro. Llévate lo que sirve para tu problema. Deja la doctrina en el estante.

AI-DLC es la mejor respuesta pública que conozco a la pregunta que todo líder de ingeniería se está haciendo ahora: cómo construir software con agentes de IA sin perder el control de lo que llega a producción. AWS publicó el método en 2025. En septiembre de 2026 lanzó AI-DLC 2, un motor que instala un ciclo de 33 etapas dentro del agente de código que tu equipo ya usa.

Aun así no le diría a un equipo que lo adopte.

Pasé los últimos meses dentro de una gran organización de ingeniería donde AI-DLC pasó de unos pocos squads piloto a un programa de formación para las personas que lo van a llevar a todos los equipos. El método funcionó donde la gente lo trató como material para construir. Se trabó donde lo trataron como doctrina a cumplir. La diferencia nunca fue la herramienta. Fue la postura.

Adoptar un nombre es adoptar los problemas de otros

Imagina la reunión. Un líder que leyó el whitepaper anuncia que desde el próximo trimestre la organización hace AI-DLC. Suena decidido. Mira lo que pasa después.

La gente se pone a estudiar. Lee el paper, mira las charlas, abre el repositorio e intenta reproducir lo que encuentra ahí. El método describe un ciclo de 33 etapas, rituales de mob, 14 agentes y un vocabulario nuevo: Intents (lo que el trabajo tiene que lograr), Units (partes de la solución que se pueden construir solas) y Bolts (porciones de entrega medidas en horas). Así que eso es lo que intentan instalar. En pocas semanas el equipo está corriendo ceremonias pensadas para un problema que no tiene, y dejando de lado el único problema que sí tiene, porque el paper no lo mencionaba.

AWS y tu empresa son animales distintos. El método lo moldeó un proveedor que vende infraestructura en la nube a clientes grandes, muchas veces regulados, muchos de ellos sobre el propio stack de AWS. Uno de sus 14 agentes es especialista en plataforma AWS. Su perfil Enterprise corre todas las etapas en el nivel más profundo. Es el diseño correcto para quienes lo escribieron. Para ti es un punto de partida, no un destino.

Trátalo como la góndola de un supermercado

Una góndola de supermercado no te pide que te lleves todo lo que hay en ella. Pasas, tomas lo que necesita la cena de hoy y dejas el resto para quien tiene otra receta. Nadie le llama elegir a conveniencia. Le llama hacer las compras.

AI-DLC merece ese trato, porque es una muy buena góndola. Tiene mecanismos que resuelven problemas reales con agentes, y casi todos funcionan solos, fuera del ciclo completo. Llevarte uno no te obliga a llevarte los demás.

La primera vez que apliqué esto fue en una conversación sobre cómo llevar el método a una parte de la organización que no estaba lista para él. En lugar de importar AI-DLC entero, lo separamos en variables: quién se sienta en el mob, qué tamaño tiene una tarea, qué combinación de rituales necesitaba cada equipo. Terminamos con cuatro o cinco configuraciones de partida en lugar de una doctrina. Cada equipo eligió la que coincidía con su madurez. Nadie tuvo que fingir que era un squad piloto.

Qué llevarte primero

Estos son los mecanismos que se pagaron solos, más o menos en el orden en que yo los tomaría.

Llévate estos

• ✓Obligatorio:
  Artefactos que viven en el repo.Requisitos, decisiones y planes como archivos versionados que el agente lee en cada sesión. Es la idea más valiosa del método, y funciona con cualquier herramienta.
• ✓Obligatorio:
  Un gate humano entre pasos.El agente produce, una persona aprueba o pide cambios, y recién entonces empieza el siguiente paso. El whitepaper llama a cada gate una función de pérdida: atrapa una decisión equivocada donde revertirla es barato.
• ✓Obligatorio:
  Deja que la IA haga las preguntas.Dale la intención al agente y responde lo que pregunte, en lugar de intentar escribir el prompt perfecto. Las preguntas que hace son las que un dev se encontraría a mitad de la implementación.
• ✓Obligatorio:
  Profundidad proporcional al trabajo.Un bugfix no necesita un modelo de dominio. AI-DLC 2 lo codifica en 11 perfiles de workflow, desde una proof of concept de 8 etapas hasta las 33. Róbate el principio aunque nunca instales el motor.
• •Opcional:
  Porciones medidas en horas.Bolts en lugar de sprints de dos semanas. Tómalo cuando el equipo especifique lo bastante bien como para que el agente entregue una porción sin esperar una reunión.
• •Opcional:
  Un loop de aprendizaje.Convierte cada corrección que haces en una regla que el agente lee la próxima vez. AI-DLC 2 lo hace con un diario por etapa y una confirmación en el gate. Un archivo simple con las reglas del equipo es un buen comienzo.

Qué dejar en el estante, al menos por ahora

La otra mitad de hacer las compras es pasar de largo.

Deja estos, por ahora

• ✗Anti-pattern:
  Las 33 etapas el primer día.Empieza con el perfil Classic, que es la ceremonia de la versión 1: Inception y Construction, una aprobación por etapa. Suma fases cuando un problema real las pida.
• ✗Anti-pattern:
  Renombrar todo.Llamar bolts a los sprints e intents a las épicas no cambia el trabajo. Cambia el trabajo primero. Las palabras pueden venir después, o nunca.
• ✗Anti-pattern:
  Un mob para cada tarea.Mob Elaboration se paga cuando una decisión necesita a varias personas. Una tarea que un ingeniero puede especificar solo no necesita una sala.
• ✗Anti-pattern:
  Los agentes que no te sirven.Si no corres en AWS, el agente de plataforma AWS y los servidores MCP de AWS son ruido. Si no tienes un régimen de compliance, el agente de compliance es ceremonia.
• ✗Anti-pattern:
  La expectativa de entrega instantánea.El método empeora el cycle time antes de mejorarlo. Los líderes que adoptan la etiqueta suelen adoptar también la promesa, y después matan el rollout en el fondo de la curva.

Escribe qué te llevaste y por qué

La metáfora de la góndola tiene una trampa: hacer las compras sin lista. Si cada equipo se lleva un puñado distinto de mecanismos y nadie lo escribe, dentro de un año tienes veinte dialectos privados de AI-DLC y ninguna forma de compararlos.

Así que la guía que escriba tu organización debería abrir con dos listas, y cada ítem de las dos listas debería llevar su origen.

## What we took from AI-DLC

- Artifacts versioned in the repo, read by the agent every session
  Origin: AWS method, principle "artifacts as context memory"
- Human approval gate after each artifact
  Origin: AWS method; we kept "Approve / Request Changes"
- Sessions capped at one hour, context cleared at each gate
  Origin: our pilot, after approvals degraded in long sessions

## What we did not take, and why

- Ideation phase: product discovery already runs elsewhere
  Revisit when: a squad without a product partner adopts the method
- AWS platform agent: we run on another cloud
- Full 33-stage route: Classic profile covers our first quarter

La regla que aplico a estas guías es tajante: si un ítem no tiene origen, no entra. Cada práctica vino del método de AWS, de otro framework o de tu propio piloto. Escribirlo es lo que separa una decisión de un rumor, y le dice a la próxima persona qué puede cambiar.

AI-DLC 2 acaba de demostrarlo

Aquí está el argumento más fuerte a favor de esta postura, y llegó en septiembre de 2026.

Los equipos que adoptaron la versión 1 de AI-DLC construyeron encima de ella. Tuvieron que hacerlo. La versión 1 era un conjunto de archivos de reglas, y los equipos reales necesitaban más que eso, así que escribieron sus propias capas: extensiones que se cargaban por opt-in, retrospectivas que corrían al final de cada tarea, construcción en paralelo con git worktrees, parches inyectados en las reglas del núcleo, disciplina para limpiar el contexto y retomar el trabajo. Algunas de esas capas eran obras de ingeniería impresionantes.

Después salió AI-DLC 2, y buena parte de esa plomería se volvió nativa.

Lo que los equipos construyeron sobre la versión 1, y lo que trajo AI-DLC 2

Verificado contra AI-DLC 2.10.0, la release actual al 1 de octubre de 2026.

Hecho en casa sobre la versión 1	Nativo en AI-DLC 2
Control de estado propio y reanudación después de limpiar el contexto	Un archivo de estado por intent, un log de auditoría de solo agregado con 108 tipos de evento, y recuperación cuando el agente comprime su contexto a mitad de sesión
Retrospectivas que corren cuando termina una tarea	Un loop de aprendizaje: un diario por etapa, candidatos confirmados en el gate, reglas aplicadas en la próxima corrida
Construcción en paralelo con git worktrees	Ejecución en swarm: Units con sus dependencias listas construidas en worktrees paralelas, con checkpoints por lote
Parches inyectados en las reglas del núcleo	Un sistema de plugins que solo agrega al núcleo y nunca lo edita
Un solo workflow, recortado a mano en cada tarea	11 perfiles de workflow más un agente composer que propone una ruta a medida

Los equipos que habían adoptado la versión 1 como doctrina pasaron a mantener una doctrina más una pila de parches caseros que el proveedor acababa de volver obsoletos. Los equipos que la habían tratado como góndola no perdieron nada importante, porque la plomería nunca fue el punto.

Lo que sobrevivió a la actualización fue todo lo que codificaba el criterio de la propia organización. Las reglas contra el vibe coding que un equipo piloto aprendió por las malas. El ritual para darle forma a una buena intención antes de que alguien escriba un requisito. El sentido de qué tareas no merecen el método. Nada de eso vino en AI-DLC 2, porque nada de eso podía venir. Les pertenece a las personas que lo aprendieron.

Sé dueño del criterio, alquila la plomería

La lección va más allá de AI-DLC. Cuando construyes sobre un framework que cambia rápido, separa lo que escribes en dos pilas.

Plomería: que la cuide el proveedor

1. 01Control de estado y reanudación
2. 02Orquestación de agentes y etapas
3. 03Ejecución en paralelo y worktrees
4. 04Logs de auditoría y chequeos de trazabilidad

Criterio: quédatelo

1. 01Tus reglas sobre lo que el agente nunca debe hacer
2. 02Cómo tus equipos le dan forma a una intención antes del primer requisito
3. 03Qué trabajo pasa por el método y cuál no
4. 04Qué revisan tus revisores en cada gate

Si tienes que extender el framework, hazlo en sus costuras. AI-DLC 2 trae un mecanismo de plugins que puede agregar etapas, agentes, reglas y chequeos sin editar el núcleo, así que tus agregados sobreviven a la próxima release. Escribí sobre la misma disciplina para dependencias en own the seam: un cambio que vive en el punto de extensión declarado se versiona y sobrevive a las actualizaciones, mientras que un parche esparcido por el núcleo se vuelve a aplicar a mano después de cada release, hasta que alguien se olvida.

Cuándo adoptarlo entero es lo correcto

Ser honesto con las excepciones hace la regla más fuerte.

Adopta AI-DLC casi entero cuando tu organización se parece a los clientes para los que fue diseñado: muchos equipos, trabajo regulado, necesidad de trazabilidad completa desde la intención hasta producción, y un stack en AWS. El perfil Enterprise existe exactamente para eso, e inventar tu propia versión sería desperdicio.

Adóptalo casi entero cuando tus equipos no tienen ningún proceso. Un método completo y documentado le gana a uno improvisado, y el modo workshop existe para enseñarlo.

E incluso así, adóptalo con las adaptaciones por escrito. Una persona de liderazgo sénior con la que trabajé lo resumió bien: adoptar el framework entero es una buena opción, siempre que los cambios que hagas sean explícitos y deliberados. La falla nunca es adoptar demasiado. Es adoptar sin decidir.

Preguntas frecuentes

¿Tomar solo partes de AI-DLC no es elegir a conveniencia?+

Elegir a conveniencia es tomar las partes fáciles y saltarse las difíciles sin decirlo. Esto es lo contrario: tomas los mecanismos que resuelven un problema que puedes nombrar, escribes qué dejaste y por qué, y revisas la lista. Los artefactos persistentes y los gates, los hábitos más difíciles, son lo primero de la lista.

¿Vamos a perder las actualizaciones si personalizamos AI-DLC?+

No, si personalizas en las costuras. AI-DLC 2 tiene un mecanismo de plugins que solo agrega al núcleo, más archivos de reglas a nivel de organización, equipo y proyecto. Los cambios hechos ahí sobreviven a las releases. Los que se parchan en los archivos del núcleo son los que se pierden.

¿Deberíamos llamar AI-DLC a nuestro proceso internamente?+

Llámalo como ayude a que la gente encuentre la guía. Solo evita que el nombre se vuelva el objetivo. Si la gente oye el nombre y se va a estudiar el paper de AWS en lugar de tu documento de dos listas, el nombre está jugando en tu contra.

¿Quién decide qué tomar?+

Las personas que corren los primeros pilotos, con alguien que sea dueño de la guía. Las prácticas que vienen de un piloto real traen evidencia. Las que vienen de un slide traen esperanza. Escribe el origen al lado de cada una.

¿Esto es un argumento contra AI-DLC?+

No. Es un argumento para usarlo bien. AI-DLC es el framework público más completo para construir con agentes, y la mayoría de sus mecanismos vale la pena tomarlos. La idea es tomarlos a propósito.

A dónde ir ahora

Los frameworks envejecen. AI-DLC 2 volvió obsoleto un año de plomería casera en una sola release, y AI-DLC 3 lo va a hacer de nuevo. Lo que no envejece es lo que tus equipos aprendieron sobre su propio trabajo. Llévate los mecanismos, quédate con el criterio, y escribe cuál es cuál.