AI-DLC vs Spec-Driven Development: por que você precisa de SDD antes

O AI-DLC pede para uma pessoa julgar uma spec em todo gate. Um time que nunca escreveu uma spec não consegue julgar uma.

As pessoas buscam “AI-DLC vs Spec-Driven Development” como se precisassem escolher um dos dois. É a pergunta errada, e responder do jeito que ela foi feita é como um time acaba rodando um ciclo de 33 estágios que não consegue operar.

Spec-Driven Development (SDD) é uma prática: antes de um agente construir qualquer coisa, você escreve o que ele precisa fazer, e verifica o resultado contra o que escreveu. O AI-DLC, o AI-Driven Development Life Cycle que a AWS publicou em 2025 e lançou como motor instalável em 2026, é um ciclo de vida inteiro: fases, rituais, agentes e gates de aprovação humana, da primeira ideia até a produção. Um é um hábito. O outro é uma organização construída em cima desse hábito.

Escrevo spec para agentes há mais de um ano, incluindo os 13 apps que construí em 70 dias. Nos últimos meses também estive dentro de uma grande organização de engenharia vendo o AI-DLC sair dos squads piloto e chegar às pessoas que vão espalhá-lo por todos os times. Os times que sofreram não eram os que tinham a ferramenta errada. Eram os que tinham pulado o hábito.

SDD é uma prática, AI-DLC é um ciclo de vida

O jeito mais rápido de ver a diferença é colocar os dois lado a lado no que um time faz de verdade.

Duas camadas, não duas escolhas

O SDD cabe dentro do AI-DLC. O AI-DLC não cabe dentro do SDD.

Dimensão	Spec-Driven Development	AI-DLC
O que é	Uma disciplina para uma unidade de trabalho: especificar, gerar, verificar.	Um ciclo de vida completo para um time: 5 fases, 33 estágios, gates entre eles.
Quem conduz	Você escreve a spec. O agente constrói a partir dela.	A IA propõe o plano e faz as perguntas. Você decide nos gates.
Artefato principal	Requisitos, design e tarefas, versionados ao lado do código.	Um registro por intent: requisitos, histórias, ADRs, Units, planos, estado, log de auditoria.
Rituais	Nenhum obrigatório. Um gate por documento basta.	Mob Elaboration, Mob Construction, gates de aprovação, gates de verificação.
Escopo	Funciona para um dev e uma feature.	Se paga quando o trabalho pede decisões de várias pessoas.
Menor começo útil	Três arquivos markdown e um agente.	Um motor instalado, um repo legível para agente e um time que já especifica.

Leia a última linha duas vezes. SDD é algo que você começa hoje à tarde. AI-DLC é algo que você começa quando o SDD já é normal, e não antes.

Todo gate do AI-DLC é uma revisão de spec

Percorra as paradas de uma rodada de AI-DLC e conte quantas delas são uma pessoa lendo uma especificação e decidindo se ela está certa.

Na Inception, a fase em que o trabalho é definido, o agente escreve os requisitos, e você aprova. Ele rascunha as user stories, e você aprova. Ele propõe um domain design com decisões de arquitetura, e você aprova. Ele divide o trabalho em Units, as partes que podem ser construídas de forma independente, e você aprova a divisão. Na Construction, a fase em que a coisa é construída, ele escreve um plano para cada Unit antes de escrever uma linha de código, e você aprova o plano. Cada um desses gates é o mesmo ato: julgar uma spec.

Esse ato é uma habilidade. Significa perceber um requisito sem critério de aceite, uma história que esconde duas features, um design que está certo localmente e errado para o resto do sistema, um plano que mexe em arquivos que não deveria. Ninguém nasce com isso. As pessoas aprendem escrevendo specs e vendo agentes construírem a coisa errada a partir das vagas.

O que acontece quando um time pula o SDD

A falha é silenciosa, e é por isso que é comum. Este é o mecanismo que vi acontecer mais de uma vez.

O time instala o workflow e começa uma feature. O agente faz as perguntas. Ninguém no time está acostumado a responder com detalhe, então as respostas saem curtas e vagas. O agente preenche as lacunas com a suposição mais provável, que é a média estatística de tudo o que ele já leu. O documento de requisitos sai longo, bem formatado e genérico. O time aprova, porque parece um documento de requisitos. O design segue o mesmo padrão. Aí a Construction produz um código que roda, passa nos testes e não resolve bem o problema.

Então um dev abre o código e conserta na mão. A execução que o agente deveria carregar volta para uma pessoa, e agora essa pessoa está consertando um código que não escreveu, contra uma spec que não leu de verdade. Isso é mais lento do que escrever o código desde o começo, e o time conclui que o AI-DLC não funciona.

O modelo vai satisfazer qualquer especificação que você der, boa ou ruim. Estatisticamente ele cai em qualquer ponto entre a melhor e a pior versão do que você quis dizer. Falei isso numa das sessões do rollout, e continuo falando porque é o argumento inteiro: a única alavanca que puxa o agente para a melhor versão é a qualidade da spec, e a qualidade da revisão que a aprovou.

AI-DLC sem o hábito da spec

1. 01Respostas vagas às perguntas do agente
2. 02Requisitos genéricos aprovados porque parecem prontos
3. 03Código que passa nos testes e erra o alvo
4. 04Devs remendando código gerado na mão
5. 05"O AI-DLC não funciona para a gente"

AI-DLC em cima de SDD

1. 01Respostas com números, edge cases e escopo negativo
2. 02Requisitos que um revisor consegue testar linha por linha
3. 03Código construído contra uma spec que alguém leu de verdade
4. 04As correções voltam para a spec, não para o código
5. 05Os gates pegam os erros onde eles são baratos

A escada do copiloto ao AI-DLC

A maioria dos times não precisa escolher entre SDD e AI-DLC. Precisa saber em que degrau está. Esta é a escada que eu uso com líderes de engenharia, e ela saiu de uma conversa sobre por que um rollout completo de AI-DLC estava chegando cedo demais para a maioria dos times.

Do copiloto ao AI-DLC

1. 1

   Scrum com copiloto

   "Autocomplete e chat dentro do processo que você já roda."

   → Digita mais rápido. A estrutura do trabalho não muda.

2. 2

   Scrum com SDD dentro da tarefa

   "Mantenha a sprint. Quando pegar uma tarefa, gaste mais tempo especificando, deixe o agente construir, confira o resultado."

   → O time aprende a escrever e julgar spec sem mudar mais nada.

3. 3

   SDD com agente supervisionado

   "A spec é o contrato. O agente constrói a partir dela, você verifica contra ela, e as correções voltam para a spec."

   → A spec deixa de ser papelada. A revisão vem antes do código.

4. 4

   Gestão e execução agênticas

   "O agente planeja, decompõe e pergunta. As pessoas decidem nos gates."

   → É aqui que o AI-DLC começa a pagar a própria cerimônia.

5. 5

   Full agêntico, em bolts

   "O trabalho anda em fatias de horas em vez de pacotes de duas semanas."

   → A cadência para a qual o AI-DLC foi desenhado.

O degrau que importa é o dois. Ele custa quase nada: a sprint fica, o board fica, as cerimônias ficam. A única mudança é dentro da tarefa. E ele constrói exatamente a habilidade da qual os degraus quatro e cinco dependem.

A maioria dos times que eu encontro está no degrau um e acha que está perto do topo, porque entrega mais rápido do que no ano passado. Digitar mais rápido parece progresso. Não é a mesma coisa que conseguir delegar uma unidade inteira de trabalho.

Como saber em que degrau você está

Esqueça o questionário de autoavaliação. Olhe o que o time faz quando uma feature começa.

Pronto para o AI-DLC?

• ✓Obrigatório:
  Toda feature começa com uma spec escrita antes de qualquer código.Não é o título de um ticket. É um documento com requisitos, critérios de aceite e o que está fora do escopo.
• ✓Obrigatório:
  As specs são revisadas antes da implementação, não depois.Se a primeira vez que alguém lê a spec é no code review, você está no degrau um com arquivos a mais.
• ✓Obrigatório:
  Quando o agente constrói a coisa errada, o time corrige a spec primeiro.Remendar o código gerado e seguir em frente quer dizer que a spec nunca foi o contrato.
• ✓Obrigatório:
  Quem revisa consegue explicar numa frase por que uma spec aprovada está certa.É exatamente o ato que o AI-DLC pede em cada gate. Se as pessoas não conseguem fazer isso nas próprias specs, não vão conseguir nas do agente.
• ✓Obrigatório:
  O repo é legível para um agente.Um AGENTS.md ou CLAUDE.md com a stack, os padrões e as bibliotecas proibidas. Sem isso o agente chuta, e as perguntas que ele faz são trivialidades.
• ✓Obrigatório:
  Alguém é dono da decisão de quando não usar o método.Uma correção de uma linha não precisa de um ciclo de vida. Um time que passa tudo pelo ritual completo não está pronto, está encenando.

O que o SDD dá ao AI-DLC que o AI-DLC não consegue dar a si mesmo

O AI-DLC é um recipiente. A qualidade do que entra nele não é trabalho dele. Três ideias do SDD são o que o enchem.

A primeira é que a spec é memória externa. Um agente vive num presente eterno: não lembra de nada entre uma sessão e outra, então a única coisa que carrega uma decisão de segunda para terça é o documento que ele lê toda vez. O SDD trata a spec como essa memória. O AI-DLC industrializou a mesma ideia. Cada intent ganha uma pasta própria no repo com os requisitos, as decisões, um arquivo de estado e um log de auditoria só de acréscimo, e o AI-DLC 2 acrescenta um loop de aprendizado que transforma as suas correções em regras para a próxima rodada. É o mesmo princípio na escala de um time. Escrevi a versão curta em Don’t Code, Specify.

A segunda é o Smart Kid Principle: escreva a spec para uma criança de doze anos muito esperta, que faz boas perguntas mas não tem nada do seu contexto. O agente tem exatamente essa limitação, e o colega que revisa a spec no gate também. Um time que escreve para a criança esperta produz artefatos que podem ser julgados. Um time que escreve para si mesmo produz artefatos que só podem ser aprovados. Como escrever uma spec é o método completo, incluindo requisitos escritos em EARS, uma gramática fixa para “quando isto acontecer, o sistema deve fazer aquilo”.

A terceira é o rigor num espectro. O paper sobre Spec-Driven Development de Deepak Babu Piskala descreve uma faixa: code-first, ad hoc, spec-first (a spec guia a primeira construção e pode ser abandonada), spec-anchored (a spec fica sincronizada com o código e os testes garantem isso) e spec-as-source (a spec é a única coisa que pessoas editam e o código é regenerado). O AI-DLC fica em spec-anchored por design: os artefatos ficam no repo e os gates de verificação checam se cada requisito ainda se liga a uma história e a uma Unit. A regra de trabalho dele contra editar código gerado na mão, voltando sempre para o design, puxa para spec-as-source. Um time que nunca sentiu a diferença entre spec-first e spec-anchored não vai entender por que essa regra importa. O espectro está explicado em o que é Spec-Driven Development.

Onde o AI-DLC vai além do SDD

Nada disso torna o AI-DLC redundante. Ele faz coisas que o SDD nunca tentou fazer, e são esses os motivos para subir a escada.

O que o SDD cobre

1. 01Uma feature, da spec ao código verificado
2. 02Um gate por documento, normalmente um pull request
3. 03Specs escritas por quem é dono da tarefa
4. 04Funciona para um dev e um agente

O que o AI-DLC acrescenta

1. 01Ideation: vale a pena construir isso, antes de existirem requisitos
2. 02Rituais de mob que juntam produto, design e engenharia numa sessão
3. 03Decomposição em Units e bolts com grafo de dependências
4. 04Uma fase de Operation que devolve a produção para a próxima intent
5. 05Um loop de aprendizado, agentes revisores e perfis de workflow do tamanho do trabalho

O salto entre os dois é coordenação. O SDD resolve o problema de uma pessoa e um agente concordarem sobre o que construir. O AI-DLC resolve o problema de um PM, uma pessoa de design, três engenheiros e uma dúzia de rodadas de agente concordarem sobre o que construir, em que ordem e quem aprovou. Esse segundo problema é real, é o que a maioria das empresas tem de fato, e o SDD sozinho não resolve. Falei da versão em time do SDD em Spec-Driven Development em time, que fica mais ou menos no degrau três da escada.

Saindo do SDD para o AI-DLC

Se a checklist acima foi bem, a mudança não é reescrever o jeito como vocês trabalham. É mais um degrau.

Do SDD a uma primeira rodada de AI-DLC

Entrada

Um time que já especifica antes de construir

↓

1. KEEPMantenha o hábito da spec exatamente como está

   Os documentos de requisitos, design e tarefas que vocês já escrevem viram a entrada que o AI-DLC espera. Nada vai para o lixo.

   ↓
2. INVERTDeixe o agente fazer as perguntas

   Em vez de escrever a spec inteira, entregue a intenção ao agente e responda o que ele perguntar. O seu instinto de SDD avisa quando uma resposta está vaga demais.

   ↓
3. GATETrate cada gate do AI-DLC como a revisão de spec que você já faz

   O mesmo ato, mais vezes, em artefatos que você não escreveu. Sessões de uma hora para que as revisões continuem de verdade.

   ↓
4. SCOPEComece com o perfil Classic numa feature

   O Classic é a cerimônia da versão 1: Inception e Construction, uma aprovação por estágio. Os 33 estágios podem esperar.

↓

Saída

Uma rodada de AI-DLC em que cada gate é julgado por pessoas que sabem como é uma spec boa.

O setup em si está em AI-DLC com Claude Code. E antes de instalar qualquer coisa, leia por que eu não adotaria o método inteiro de uma vez: não adote o AI-DLC, roube dele.

As ferramentas misturam as coisas, a ordem não muda

Um motivo para a pergunta continuar aparecendo é que as ferramentas misturam os dois. O Kiro é uma IDE spec-driven e também foi a primeira casa dos steering files do AI-DLC. O GitHub Spec Kit roda um fluxo de spec, plano e tarefas que parece uma Inception pequena. O próprio AI-DLC 2 escreve documentos de requisitos e de design que qualquer praticante de SDD reconheceria.

Ignore a marca. Pergunte o que as pessoas do time conseguem fazer. Se conseguem escrever uma spec que um agente constrói certo, e revisar uma spec que não escreveram, estão prontas para um ciclo de vida. Se não conseguem, nenhum ciclo de vida vai fazer isso por elas. O ciclo de vida assume a habilidade. Não ensina.

Perguntas frequentes

O AI-DLC é uma forma de Spec-Driven Development?+

No espírito, sim. O AI-DLC guarda requisitos, designs e planos como artefatos versionados, e o agente constrói a partir do que as pessoas aprovaram. Esse é o loop central do SDD.

Mas o AI-DLC é muito mais do que esse loop: fases, rituais, agentes, papéis no time e operação. Pense no SDD como a unidade de trabalho e no AI-DLC como a organização em volta de muitas unidades.

Dá para usar AI-DLC sem fazer SDD antes?+

Dá para instalar. Vai ser difícil rodar. Todo gate pede para alguém julgar uma especificação, e quem nunca escreveu uma tende a aprovar qualquer coisa que pareça completa. Os times que pulam o hábito normalmente acabam remendando código gerado na mão e culpando o método.

O que vem primeiro, SDD ou AI-DLC?+

SDD. Comece especificando dentro das tarefas que vocês já fazem, mantenham as sprints e o board, e deixem o time ficar bom em escrever e revisar spec. Quando spec for normal e revisada antes do código, testem o AI-DLC numa feature real.

O Kiro é spec-driven development ou AI-DLC?+

O Kiro é uma IDE spec-driven da AWS, e foi o primeiro lugar onde as regras de workflow do AI-DLC rodaram. O AI-DLC 2 trata o Kiro como um dos sete harnesses suportados (os agentes de código em que o motor se instala), ao lado de Claude Code, Codex, Cursor, opencode e GitHub Copilot. Usar o Kiro não quer dizer que você roda AI-DLC, e rodar AI-DLC não exige o Kiro.

O GitHub Spec Kit ou o pi-sdd-kit competem com o AI-DLC?+

Na prática, não. São toolkits de SDD: ajudam um dev ou um time a especificar, planejar e construir uma feature com um agente. O AI-DLC é o ciclo de vida maior. Um time que roda bem o Spec Kit ou o pi-sdd-kit está construindo exatamente a habilidade da qual o AI-DLC depende.

O AI-DLC 2 muda essa resposta?+

Deixa mais forte. O AI-DLC 2 acrescenta uma fase de Ideation, mais estágios, agentes revisores e um loop de aprendizado. Mais artefatos quer dizer mais gates, e mais gates quer dizer mais momentos em que uma pessoa precisa julgar uma spec.

Para onde ir agora

SDD e AI-DLC não são rivais. Um é o hábito, o outro é a casa que você constrói quando o hábito se sustenta. Comece de onde o seu time realmente está, suba um degrau por vez, e não deixe ninguém te vender o degrau cinco enquanto você ainda está no um.