Não adote o AI-DLC. Roube dele.

O framework mais maduro para construir com agentes foi desenhado para outra pessoa. Leve o que serve para o seu problema. Deixe a doutrina na prateleira.

O AI-DLC é a melhor resposta pública que eu conheço para a pergunta que todo líder de engenharia está fazendo agora: como construir software com agentes de IA sem perder o controle do que vai para produção. A AWS publicou o método em 2025. Em setembro de 2026 lançou o AI-DLC 2, um motor que instala um ciclo de 33 estágios dentro do agente de código que o seu time já usa.

Mesmo assim eu não diria para um time adotar.

Passei os últimos meses dentro de uma grande organização de engenharia onde o AI-DLC saiu de alguns squads piloto e virou um programa de treinamento para as pessoas que vão espalhá-lo por todos os times. O método funcionou onde as pessoas trataram ele como material para construir. Travou onde trataram como doutrina a ser cumprida. A diferença nunca foi a ferramenta. Foi a postura.

Adotar um nome é adotar os problemas dos outros

Imagine a reunião. Um líder que leu o whitepaper anuncia que a partir do próximo trimestre a organização faz AI-DLC. Soa decidido. Veja o que acontece depois.

As pessoas vão estudar. Leem o paper, assistem às palestras, abrem o repositório e tentam reproduzir o que encontram lá. O método descreve um ciclo de 33 estágios, rituais de mob, 14 agentes e um vocabulário novo: Intents (o que o trabalho precisa alcançar), Units (partes da solução que podem ser construídas sozinhas) e Bolts (fatias de entrega medidas em horas). Então é isso que elas tentam instalar. Em poucas semanas o time está rodando cerimônias dimensionadas para um problema que não tem, e deixando de lado o único problema que tem, porque o paper não falava dele.

A AWS e a sua empresa são bichos diferentes. O método foi moldado por um fornecedor que vende infraestrutura de nuvem para clientes grandes, muitas vezes regulados, muitos deles na própria stack da AWS. Um dos 14 agentes é especialista em plataforma AWS. O perfil Enterprise roda todos os estágios no nível mais profundo. É o design certo para quem o escreveu. Para você, é ponto de partida, não destino.

Trate como gôndola de supermercado

Uma gôndola de supermercado não pede para você levar tudo o que está nela. Você passa, pega o que o jantar de hoje pede e deixa o resto para quem tem outra receita. Ninguém chama isso de escolher a dedo. Chama de fazer compras.

O AI-DLC merece esse tratamento, porque é uma gôndola muito boa. Tem mecanismos que resolvem problemas reais com agentes, e quase todos funcionam sozinhos, fora do ciclo completo. Levar um não te obriga a levar os outros.

A primeira vez que apliquei isso foi numa conversa sobre como levar o método para uma parte da organização que não estava pronta para ele. Em vez de importar o AI-DLC inteiro, a gente separou em variáveis: quem senta no mob, qual o tamanho de uma tarefa, qual combinação de rituais um time específico precisava. Terminamos com quatro ou cinco configurações de partida em vez de uma doutrina. Cada time escolheu a que combinava com a própria maturidade. Ninguém precisou fingir que era squad piloto.

O que levar primeiro

Estes são os mecanismos que se pagaram sozinhos, mais ou menos na ordem em que eu levaria.

Leve estes

• ✓Obrigatório:
  Artefatos que ficam no repo.Requisitos, decisões e planos como arquivos versionados que o agente lê em toda sessão. É a ideia mais valiosa do método, e funciona com qualquer ferramenta.
• ✓Obrigatório:
  Um gate humano entre as etapas.O agente produz, uma pessoa aprova ou pede mudanças, e só então a próxima etapa começa. O whitepaper chama cada gate de função de perda: ele pega uma decisão errada onde voltar atrás é barato.
• ✓Obrigatório:
  Deixe a IA fazer as perguntas.Entregue a intenção ao agente e responda o que ele perguntar, em vez de tentar escrever o prompt perfeito. As perguntas que ele faz são as que um dev encontraria no meio da implementação.
• ✓Obrigatório:
  Profundidade proporcional ao trabalho.Um bugfix não precisa de modelo de domínio. O AI-DLC 2 codifica isso em 11 perfis de workflow, de uma proof of concept de 8 estágios até os 33. Roube o princípio mesmo que nunca instale o motor.
• •Opcional:
  Fatias medidas em horas.Bolts em vez de sprints de duas semanas. Leve quando o time especificar bem o bastante para o agente entregar uma fatia sem esperar uma reunião.
• •Opcional:
  Um loop de aprendizado.Transforme cada correção que você faz numa regra que o agente lê da próxima vez. O AI-DLC 2 faz isso com um diário por estágio e uma confirmação no gate. Um arquivo simples com as regras do time já é um bom começo.

O que deixar na prateleira, pelo menos por enquanto

A outra metade de fazer compras é passar reto.

Deixe estes, por enquanto

• ✗Anti-pattern:
  Os 33 estágios no primeiro dia.Comece pelo perfil Classic, que é a cerimônia da versão 1: Inception e Construction, uma aprovação por estágio. Acrescente fases quando um problema real pedir.
• ✗Anti-pattern:
  Renomear tudo.Chamar sprint de bolt e épico de intent não muda o trabalho. Mude o trabalho primeiro. As palavras podem vir depois, ou nunca.
• ✗Anti-pattern:
  Um mob para toda tarefa.O Mob Elaboration se paga quando uma decisão precisa de várias pessoas. Uma tarefa que um engenheiro consegue especificar sozinho não precisa de uma sala.
• ✗Anti-pattern:
  Os agentes que não servem para você.Se você não roda na AWS, o agente de plataforma AWS e os servidores MCP da AWS são ruído. Se você não tem regime de compliance, o agente de compliance é cerimônia.
• ✗Anti-pattern:
  A expectativa de entrega instantânea.O método piora o cycle time antes de melhorar. Líderes que adotam o rótulo normalmente adotam a promessa junto, e depois matam o rollout no fundo da curva.

Escreva o que levou e por quê

A metáfora da gôndola tem uma armadilha: fazer compras sem lista. Se cada time leva um punhado diferente de mecanismos e ninguém escreve, daqui a um ano você tem vinte dialetos privados de AI-DLC e nenhum jeito de compará-los.

Então o guia que a sua organização escrever deve abrir com duas listas, e cada item das duas listas deve levar a sua origem.

## 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

A regra que eu aplico nesses guias é seca: se um item não tem origem, ele não entra. Toda prática veio do método da AWS, de outro framework ou do seu próprio piloto. Escrever isso é o que separa uma decisão de um boato, e diz para a próxima pessoa o que ela pode mudar.

O AI-DLC 2 acabou de provar o ponto

Aqui está o argumento mais forte a favor dessa postura, e ele chegou em setembro de 2026.

Os times que adotaram a versão 1 do AI-DLC construíram em cima dela. Precisavam. A versão 1 era um conjunto de arquivos de regras, e times de verdade precisavam de mais do que isso, então escreveram as próprias camadas: extensões carregadas por opt-in, retrospectivas que rodavam no fim de cada tarefa, construção em paralelo com git worktrees, patches injetados nas regras do núcleo, disciplina para limpar o contexto e retomar o trabalho. Algumas dessas camadas eram obras de engenharia impressionantes.

Aí o AI-DLC 2 saiu, e boa parte desse encanamento virou nativa.

O que os times construíram na versão 1, e o que o AI-DLC 2 entregou

Conferido contra o AI-DLC 2.10.0, a release atual em 1º de outubro de 2026.

Feito em casa na versão 1	Nativo no AI-DLC 2
Controle de estado próprio e retomada depois de limpar o contexto	Um arquivo de estado por intent, um log de auditoria só de acréscimo com 108 tipos de evento, e recuperação quando o agente comprime o contexto no meio da sessão
Retrospectivas que rodam quando uma tarefa termina	Um loop de aprendizado: um diário por estágio, candidatos confirmados no gate, regras aplicadas na próxima rodada
Construção em paralelo com git worktrees	Execução em swarm: Units com as dependências prontas construídas em worktrees paralelas, com checkpoints por lote
Patches injetados nas regras do núcleo	Um sistema de plugins que só acrescenta ao núcleo e nunca o edita
Um workflow só, aparado na mão a cada tarefa	11 perfis de workflow mais um agente composer que propõe uma rota sob medida

Os times que tinham adotado a versão 1 como doutrina passaram a manter uma doutrina mais uma pilha de gambiarras que o fornecedor tinha acabado de tornar obsoletas. Os times que tinham tratado o método como gôndola não perderam nada importante, porque o encanamento nunca foi o ponto.

O que sobreviveu à atualização foi tudo o que codificava o julgamento da própria organização. As regras contra vibe coding que um time piloto aprendeu do jeito difícil. O ritual para moldar uma boa intenção antes de alguém escrever um requisito. O senso de quais tarefas não merecem o método. Nada disso veio no AI-DLC 2, porque nada disso poderia vir. Pertence às pessoas que aprenderam.

Seja dono do julgamento, alugue o encanamento

A lição vale além do AI-DLC. Quando você constrói em cima de um framework que muda rápido, separe o que você escreve em duas pilhas.

Encanamento: deixe o fornecedor cuidar

1. 01Controle de estado e retomada
2. 02Orquestração de agentes e estágios
3. 03Execução em paralelo e worktrees
4. 04Logs de auditoria e checagens de rastreabilidade

Julgamento: mantenha com você

1. 01As suas regras sobre o que o agente nunca pode fazer
2. 02Como os seus times moldam uma intenção antes do primeiro requisito
3. 03Que trabalho passa pelo método e que trabalho não passa
4. 04O que os seus revisores checam em cada gate

Se você precisa estender o framework, faça isso nas costuras dele. O AI-DLC 2 vem com um mecanismo de plugins que consegue acrescentar estágios, agentes, regras e checagens sem editar o núcleo, então as suas adições sobrevivem à próxima release. Escrevi sobre a mesma disciplina para dependências em own the seam: uma mudança que mora no ponto de extensão declarado é versionada e sobrevive às atualizações, enquanto um patch espalhado pelo núcleo é reaplicado na mão depois de cada release, até alguém esquecer.

Quando adotar tudo é o certo

Ser honesto sobre as exceções deixa a regra mais forte.

Adote o AI-DLC quase inteiro quando a sua organização se parece com os clientes para quem ele foi desenhado: muitos times, trabalho regulado, necessidade de rastreabilidade completa da intenção até a produção, e uma stack AWS. O perfil Enterprise existe exatamente para isso, e inventar a sua própria versão seria desperdício.

Adote quase inteiro quando os seus times não têm processo nenhum. Um método completo e documentado ganha de um improvisado, e o modo workshop existe para ensiná-lo.

E mesmo assim, adote com as adaptações escritas. Uma liderança sênior com quem trabalhei resumiu bem: adotar o framework inteiro é uma boa escolha, desde que as mudanças que você faz sejam explícitas e deliberadas. A falha nunca é adotar demais. É adotar sem decidir.

Perguntas frequentes

Levar só partes do AI-DLC não é escolher a dedo?+

Escolher a dedo é levar as partes fáceis e pular as difíceis sem avisar. Isto é o contrário: você leva os mecanismos que resolvem um problema que você sabe nomear, escreve o que deixou e por quê, e revisita a lista. Os artefatos persistentes e os gates, os hábitos mais difíceis, são os primeiros da lista.

Vamos perder as atualizações se customizarmos o AI-DLC?+

Não, se a customização for nas costuras. O AI-DLC 2 tem um mecanismo de plugins que só acrescenta ao núcleo, mais arquivos de regras nos níveis de organização, time e projeto. O que muda ali sobrevive às releases. O que é remendado nos arquivos do núcleo é o que se perde.

Devemos chamar o nosso processo de AI-DLC internamente?+

Chame do jeito que ajudar as pessoas a encontrar o guia. Só evite transformar o nome no objetivo. Se as pessoas ouvem o nome e vão estudar o paper da AWS em vez do seu documento de duas listas, o nome está trabalhando contra você.

Quem decide o que levar?+

As pessoas que rodam os primeiros pilotos, com alguém que seja dono do guia. Práticas que vêm de um piloto real trazem evidência. Práticas que vêm de um slide trazem esperança. Escreva a origem ao lado de cada uma.

Isto é um argumento contra o AI-DLC?+

Não. É um argumento para usá-lo bem. O AI-DLC é o framework público mais completo para construir com agentes, e a maioria dos mecanismos dele vale a pena levar. O ponto é levar de propósito.

Para onde ir agora

Frameworks envelhecem. O AI-DLC 2 tornou obsoleto um ano de encanamento feito em casa numa release só, e o AI-DLC 3 vai fazer de novo. O que não envelhece é o que os seus times aprenderam sobre o próprio trabalho. Leve os mecanismos, fique com o julgamento, e escreva qual é qual.