AI-DLC vs Spec-Driven Development: por qué necesitas SDD primero

AI-DLC le pide a una persona que juzgue una spec en cada gate. Un equipo que nunca escribió una spec no puede juzgar una.

La gente busca “AI-DLC vs Spec-Driven Development” como si tuviera que elegir uno. Es la pregunta equivocada, y responderla tal como viene es la forma en que un equipo termina corriendo un ciclo de 33 etapas que no puede operar.

Spec-Driven Development (SDD) es una práctica: antes de que un agente construya cualquier cosa, escribes lo que tiene que hacer, y verificas el resultado contra lo que escribiste. AI-DLC, el AI-Driven Development Life Cycle que AWS publicó en 2025 y lanzó como motor instalable en 2026, es un ciclo de vida completo: fases, rituales, agentes y gates de aprobación humana, de la primera idea a producción. Uno es un hábito. El otro es una organización construida sobre ese hábito.

Escribo specs para agentes desde hace más de un año, incluidas las de las 13 apps que construí en 70 días. En los últimos meses también estuve dentro de una gran organización de ingeniería viendo cómo AI-DLC pasaba de los squads piloto a las personas que lo van a llevar a todos los equipos. Los equipos que sufrieron no eran los que tenían la herramienta equivocada. Eran los que se habían saltado el hábito.

SDD es una práctica, AI-DLC es un ciclo de vida

La forma más rápida de ver la diferencia es ponerlos lado a lado en lo que un equipo hace de verdad.

Dos capas, no dos opciones

SDD cabe dentro de AI-DLC. AI-DLC no cabe dentro de SDD.

Dimensión	Spec-Driven Development	AI-DLC
Qué es	Una disciplina para una pieza de trabajo: especificar, generar, verificar.	Un ciclo de vida completo para un equipo: 5 fases, 33 etapas, gates entre ellas.
Quién conduce	Tú escribes la spec. El agente construye desde ella.	La IA propone el plan y hace las preguntas. Tú decides en los gates.
Artefacto principal	Requisitos, diseño y tareas, versionados junto al código.	Un registro por intent: requisitos, historias, ADRs, Units, planes, estado, log de auditoría.
Rituales	Ninguno obligatorio. Con un gate por documento alcanza.	Mob Elaboration, Mob Construction, gates de aprobación, gates de verificación.
Alcance	Funciona para un dev y una feature.	Se paga cuando el trabajo necesita decisiones de varias personas.
Comienzo útil más chico	Tres archivos markdown y un agente.	Un motor instalado, un repo legible para un agente y un equipo que ya especifica.

Lee la última fila dos veces. SDD es algo que puedes empezar esta tarde. AI-DLC es algo que puedes empezar cuando SDD ya es normal, y no antes.

Cada gate de AI-DLC es una revisión de spec

Recorre las paradas de una corrida de AI-DLC y cuenta cuántas son una persona leyendo una especificación y decidiendo si está bien.

En Inception, la fase en la que se define el trabajo, el agente escribe los requisitos, y tú los apruebas. Redacta las user stories, y tú las apruebas. Propone un domain design con decisiones de arquitectura, y tú lo apruebas. Divide el trabajo en Units, las piezas que se pueden construir de forma independiente, y tú apruebas la división. En Construction, la fase en la que se construye, escribe un plan para cada Unit antes de escribir una línea de código, y tú apruebas el plan. Cada uno de esos gates es el mismo acto: juzgar una spec.

Ese acto es una habilidad. Significa notar un requisito sin criterio de aceptación, una historia que esconde dos features, un diseño que está bien localmente y mal para el resto del sistema, un plan que toca archivos que no debería. Nadie nace con eso. La gente lo aprende escribiendo specs y viendo a los agentes construir lo equivocado a partir de las vagas.

Qué pasa cuando un equipo se salta el SDD

La falla es silenciosa, y por eso es común. Este es el mecanismo que vi más de una vez.

El equipo instala el workflow y empieza una feature. El agente hace sus preguntas. Nadie en el equipo está acostumbrado a responder con detalle, así que las respuestas salen cortas y vagas. El agente llena los huecos con la suposición más probable, que es el promedio estadístico de todo lo que leyó. El documento de requisitos sale largo, bien formateado y genérico. El equipo lo aprueba, porque parece un documento de requisitos. El diseño sigue el mismo patrón. Después Construction produce código que corre, pasa sus pruebas y no termina de resolver el problema.

Entonces un dev abre el código y lo arregla a mano. La ejecución que debía cargar el agente vuelve a una persona, y ahora esa persona arregla código que no escribió, contra una spec que en realidad no leyó. Eso es más lento que escribir el código desde el principio, y el equipo concluye que AI-DLC no funciona.

El modelo va a satisfacer cualquier especificación que le des, buena o mala. Estadísticamente cae en cualquier punto entre la mejor y la peor versión de lo que quisiste decir. Lo dije en una de las sesiones del rollout, y lo sigo diciendo porque es todo el argumento: la única palanca que lleva al agente hacia la mejor versión es la calidad de la spec, y la calidad de la revisión que la aprobó.

AI-DLC sin el hábito de la spec

1. 01Respuestas vagas a las preguntas del agente
2. 02Requisitos genéricos aprobados porque parecen terminados
3. 03Código que pasa las pruebas y pierde el punto
4. 04Devs parchando a mano el código generado
5. 05"AI-DLC no funciona para nosotros"

AI-DLC encima de SDD

1. 01Respuestas con números, edge cases y alcance negativo
2. 02Requisitos que un revisor puede probar línea por línea
3. 03Código construido contra una spec que alguien leyó de verdad
4. 04Las correcciones vuelven a la spec, no al código
5. 05Los gates atrapan los errores donde son baratos

La escalera del copiloto a AI-DLC

La mayoría de los equipos no necesita elegir entre SDD y AI-DLC. Necesita saber en qué escalón está parado. Esta es la escalera que uso con líderes de ingeniería, y salió de una conversación sobre por qué un rollout completo de AI-DLC llegaba demasiado temprano para la mayoría de los equipos.

Del copiloto a AI-DLC

1. 1

   Scrum con copiloto

   "Autocompletado y chat dentro del proceso que ya corres."

   → Escribes más rápido. La estructura del trabajo no cambia.

2. 2

   Scrum con SDD dentro de la tarea

   "Mantén el sprint. Cuando tomes una tarea, dedica más tiempo a especificar, deja que el agente construya, revisa el resultado."

   → El equipo aprende a escribir y juzgar specs sin cambiar nada más.

3. 3

   SDD con agente supervisado

   "La spec es el contrato. El agente construye desde ella, tú verificas contra ella, y las correcciones vuelven a la spec."

   → Las specs dejan de ser papeleo. La revisión pasa a estar antes del código.

4. 4

   Gestión y ejecución agénticas

   "El agente planifica, descompone y pregunta. Las personas deciden en los gates."

   → Aquí AI-DLC empieza a pagar su ceremonia.

5. 5

   Full agéntico, en bolts

   "El trabajo avanza en porciones de horas en lugar de paquetes de dos semanas."

   → La cadencia para la que se diseñó AI-DLC.

El escalón que importa es el dos. Cuesta casi nada: el sprint se queda, el board se queda, las ceremonias se quedan. El único cambio es dentro de la tarea. Y construye exactamente la habilidad de la que dependen los escalones cuatro y cinco.

La mayoría de los equipos que conozco está en el escalón uno y cree que está cerca de la cima, porque entrega más rápido que el año pasado. Escribir más rápido se siente como progreso. No es lo mismo que poder delegar una unidad completa de trabajo.

Cómo saber en qué escalón estás

Olvídate de la encuesta de autoevaluación. Mira lo que hace el equipo cuando empieza una feature.

¿Listo para AI-DLC?

• ✓Obligatorio:
  Cada feature empieza con una spec escrita antes de cualquier código.No el título de un ticket. Un documento con requisitos, criterios de aceptación y lo que queda fuera del alcance.
• ✓Obligatorio:
  Las specs se revisan antes de la implementación, no después.Si la primera vez que alguien lee la spec es en el code review, estás en el escalón uno con archivos de más.
• ✓Obligatorio:
  Cuando el agente construye lo equivocado, el equipo corrige primero la spec.Parchar el código generado y seguir significa que la spec nunca fue el contrato.
• ✓Obligatorio:
  Quien revisa puede explicar en una frase por qué una spec aprobada está bien.Es exactamente el acto que AI-DLC pide en cada gate. Si la gente no puede hacerlo con sus propias specs, no va a poder con las del agente.
• ✓Obligatorio:
  El repo es legible para un agente.Un AGENTS.md o CLAUDE.md con el stack, los patrones y las librerías prohibidas. Sin eso el agente adivina, y lo que pregunta son trivialidades.
• ✓Obligatorio:
  Alguien es dueño de la decisión de cuándo no usar el método.Una corrección de una línea no necesita un ciclo de vida. Un equipo que pasa todo por el ritual completo no está listo, está actuando.

Lo que SDD le da a AI-DLC y AI-DLC no puede darse solo

AI-DLC es un contenedor. La calidad de lo que entra no es su trabajo. Tres ideas de SDD son las que lo llenan.

La primera es que la spec es memoria externa. Un agente vive en un presente eterno: no recuerda nada entre sesiones, así que lo único que lleva una decisión del lunes al martes es el documento que lee cada vez. SDD trata la spec como esa memoria. AI-DLC industrializó la misma idea. Cada intent tiene su propia carpeta en el repo con los requisitos, las decisiones, un archivo de estado y un log de auditoría de solo agregado, y AI-DLC 2 suma un loop de aprendizaje que convierte tus correcciones en reglas para la próxima corrida. Es el mismo principio a escala de equipo. Escribí la versión corta en Don’t Code, Specify.

La segunda es el Smart Kid Principle: escribe la spec para un chico de doce años muy inteligente, que hace buenas preguntas pero no tiene nada de tu contexto. El agente tiene exactamente esa limitación, y también el compañero que revisa la spec en el gate. Un equipo que escribe para el chico inteligente produce artefactos que se pueden juzgar. Un equipo que escribe para sí mismo produce artefactos que solo se pueden aprobar. Cómo escribir una spec es el método completo, incluidos los requisitos escritos en EARS, una gramática fija para “cuando pase esto, el sistema debe hacer aquello”.

La tercera es el rigor en un espectro. El paper sobre Spec-Driven Development de Deepak Babu Piskala plantea un rango: code-first, ad hoc, spec-first (la spec guía la primera construcción y puede abandonarse), spec-anchored (la spec se mantiene sincronizada con el código y las pruebas lo garantizan) y spec-as-source (la spec es lo único que editan las personas y el código se regenera). AI-DLC está en spec-anchored por diseño: los artefactos viven en el repo y los gates de verificación chequean que cada requisito siga vinculado a una historia y a una Unit. Su regla de trabajo contra editar a mano el código generado, volviendo siempre al diseño, tira hacia spec-as-source. Un equipo que nunca sintió la diferencia entre spec-first y spec-anchored no va a entender por qué esa regla importa. El espectro está explicado en qué es Spec-Driven Development.

Dónde AI-DLC va más allá de SDD

Nada de esto vuelve redundante a AI-DLC. Hace cosas que SDD nunca intentó, y esas son las razones para subir la escalera.

Lo que cubre SDD

1. 01Una feature, de la spec al código verificado
2. 02Un gate por documento, normalmente un pull request
3. 03Specs escritas por quien es dueño de la tarea
4. 04Funciona para un dev y un agente

Lo que suma AI-DLC

1. 01Ideation: si vale la pena construir esto, antes de que existan requisitos
2. 02Rituales de mob que reúnen producto, diseño e ingeniería en una sesión
3. 03Descomposición en Units y bolts con un grafo de dependencias
4. 04Una fase de Operation que devuelve producción a la próxima intent
5. 05Un loop de aprendizaje, agentes revisores y perfiles de workflow del tamaño del trabajo

El salto entre los dos es la coordinación. SDD resuelve el problema de que una persona y un agente se pongan de acuerdo sobre qué construir. AI-DLC resuelve el problema de que un PM, una persona de diseño, tres ingenieros y una docena de corridas de agentes se pongan de acuerdo sobre qué construir, en qué orden y quién lo aprobó. Ese segundo problema es real, es el que de verdad tiene la mayoría de las empresas, y SDD solo no lo resuelve. Hablé de la versión en equipo de SDD en Spec-Driven Development para equipos, que queda más o menos en el escalón tres.

Pasar de SDD a AI-DLC

Si la checklist de arriba salió bien, el cambio no es reescribir cómo trabajan. Es un escalón más.

De SDD a una primera corrida de AI-DLC

Entrada

Un equipo que ya especifica antes de construir

↓

1. KEEPMantén el hábito de la spec tal como está

   Los documentos de requisitos, diseño y tareas que ya escriben se vuelven la entrada que AI-DLC espera. Nada se tira.

   ↓
2. INVERTDeja que el agente haga las preguntas

   En lugar de escribir toda la spec tú mismo, dale la intención al agente y responde lo que pregunte. Tu instinto de SDD te avisa cuando una respuesta es demasiado vaga.

   ↓
3. GATETrata cada gate de AI-DLC como la revisión de spec que ya haces

   El mismo acto, más seguido, sobre artefactos que no escribiste. Sesiones de una hora para que las revisiones sigan siendo reales.

   ↓
4. SCOPEEmpieza con el perfil Classic en una feature

   Classic es la ceremonia de la versión 1: Inception y Construction, una aprobación por etapa. Las 33 etapas pueden esperar.

↓

Salida

Una corrida de AI-DLC en la que cada gate lo juzgan personas que saben cómo es una buena spec.

El setup en sí está en AI-DLC con Claude Code. Y antes de instalar nada, lee por qué yo no adoptaría el método entero de una vez: no adoptes AI-DLC, róbale.

Las herramientas mezclan las cosas, el orden no cambia

Una razón por la que la pregunta sigue apareciendo es que las herramientas mezclan las dos cosas. Kiro es un IDE spec-driven y también fue la primera casa de los steering files de AI-DLC. GitHub Spec Kit corre un flujo de spec, plan y tareas que parece una Inception chica. El propio AI-DLC 2 escribe documentos de requisitos y de diseño que cualquier practicante de SDD reconocería.

Ignora la marca. Pregunta qué puede hacer la gente del equipo. Si puede escribir una spec que un agente construye bien, y revisar una spec que no escribió, está lista para un ciclo de vida. Si no puede, ningún ciclo de vida lo va a hacer por ella. El ciclo de vida asume la habilidad. No la enseña.

Preguntas frecuentes

¿AI-DLC es una forma de Spec-Driven Development?+

En espíritu, sí. AI-DLC guarda requisitos, diseños y planes como artefactos versionados, y el agente construye a partir de lo que las personas aprobaron. Ese es el loop central de SDD.

Pero AI-DLC es mucho más que ese loop: fases, rituales, agentes, roles de equipo y operación. Piensa en SDD como la unidad de trabajo y en AI-DLC como la organización alrededor de muchas unidades.

¿Puedo usar AI-DLC sin hacer SDD antes?+

Puedes instalarlo. Te va a costar correrlo. Cada gate le pide a alguien que juzgue una especificación, y la gente que nunca escribió una tiende a aprobar lo que parezca completo. Los equipos que se saltan el hábito suelen terminar parchando a mano el código generado y culpando al método.

¿Qué va primero, SDD o AI-DLC?+

SDD. Empieza especificando dentro de las tareas que ya hacen, mantengan los sprints y el board, y dejen que el equipo se vuelva bueno escribiendo y revisando specs. Cuando las specs sean normales y se revisen antes del código, prueben AI-DLC en una feature real.

¿Kiro es spec-driven development o AI-DLC?+

Kiro es un IDE spec-driven de AWS, y fue el primer lugar donde corrieron las reglas de workflow de AI-DLC. AI-DLC 2 trata a Kiro como uno de los siete harnesses soportados (los agentes de código en los que se instala su motor), junto a Claude Code, Codex, Cursor, opencode y GitHub Copilot. Usar Kiro no significa que corras AI-DLC, y correr AI-DLC no requiere Kiro.

¿GitHub Spec Kit o pi-sdd-kit compiten con AI-DLC?+

En la práctica, no. Son toolkits de SDD: ayudan a un dev o a un equipo a especificar, planificar y construir una feature con un agente. AI-DLC es el ciclo de vida más grande. Un equipo que corre bien Spec Kit o pi-sdd-kit está construyendo exactamente la habilidad de la que depende AI-DLC.

¿AI-DLC 2 cambia esta respuesta?+

La hace más fuerte. AI-DLC 2 suma una fase de Ideation, más etapas, agentes revisores y un loop de aprendizaje. Más artefactos significa más gates, y más gates significa más momentos en los que una persona tiene que juzgar una spec.

A dónde ir ahora

SDD y AI-DLC no son rivales. Uno es el hábito, el otro es la casa que construyes cuando el hábito se sostiene. Empieza donde tu equipo realmente está, sube un escalón a la vez, y no dejes que nadie te venda el escalón cinco mientras sigues en el uno.