AI-DLC 2: o que mudou, e o que ficou obsoleto
A AWS reescreveu o AI-DLC. A versão 2 chega como um motor determinístico que tira do modelo a rota, a avaliação e o estado: 5 fases, 33 estágios, 14 agentes, 11 perfis de workflow, um loop de aprendizado e checkpoints de construção verificados. O que mudou desde a versão 1, quais camadas caseiras ficaram obsoletas e o que sobreviveu.
A AWS não subiu o AI-DLC para a versão 2. Reescreveu, e numa release só a maior parte do encanamento que os times tinham construído em cima da versão 1 deixou de valer a manutenção.
O AI-DLC 2 é a segunda geração do AI-Driven Development Life Cycle da AWS. A primeira release estável da linha 2.x, a 2.7.0, saiu em 1º de setembro de 2026. Três semanas depois a 2.10.0 já estava no ar. A versão 1 era um conjunto de arquivos de regras que dizia ao agente como conduzir você por um projeto. A versão 2 é um motor: um comando nativo, aidlc, que instala um workflow determinístico em sete agentes de código, com 5 fases, 33 estágios, 14 agentes, 11 perfis de workflow e um loop que transforma as suas correções em regras.
Se o método em si é novo para você, comece por o que é AI-DLC. Este artigo é para quem já conhece a versão 1, ou para quem está decidindo se começa direto na versão 2.
Acompanhei a versão 1 do AI-DLC dentro de uma grande organização de engenharia, dos squads piloto a um programa de treinamento. Os times fizeram o que todo adotante sério faz com um framework jovem: construíram camadas por cima para cobrir o que faltava. Aí o AI-DLC 2 entregou a maior parte dessas camadas como recurso nativo. Ver isso acontecer me ensinou mais sobre adotar framework de IA do que o próprio framework, então a segunda metade deste artigo é sobre isso.
De arquivos de regras a um motor em quatorze meses
Como o AI-DLC chegou à versão 2
- jul. 2025O whitepaper
Raja SP publica a definição do método AI-DLC e a AWS anuncia no blog de DevOps. Dez princípios, três fases, nenhum código.
- nov. 2025Open source como arquivos de regras
A AWS libera os workflows como regras do Amazon Q Developer e steering files do Kiro. O agente lê as regras e segue o ciclo.
- jan. a abr. 2026A série 0.1
Nove releases endurecem o workflow guiado por regras.
- 19 jun. 2026Versão 1.0.0
A primeira release estável. A 1.0.1 vem em 30 de junho e vira a última da linha.
- 1º set. 2026Versão 2.7.0
A primeira release estável da linha 2.x. A linha 2.x foi construída à parte; nenhuma release de 2.0 a 2.6 saiu como estável.
- 24 set. 2026Versão 2.10.0
Checkpoints de construção mais fortes, harnesses convivendo no mesmo projeto, correções de worktree. Previews da 2.10.1 saem quase todo dia.
O número da versão já conta uma história. A AWS pulou direto da 1.0.1 para a 2.7.0, o que quer dizer que a linha 2.x passou meses amadurecendo em paralelo antes de alguém ser chamado a depender dela. Quando chegou à branch principal, já estava na sétima versão minor.
O AI-DLC 2.10.0 em números
- 33
- estágiosem 5 fases
- 14
- agentes11 especialistas, 2 revisores, 1 composer
- 11
- perfis de workflowmais um composer para rotas sob medida
- 108
- tipos de evento de auditorianum log só de acréscimo
O motor decide, o modelo executa
De tudo o que mudou na versão 2, é essa mudança que eu colocaria na caixa. A versão 1 era arquivo de regras: prosa que o agente lia e em que se confiava que ele seguiria. O agente decidia qual estágio vinha depois, se dava para pular um passo, se a própria saída estava boa o bastante e o que o arquivo de estado dizia. Quando ele saía do trilho, nada segurava além de uma pessoa cansada num gate. É daí que nasce o slop: um modelo que escolhe a própria rota, corrige a própria lição e edita os próprios registros.
A versão 2 divide o trabalho em dois. Um motor determinístico, código comum com meia dúzia de subcomandos, é dono da rota: qual estágio roda depois, qual perfil vale, quando parar, o que um gate está esperando. Ele emite uma instrução tipada, e o conductor (a sessão do /aidlc, que é o LLM) executa e devolve o resultado. O modelo continua fazendo o raciocínio dentro do estágio. Ele só não decide mais o formato do processo. A própria documentação da AWS resume a divisão numa frase: o motor é dono da rota, o conductor é dono da qualidade da execução.
Poderes que o modelo tinha na versão 1, e com quem eles ficam na versão 2
| Na versão 1 o modelo podia | Na versão 2 |
|---|---|
| Decidir qual estágio vem depois, ou pular um | O motor roteia a partir de um grafo de estágios compilado quando o workflow começa. Um estágio pulado fica registrado como pulado. |
| Dizer que os testes passaram | Uma Unit só é verificada pelo comando de checagem que uma pessoa aprovou, e só por um recibo que a ferramenta escreve. Um arquivo de prova escrito à mão não verifica uma Unit. |
| Avaliar o próprio artefato | Agentes revisores separados julgam o artefato, presos a uma impressão digital dele, então trabalho alterado não herda uma aprovação anterior. Sensores determinísticos (linters, checagem de tipos) disparam sobre a saída. |
| Editar o estado do workflow | Uma guarda impede as ferramentas do modelo de escrever os registros de sessão e de aprovação de plano. O estado anda pelo motor. |
| Aprovar o próprio gate | Um gate apresentado a você precisa de uma mensagem real sua. A guarda de presença humana não pode ser baixada por workflow. |
| Mudar as regras no meio do caminho | Regras, estágios e sensores são compilados uma vez por workflow. Uma regra nova vale na próxima vez. |
| Perder as ligações entre artefatos | Gates de verificação automáticos checam a rastreabilidade entre as fases antes que a próxima construa em cima delas. |
Nada disso deixa o modelo mais inteligente. Deixa o processo menos dependente de o modelo se comportar, o que é um objetivo diferente e melhor. É a mesma lição em que eu sempre acabo chegando em harness engineering: uma checagem determinística que quebra o build vale mais do que um parágrafo de instrução que o agente pode ignorar. A AWS só aplicou isso ao ciclo inteiro. Até o empacotamento segue a regra: todo harness recebe o mesmo motor, e o build que gera as sete distribuições roda duas vezes e compara a saída byte a byte.
O ciclo de vida ganhou duas fases
A versão 1 tinha as três fases do whitepaper. Inception transformava uma intenção em requisitos, histórias e Units de trabalho. Construction transformava cada Unit em design, código e testes. Operations fazia o deploy e acompanhava o sistema rodando. Uma pessoa aprovava cada passo.
AI-DLC versão 1
- 01
Inception
Mob Elaboration: a IA propõe, o time refina.
- Workspace detection
- Reverse engineering (brownfield)
- Requirements analysis
- User stories
- Workflow planning
- Application design
- Units generation
Gate: Aprovação humana por estágio
- 02
Construction
Mob Construction, por Unit.
- Functional design
- NFR requirements
- NFR design
- Infrastructure design
- Code generation
- Build and test
Gate: Aprovação humana por estágio
- 03
Operations
O whitepaper descreve deploy, monitoramento e ações de runbook aprovadas. As regras da versão 1 entregaram a fase como placeholder.
A versão 2 mantém essas três e embrulha. A Initialization roda primeiro, sem pessoa nenhuma, e monta o workspace em menos de um segundo. A Ideation roda antes da Inception e pergunta se vale a pena construir a coisa: captura da intenção, pesquisa de mercado, viabilidade, escopo, formação do time, mockups rascunho e uma aprovação para seguir. Entre as fases, um gate de verificação agora checa a rastreabilidade sozinho, então um requisito órfão ou uma história que não aponta para nada é pego antes que a fase seguinte construa em cima.
AI-DLC versão 2
- 0.1 a 0.3
Initialization
Workspace, detecção, estado. Automático.
- 3 estágios, sem gate
- 1.1 a 1.7
Ideation
Vale a pena construir isso?
- Intent Capture
- Feasibility
- Scope Definition
- e mais 4
Gate: Gate de verificação 1
- 2.1 a 2.9
Inception
Requisitos, design, Units.
- Reverse Engineering
- Practices Discovery
- Requirements Analysis
- Units Generation
- e mais 5
Gate: Gate de verificação 2
- 3.1 a 3.7
Construction
Design, código e testes por Unit.
- Functional Design
- NFR Design
- Code Generation
- Build and Test
- e mais 3
Gate: Gate de verificação 3
- 4.1 a 4.7
Operation
Deploy, observabilidade, retorno.
- Deployment Pipeline
- Observability Setup
- Incident Response
- e mais 4
O estágio novo da Inception que merece atenção é o Practices Discovery. Antes de escrever requisitos, o agente olha como o seu time já trabalha (postura de testes, hábitos de deploy, estilo de código), rascunha isso, coloca outros três agentes para inspecionar o rascunho de forma independente, entrevista você sobre as lacunas e grava o resultado na memória do time. A versão 1 aprendia as suas convenções levando correção. A versão 2 pergunta antes.
Quatorze agentes em vez de uma voz só
A versão 1 era um agente seguindo steering rules e fazendo os papéis que as regras mandavam. A versão 2 traz 14 agentes com nome: 11 especialistas de domínio (produto, design, entrega, arquitetura, plataforma AWS, compliance, DevSecOps, desenvolvimento, qualidade, pipeline e deploy, operações), dois revisores e um composer.
A AWS chama a filosofia de “Small Mob, Broad Agents”. A alternativa era óbvia e errada: trinta especialistas estreitos, cada um dono de um artefato, passando o trabalho adiante numa corrente. Isso é waterfall com passos extras, e cada passagem perde contexto. Onze agentes amplos que trabalham em vários estágios levam mais do quadro com eles.
A maioria dos estágios continua rodando inline, na sua conversa. Quatro despacham trabalho: Reverse Engineering como pipeline de dois passos (um agente de desenvolvimento varre o código, um agente de arquitetura escreve a síntese), Practices Discovery e Code Generation como subagents, e User Stories como mob, em que os agentes de design, desenvolvimento e qualidade escrevem em paralelo. A conta na 2.10.0 é 29 inline, 2 subagent, 1 pipeline, 1 mob.
Os dois revisores importam mais do que o número de agentes. Depois que um estágio produz o artefato, o revisor de produto julga requisitos e histórias, e o revisor de arquitetura julga o design técnico. Uma revisão adversarial pode devolver o trabalho até duas vezes. E aí para e entrega as conclusões para você, porque o revisor nunca bloqueia. Quem decide é a pessoa. Essa regra é o método inteiro numa linha, e fico contente que a AWS colocou isso no motor em vez de deixar para a boa vontade.
Perfis no lugar do ciclo tamanho único
O décimo princípio do whitepaper dizia que nenhum workflow deveria ser engessado: a IA propõe a profundidade, a pessoa ajusta. A versão 1 implementou isso como um julgamento dentro das regras. A versão 2 transformou isso em 11 perfis de workflow com nome (o motor chama de scopes), cada um uma rota fixa pelos 33 estágios, com profundidade e estratégia de testes padrão.
Os perfis que você vai usar primeiro
| Perfil | Estágios | Para que serve |
|---|---|---|
| Classic | 18 / 33 | A cerimônia da versão 1: Inception e Construction, uma aprovação por estágio. O padrão do motor quando você não escolhe nada. |
| Express | 10 / 33 | Requisitos já entendidos. O caminho mais curto até código e testes. |
| Feature | 33 / 33 | Uma feature de produção pelo ciclo inteiro, com profundidade padrão. |
| Bugfix | 9 / 33 | Um defeito conhecido, um reparo focado, um teste de regressão e o deploy. |
O Classic é o caminho de migração, e a AWS fez dele o padrão de propósito. Um time que conhece a versão 1 consegue começar na versão 2 sem aprender uma cerimônia nova. Profundidade e estratégia de testes agora são botões separados (Minimal, Standard, Comprehensive), e dá para girar qualquer um sem trocar de perfil.
Correções viram regras: o loop de aprendizado
Esse é o recurso pelo qual eu teria pagado. A versão 1 esquecia. Você corrigia o agente na segunda, e na quinta, num workflow novo, ele cometia o mesmo erro, porque nada levava a correção adiante além da sua própria memória.
A versão 2 mantém um diário para cada estágio, um arquivo chamado memory.md, com quatro seções: Interpretations, Deviations, Tradeoffs e Open questions. Quando o agente toma uma decisão que as instruções do estágio não cobriam, ele anota. No gate de aprovação, o motor mostra essas linhas ao pé da letra e pergunta se você quer guardar alguma, mais um campo livre: “Anything to add for next time?”.
Como uma correção vira regra
Entrada
Você corrige o agente durante um estágio
- DIARYO agente registra a decisão que tomou
O memory.md do estágio ganha uma entrada em Interpretations, Deviations, Tradeoffs ou Open questions.
- GATEO gate mostra os candidatos
As linhas aparecem como foram escritas, sem paráfrase. Você marca as que valem guardar e pode acrescentar as suas.
- CHECKUma checagem de conflito contra as regras da organização
Se a linha nova contradiz uma regra da organização, você revisa, descarta ou escala.
- WRITEA linha guardada vai para a memória do projeto
Vai para o project.md, e um clique promove para o team.md. Open questions nunca viram regra.
Saída
A regra vale a partir do primeiro estágio do próximo workflow. Nunca no meio do atual.
A documentação percorre um exemplo real. Num projeto bancário, uma nota de stakeholder dizia “a transação não deveria duplicar em retry”. O agente de produto leu “transação” como transação de banco de dados e escreveu um requisito ACID. A pessoa queria dizer um pagamento e corrigiu, o diário registrou a interpretação, e a regra guardada fixou o termo para todos os workflows dali em diante.
O último detalhe é o que mostra que alguém pensou no assunto. Um aprendizado nunca muda as regras no meio da rodada. O motor compila estágios, regras e checagens uma vez, quando o workflow começa, e mantém essa visão compilada até o fim. Os gates que você aprovou antes atestaram um conjunto estável de regras, e o chão não se mexe embaixo de um workflow em andamento.
Regras e sensores: a AWS agora fala de harness engineering
A versão 2 divide o direcionamento em duas metades. Regras são instruções em prosa carregadas antes do trabalho (feedforward). Sensores são checagens determinísticas disparadas sobre a saída, como um linter ou uma checagem de tipos (feedback). A AWS chama o par de control loop.
As regras se resolvem em cinco camadas, e o modelo é estritamente aditivo: toda camada aplicável está no contexto ao mesmo tempo, e nada sobrescreve nada em silêncio.
As cinco camadas de regras
- ORG
Organização
Padrões do framework e da empresa: trunk-based development, postura de testes, política de walking skeleton.
- TEAM
Time
Práticas que o seu time confirmou, incluindo as que o Practices Discovery encontrou.
- PROJ
Projeto
A especialização deste projeto. É onde o loop de aprendizado escreve por padrão.
- PHASE
Fase
Regras para todos os estágios de uma fase, como documentar duas alternativas para cada decisão de arquitetura na Inception.
- STAGE
Estágio
Reservado para uma release futura.
O repositório traz até um Harness Engineer Guide para remodelar estágios, agentes, regras, sensores e conhecimento sem mexer no código do motor. Faz meses que eu defendo que o harness é onde mora a sua vantagem. Foi bom ver a AWS colocar a palavra na própria documentação.
A Construction ganhou checkpoints verificados
A versão 1 pedia aprovação para cada estágio da Construction em cada Unit. Numa feature com seis Units e cinco estágios cada, são trinta aprovações, a maioria em documentos de design que ninguém leria duas vezes. A fadiga de aprovação foi uma das primeiras coisas a quebrar nos pilotos que acompanhei.
A versão 2 mudou o padrão para trabalho solo novo com Units. Ela constrói uma Unit por vez, na ordem das dependências, e pede a sua aprovação para cada Unit concluída num checkpoint verificado, em vez de pedir aprovação para cada documento intermediário. Verificado quer dizer uma coisa específica: no Delivery Planning, o agente propõe uma checagem real do projeto (bun test, pytest, make check), você aprova aquele comando exato, e o motor reaproveita esse comando em todo checkpoint. Mudar depois exige a sua aprovação de novo. Um arquivo de prova escrito à mão não verifica uma Unit.
O que a Construction te pergunta na versão 2
- Obrigatório:Aprovar o plano de cada Unit antes de gerar código.A aprovação de plano continua humana em qualquer modo.
- Obrigatório:Aprovar o comando de verificação, uma vez.Reaproveitado em todo checkpoint. Trocar exige uma nova aprovação humana.
- Obrigatório:Aprovar o walking skeleton, quando ele está ligado.A primeira Unit é a menor fatia funcionando de ponta a ponta, verificada pelo comando antes de as outras começarem.
- Opcional:Escolher: seguir automaticamente ou revisar cada checkpoint.O automático pula as perguntas de rotina na conclusão. Nunca pula a aprovação de plano, o comando ou as falhas.
- Obrigatório:Decidir em toda falha.Uma Unit que falha para a Construction e oferece retry, skip ou abort, mesmo no modo automático.
Também existe um modo de time. Com a propriedade das Units definida como de time, as pessoas reivindicam Units e constroem cada uma no seu checkout ao mesmo tempo, cada uma com o seu ritmo de gates. A versão 1 não tinha nada parecido. Os times que queriam construção em paralelo tinham que inventar.
Guardas, e quem pode baixá-las
A versão 2 acrescenta uma Guard Policy por peça de trabalho, com três valores: strict, relaxed e off. Ela controla cinco cercas: aprovação de plano, congelamento de review, transição de estado, escopo de leitura do revisor e presença humana. O Enterprise vem em strict. Os outros perfis vêm em off, o que deixa quatro das cercas saírem do caminho em trabalho sem direção explícita, e toda vez que uma cerca sai do caminho o log de auditoria registra.
A quinta cerca é a interessante. A presença humana não pode ser baixada para um workflow isolado. Um gate apresentado a você precisa de uma mensagem real sua. O único jeito de contornar é uma variável de ambiente que vale para a máquina inteira, que é o nível certo de atrito para “deixa o agente aprovar o próprio trabalho”.
Multi-repo agora é nativo
A versão 1 era de repositório único. Feature de verdade raramente é: um back-end, um front-end, talvez um app mobile, cada um no seu repo. Os times que acompanhei contornavam rodando uma sessão por stack e apontando o agente para o diretório do outro repo como material de referência, com o contrato entre eles combinado na mão antes.
A versão 2 suporta intents multi-repo. Você declara o conjunto de repositórios quando cria a intent (ou deixa o motor descobrir os repositórios irmãos), a Construction ancora cada operação de git num repo específico, e o Reverse Engineering precisa completar uma cadeia de varredura inteira por repositório antes que o estágio possa ser aprovado. O contorno virou uma flag.
O registro agora é algo que você consulta
Toda intent ganha a própria pasta de registro em aidlc/spaces/<space>/intents/. Lá dentro: o arquivo de estado, com um checkbox de seis estados por estágio (não iniciado, em andamento, aguardando aprovação, em revisão, concluído, pulado), todos os artefatos, todos os arquivos de perguntas e um log de auditoria só de acréscimo com 108 tipos de evento. A versão 1 também tinha arquivo de estado e arquivo de auditoria. A versão 2 transformou os dois na fonte de verdade do motor e acrescentou um runtime graph compilado a partir do log de auditoria a cada transição.
Isso torna o workflow mensurável sem ferramenta nova. O /aidlc-session-cost mostra duração, resultado dos estágios e aprendizados. O /aidlc-replay narra a sessão para quem não estava lá. O aidlc attest diz se o conteúdo de um commit ainda bate com o que um revisor aprovou. Escrevi sobre como usar esses dados em depois dos story points.
O que o AI-DLC 2 tornou obsoleto
Agora a parte que as notas de release não contam.
O time que acompanhei mais de perto mantinha um overlay em cima da versão 1: um conjunto de extensões, comandos e patches que encaixava o método na organização. Era trabalho bom, feito por gente que rodava o método todo dia e consertava o que doía. Aí o AI-DLC 2 chegou e entregou a maior parte disso como nativo.
O que os times construíram na versão 1, e o que a versão 2 entrega
| Camada caseira na versão 1 | Nativo na versão 2 |
|---|---|
| Um arquivo de estado compartilhado que toda skill customizada lia e atualizava, para uma sessão nova conseguir retomar depois de limpar o contexto | Uma máquina de estados com checkboxes de seis estados, um breadcrumb de recuperação antes da compactação e o /aidlc --resume |
| Patches injetados nas regras do core sem fazer fork | Um sistema de plugins que só acrescenta, nunca edita o core, com comandos de validate, build e sync |
| Uma retrospectiva automática depois do Build and Test que procurava onde a IA tinha falhado | O loop de aprendizado: diários por estágio, candidatos no gate, regras que valem no próximo workflow |
| Um plano para paralelizar a construção com git worktrees | Execução em swarm com um worktree por Unit, e modo de time com reivindicação de Units |
| Rodar uma sessão por stack e apontar para o outro repo na mão | Intents multi-repo com reverse engineering por repositório |
| Arquivar os artefatos de cada tarefa concluída para começar a próxima do zero | Pastas de registro por intent, spaces e comandos de arquivamento de intent |
É isso que acontece com toda camada de encanamento que você constrói em cima de um framework que anda rápido. Se a lacuna é genérica, o fornecedor vê a mesma lacuna em todo cliente e entrega. O seu repasse de estado esperto vira recurso deles, e o seu código vira trabalho de migração.
O que sobreviveu à reescrita
Aqui está a lista do que não foi absorvido, e é a lista que eu protegeria.
O que a versão 2 não substituiu
- Obrigatório:As regras contra vibe coding.Nunca editar código gerado na mão. Pedir o impacto antes de uma mudança grande. Pedir a crítica num contexto limpo. Elas nasceram de ver o agente falhar, e nenhum motor codifica isso por você.
- Obrigatório:O ritual antes do código.Como uma intenção ganha forma antes de o AI-DLC vê-la: o documento de entrada, as fontes curadas, a triagem de complexidade. A Ideation ajuda. Ainda assume que alguém conhece o problema.
- Obrigatório:Quem senta no mob.Só quem tem poder de decisão sobre alguma dimensão do trabalho. A versão 2 tem um estágio de Team Formation; ele não sabe dizer quem decide na sua empresa.
- Obrigatório:Ritmo.Sessões de uma hora, managers nos primeiros mobs, pausas entre gates. A versão 2 melhorou os gates. Gente cansada continua aprovando qualquer coisa.
- Obrigatório:O conhecimento da própria organização.As bibliotecas internas para injetar antes da geração de código, os registros de decisão, onde mora a documentação confiável.
- Obrigatório:Saber quando não usar.Uma mudança de uma linha não precisa de AI-DLC, em versão nenhuma.
Então a lição para quem está adotando um framework de IA em 2026: construa julgamento, alugue encanamento. Gaste o seu tempo de engenharia nas partes que codificam como a sua organização decide, e mantenha fina a máquina genérica, porque o fornecedor está prestes a entregá-la. É o argumento de não adote o AI-DLC, roube dele, e a versão 2 é a prova mais forte dele.
Vale migrar da versão 1?
Se você tem um workflow em andamento na versão 1, termine, e comece a próxima intent na versão 2. A própria versão 2 se recusa a atualizar um projeto enquanto há um workflow ativo, o que diz muito sobre como a AWS pensa em mudar o chão embaixo de trabalho em andamento.
Escolha o Classic para essa primeira rodada. Ele reproduz a cerimônia da versão 1 em 18 dos 33 estágios, então o seu time aprende o motor novo sem precisar aprender também um processo novo. Quando o Classic virar rotina, teste o Feature numa mudança real de produção e ligue o walking skeleton.
E antes de portar as suas camadas caseiras, separe todas nas duas listas acima. O encanamento provavelmente já tem um equivalente nativo; apague. O julgamento não tem; leve para regras, memória do time ou um plugin que só acrescenta. O setup em si está em AI-DLC com Claude Code, e se a sua base de código é antiga e grande, leia antes AI-DLC em brownfield.
Perguntas frequentes
Quando o AI-DLC 2 foi lançado?
A primeira release estável da linha 2.x, o AI-DLC 2.7.0, foi publicada em 1º de setembro de 2026. A 2.8.0 veio em 8 de setembro, a 2.9.0 em 15 de setembro e a 2.10.0 em 24 de setembro. As versões 2.0 a 2.6 nunca saíram como releases estáveis.
O AI-DLC 2 é compatível com workflows da versão 1?
Não como substituição direta. A versão 2 é outra instalação, um comando nativo aidlc mais os runtimes de cada harness, e guarda o estado em pastas de registro por intent.
Termine os workflows da versão 1 que estão em andamento onde estão e comece as intents novas na versão 2. O perfil Classic reproduz a cerimônia da versão 1, então o processo fica familiar.
Qual a diferença entre os perfis Classic e Feature?
O Classic roda 18 dos 33 estágios: Inception e Construction com uma aprovação por estágio, pulando Ideation e Operation, como na versão 1. O Feature roda os 33 estágios com profundidade padrão, da captura da intenção até o deploy e o retorno.
O AI-DLC 2 ainda exige Kiro ou Amazon Q?
Não. A versão 2 roda um motor só em sete harnesses: Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode e GitHub Copilot. O README recomenda o Claude Opus 4.8 como modelo.
O que é o loop de aprendizado do AI-DLC?
Cada estágio mantém um diário das decisões que o agente tomou. No gate de aprovação você escolhe quais guardar, e as guardadas viram regras na memória do projeto ou do time. Elas valem a partir do início do próximo workflow, nunca no meio do atual.
O AI-DLC 2 é open source?
É. Os workflows estão publicados em github.com/awslabs/aidlc-workflows sob a licença MIT-0. Você paga só pelo modelo que o seu agente de código usa.
Para onde ir agora
O AI-DLC 2 agora é um motor de verdade, e fechou a maior parte das lacunas que deixavam a versão 1 difícil de rodar em escala. Use. Mas repare no que ele absorveu e no que deixou de fora, porque essa linha diz onde o seu próprio trabalho deve ir.
A newsletter
Don’t Code, Specify. Toda semana, agentes de IA em produção de verdade. Sem hype: o que funcionou e o que quebrou.
Assinar no Substack (abre em nova aba)