AI-DLC: a metodologia da AWS que reimagina o ciclo de desenvolvimento (e como implementar com Kiro)

Victor Batista — Fri, 11 Sep 2026 14:06:13 +0000

TL;DR

AI-DLC (AI-Driven Development Life Cycle) é uma metodologia criada por Raja SP (Principal Solutions Architect da AWS), com white paper aberto e repo open source awslabs/aidlc-workflows.
Diagnóstico central: adotar IA como assistente (autocomplete glorificado) ou como agente totalmente autônomo são os dois extremos subótimos. O ponto ótimo é execução por IA com supervisão humana.
Modelo mental que se repete em cada atividade: a IA cria um plano → faz perguntas → implementa só depois da validação humana.
3 fases conceituais: Inception (Mob Elaboration), Construction (Mob Construction) e Operations — com o contexto persistido no repositório entre elas. (Atualização set/2026: a implementação de referência awslabs/aidlc-workflows hoje formaliza **5 fases* — Initialization, Ideation, Inception, Construction, Operation — em 33 stages, com um verification gate em cada fronteira.)*
Vocabulário novo: sprints viram bolts (horas/dias, não semanas); Epics viram Units of Work.
A novidade que muda o jogo (set/2026): o awslabs/aidlc-workflows agora roda nativamente no Kiro CLI (≥ 2.6) e no Kiro IDE — além de Claude Code, Codex CLI, Cursor, opencode e GitHub Copilot. Você instala o comando aidlc, roda aidlc config --harness kiro e invoca o fluxo com /aidlc. O caminho DIY (steering + specs) continua válido para entender o ritual por dentro.

Atualização — setembro de 2026. Este artigo foi publicado em julho/2026. Desde então, a implementação de referência awslabs/aidlc-workflows amadureceu de um conjunto de workflows para um orquestrador nativo que roda dentro do harness que você já usa (Kiro CLI, Kiro IDE, Claude Code, Codex CLI, Cursor, opencode, GitHub Copilot). Os conceitos centrais — as 2 dimensões e o modelo mental — seguem idênticos; o que mudou foi o como implementar. As seções abaixo trazem o texto original com notas de atualização onde os fatos mudaram.

O problema: IA nova, processo velho

A cena mais comum de 2026 é esta: um time compra assentos de uma ferramenta de IA, pluga no editor, e espera que a produtividade dispare. Na prática, ele acelerou a digitação — mas manteve intacto um processo que já vazava valor em todas as juntas. Requisitos ambíguos continuam ambíguos, só que agora a IA implementa a ambiguidade mais rápido. O handoff entre "quem entende o negócio" e "quem escreve o código" continua lá, só que com um autocomplete no meio. Você colou IA por cima de um processo ineficiente e chamou de transformação.

O diagnóstico do AI-DLC é que existem dois modos de usar IA no desenvolvimento, e ambos são subótimos quando adotados de forma pura:

IA como assistente: ela sugere, você aceita ou rejeita linha a linha. O humano continua sendo o gargalo — a IA nunca sai do banco de trás. Você ganha velocidade de digitação, não de raciocínio.
IA totalmente autônoma: você joga um prompt e reza. Ela decide arquitetura, faz suposições silenciosas sobre requisitos e entrega algo que compila e está errado nos detalhes que importam. O humano perde a rédea justamente nas decisões caras de reverter.

O AI-DLC não escolhe entre "IA que ajuda" e "IA que faz tudo". Ele reorganiza o ciclo para que a IA execute e o humano decida — nos pontos certos.

O AI-DLC (AI-Driven Development Life Cycle) foi proposto por Raja SP, Principal Solutions Architect da AWS, e não é um produto: é uma metodologia com white paper aberto e um repositório de referência open source, o awslabs/aidlc-workflows. A ideia é reimaginar o SDLC assumindo a IA como executora principal — e desenhar os rituais humanos ao redor disso, em vez de encaixar a IA num ritual desenhado para humanos.

As 2 dimensões

O AI-DLC se apoia em duas dimensões que operam ao mesmo tempo. Elas são o que diferencia a metodologia de "usar IA com bom senso".

1. AI Powered Execution with Human Oversight

A IA é a executora: ela redige requisitos, propõe arquitetura, escreve código e testes. Mas ela opera sob três disciplinas explícitas:

Cria planos antes de agir — nunca sai implementando; primeiro expõe a estratégia.
Pede clarificação — quando há ambiguidade, ela pergunta em vez de supor.
Adia decisões críticas ao humano — escolhas de arquitetura, trade-offs de negócio e qualquer coisa cara de reverter voltam para a mesa do humano.

O humano deixa de revisar linha a linha (trabalho de baixo valor) e passa a revisar planos e decisões (trabalho de alto valor). É uma inversão de onde a atenção humana é gasta.

2. Dynamic Team Collaboration (mob)

A segunda dimensão é social. Em vez de fatiar o trabalho em tarefas individuais que depois são costuradas em code review, o AI-DLC usa colaboração dinâmica no estilo mob: o time se reúne ao redor da IA nas atividades de elaboração e construção. A IA gera o artefato (requisito, design, código); o grupo valida, corrige e decide junto, em tempo real. O conhecimento não fica preso na cabeça de um autor — ele emerge na conversa e é capturado no repositório.

Isso muda o significado do code review: boa parte da revisão acontece durante a geração, com o time presente, e não depois, de forma assíncrona e tardia.

O modelo mental

Se você guardar uma única coisa deste artigo, guarde este loop. Ele é a assinatura do AI-DLC e se repete em cada atividade do ciclo:

┌─────────────────────────────────────────────────────┐
│                                                       │
│   1. IA cria um PLANO                                 │
│      (o que pretende fazer, em passos explícitos)     │
│                     │                                 │
│                     ▼                                 │
│   2. IA faz PERGUNTAS                                 │
│      (dúvidas, ambiguidades, decisões que são suas)   │
│                     │                                 │
│                     ▼                                 │
│   3. Humano VALIDA                                    │
│      (aprova o plano, responde, ajusta o rumo)        │
│                     │                                 │
│                     ▼                                 │
│   4. IA IMPLEMENTA                                    │
│      (só depois da validação — nunca antes)           │
│                                                       │
└───────────────── repete a cada atividade ────────────┘

Note a ordem: plano → perguntas → validação → implementação. A implementação é sempre o último passo, nunca o primeiro. Isso é o oposto do "vibe coding", onde a implementação vem primeiro e o entendimento (se vier) vem depois. E não é burocracia: o loop roda em minutos, não em reuniões de aprovação de dias.

As 3 fases

O AI-DLC organiza o ciclo em três fases. O ponto-chave é que o contexto é persistido no repositório entre elas — o que a fase de Inception produziu fica disponível, versionado, para a Construction, e assim por diante. Não há conhecimento evaporando em threads de chat.

Fase	Ritual	O que a IA faz	O que o humano decide
Inception	Mob Elaboration	Traduz intenção em requisitos, user stories e Units of Work; levanta ambiguidades	Aprova o escopo, resolve ambiguidades de negócio, prioriza
Construction	Mob Construction	Propõe arquitetura e domain models; escreve código e testes	Valida decisões arquiteturais, trade-offs, contratos de API
Operations	—	Gera IaC e prepara deploy	Aprova a topologia, políticas de segurança, o go/no-go de produção

Inception (Mob Elaboration)

Ponto de partida: uma intenção ("queremos que clientes avaliem produtos que compraram"). A IA a transforma em requisitos estruturados, stories e Units of Work, fazendo perguntas onde a intenção é vaga ("avaliação exige compra confirmada? há moderação?"). O humano decide o que é escopo e o que fica de fora. O produto desta fase é um entendimento compartilhado e escrito — não a memória de uma reunião.

Construction (Mob Construction)

Com os requisitos aprovados, a IA propõe a arquitetura, os modelos de domínio, e depois escreve código e testes. As decisões arquiteturais caras (banco relacional vs. documento, síncrono vs. evento, contratos entre serviços) sobem para o humano no formato de plano — antes de virarem código. O time valida em mob; a IA implementa.

Operations

A IA gera infraestrutura como código e prepara o deploy, sempre sob supervisão. Aqui o humano decide topologia, políticas de segurança e o momento de promover para produção. A automação chega até a porta de produção; quem abre a porta é gente.

Atualização set/2026 — de 3 fases conceituais para 5 fases na prática. A metodologia (white paper) descreve o arco conceitual em três fases. A implementação de referência awslabs/aidlc-workflows hoje as materializa em 5 fases sequenciais — Initialization → Ideation → Inception → Construction → Operation — com 33 stages no total e um verification gate em cada fronteira de fase. Ela também adiciona workflow profiles / scopes (/aidlc express, /aidlc feature ..., /aidlc bugfix ..., entre 11 scopes + auto-detecção) e 3 níveis de profundidade, de modo que um bugfix não percorre os mesmos 33 stages de uma feature completa. A filosofia declarada é "Small Mob, Broad Agents": 14 agentes (11 especialistas de domínio + 2 revisores + 1 compositor), cada um atuando em várias fases para eliminar handoffs — e cada stage ainda termina num approval gate humano.

Vocabulário novo (e por que ele importa)

Metodologia nova traz palavras novas — e aqui elas carregam intenção real, não são cosméticas:

sprints → bolts. Um bolt é uma unidade de trabalho de horas ou dias, não de duas semanas. O nome sugere um "raio": a IA comprime o ciclo de elaboração-construção-validação a ponto de o horizonte de planejamento encolher de semanas para horas. Se um bolt ainda leva semanas, você não está fazendo AI-DLC. (Na implementação de referência, o bolt é definido com precisão como uma iteração de Construction, no estilo de um sprint, sobre uma ou mais Units interligadas por dependência — planejada no stage de Delivery Planning.)
Epics → Units of Work. Em vez do "epic" (que na prática virou uma caixa onde requisitos vagos hibernam por trimestres), o AI-DLC usa Units of Work: recortes de valor pequenos o bastante para caber num bolt e serem elaborados pela IA de ponta a ponta.

Trocar "sprint" por "bolt" não é rebranding. É admitir que, quando a IA executa e o humano decide, a unidade de tempo do desenvolvimento muda de ordem de grandeza.

Implementando AI-DLC com o Kiro

Aqui está a parte prática — e é onde a atualização de setembro/2026 pesa mais. Hoje existem dois caminhos para rodar AI-DLC com o Kiro, e vale conhecer os dois.

Caminho A (recomendado) — o orquestrador oficial rodando nativo no Kiro

O awslabs/aidlc-workflows deixou de ser "um repo de workflows para copiar" e virou um orquestrador nativo que roda dentro do harness que você já usa — incluindo Kiro CLI (≥ 2.6) e Kiro IDE. A instalação é um comando:

# macOS, Linux ou WSL
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.sh | sh

# no diretório do projeto, configure o harness Kiro
cd /caminho/do/seu-projeto
aidlc config --harness kiro      # ou --harness kiro-ide para o IDE
aidlc doctor                     # checagem de saúde

Depois é só abrir o Kiro (kiro-cli chat) e invocar o fluxo com uma frase de intenção:

/aidlc Construir uma API REST de avaliações de produto

O orquestrador seleciona um workflow profile a partir do pedido — ou você escolhe explicitamente:

/aidlc express
/aidlc feature Adicionar notificações ao cliente
/aidlc bugfix Corrigir o timeout de login

A partir daí, um engine determinístico decide qual stage vem a seguir e o Kiro (o "conductor") executa cada stage adotando a persona do agente certo, gravando o estado em aidlc-state.md e a trilha de auditoria no diretório do intent (aidlc/spaces/<space>/intents/<YYMMDD>-<label>/). Cada stage termina num approval gate — o modelo mental "plano → perguntas → validação → implementação" continua sendo a lei, só que agora vem embalado e versionado por padrão.

Use este caminho quando quiser o AI-DLC "de fábrica": os 33 stages, os 14 agentes e a trilha de auditoria completa, sem manter o ritual à mão.

Caminho B (DIY) — codificar o ritual você mesmo com steering + specs

O caminho abaixo era a única opção quando este artigo saiu, e continua valendo — é a melhor forma de entender o AI-DLC por dentro e de aplicá-lo de forma leve, sem instalar o orquestrador. Ele usa as duas primitivas nativas do Kiro: steering (para codificar o ritual e o modelo mental de forma persistente) e specs (para materializar as fases como artefatos versionados no repositório).

Passo 1 — Um steering file que codifica o ritual do bolt

O modelo mental "plano → perguntas → validação → implementação" não pode viver na sua cabeça: ele precisa estar no repositório, para que a IA o siga em toda sessão. Isso é exatamente o papel de um steering file. Vou usar inclusion: manual, para invocar o ritual explicitamente quando iniciar um bolt (ele aparece como slash command). Se você quiser que ele seja injetado automaticamente com base no contexto, troque para inclusion: auto com name e description.

Crie .kiro/steering/ai-dlc-bolt.md:

---
inclusion: manual
---
# Ritual de um Bolt (AI-DLC)

Você opera sob o AI-DLC: **execução por IA com supervisão humana**.
Um "bolt" é uma unidade de trabalho de horas/dias sobre uma **Unit of Work**.
Nunca pule etapas. Nunca implemente antes da validação.

## Modelo mental (obrigatório em CADA atividade)
1. **PLANO**: descreva, em passos explícitos, o que pretende fazer antes de tocar em qualquer arquivo.
2. **PERGUNTAS**: liste toda ambiguidade e toda decisão que é do humano
   (regras de negócio, trade-offs de arquitetura, contratos de API, segurança).
   Se houver dúvida, PERGUNTE — não suponha.
3. **VALIDAÇÃO**: aguarde a aprovação humana do plano e as respostas às perguntas.
4. **IMPLEMENTAÇÃO**: só então implemente. A implementação é sempre o último passo.

## Decisões que você SEMPRE adia ao humano
- Escolha de arquitetura e persistência (relacional x documento, síncrono x evento).
- Contratos entre serviços e mudanças de API pública.
- Políticas de segurança, autenticação e autorização.
- Qualquer mudança cara de reverter ou com impacto em produção.

## Onde persistir o contexto (entre fases e sessões)
- Inception  -> `.kiro/specs/<unit-of-work>/requirements.md`
- Construction-> `.kiro/specs/<unit-of-work>/design.md` + `tasks.md`
- Operations -> infraestrutura como código no repositório

O contexto vive no REPOSITÓRIO, não no chat. Sempre grave o resultado de cada fase.

Repare no que este arquivo faz: ele transforma uma metodologia (algo que normalmente mora num white paper que ninguém relê) em instrução operacional que a IA carrega toda vez. É o AI-DLC deixando de ser slide e virando comportamento.

Passo 2 — Mapear as fases nos artefatos de spec do Kiro

As specs do Kiro já têm o formato de três fases que o AI-DLC precisa. A pasta .kiro/specs/<unit-of-work>/ gera três arquivos, e o mapeamento é direto:

.kiro/specs/avaliacoes-de-produto/     ← uma Unit of Work
├── requirements.md   ← Inception (Mob Elaboration)
│                        intenção → user stories + critérios EARS
├── design.md         ← Construction (Mob Construction)
│                        arquitetura, domain model, fluxo, testes
└── tasks.md          ← Construction → execução do bolt
                         tarefas discretas e rastreáveis

O requirements.md usa notação EARS (Easy Approach to Requirements Syntax), que é onde a IA cristaliza a intenção elaborada em mob e onde as ambiguidades levantadas na fase de perguntas ficam resolvidas por escrito:

# Requisitos — Avaliações de Produto (Unit of Work)

## User Story 1: Criar avaliação
Como cliente autenticado, quero avaliar um produto que comprei,
para ajudar outros compradores.

### Critérios de aceitação (EARS)
- WHEN um cliente autenticado envia uma avaliação com nota de 1 a 5,
  THE SYSTEM SHALL persistir a avaliação e associá-la ao produto e ao usuário.
- IF o usuário não comprou o produto,
  THEN THE SYSTEM SHALL rejeitar a avaliação com HTTP 403.
- WHERE a avaliação contém linguagem sinalizada pelo filtro,
  THE SYSTEM SHALL marcá-la como "pendente de moderação".

Cada critério EARS aqui é a materialização do loop: era uma pergunta na fase de Inception ("avaliação exige compra?"), foi validado pelo humano, e virou um SHALL que a IA vai implementar na Construction. A fase de Construction produz o design.md (com a arquitetura e os diagramas de sequência que o humano validou em mob) e o tasks.md, cujas tarefas são a execução propriamente dita do bolt. Como o Kiro roda "Run all Tasks" construindo um grafo de dependências e agrupando tarefas independentes em waves, um único bolt pode paralelizar boa parte da implementação — reforçando por que a unidade de tempo encolheu de sprint para bolt.

Na fase de Operations, o mesmo ritual continua: a IA propõe o IaC (por exemplo, um template gerado a partir do design.md), apresenta o plano, e você aprova a topologia e as políticas antes do deploy. Se quiser fechar o loop com automação, um hook de PostFileSave sobre os arquivos de infraestrutura pode disparar validação — mas a decisão de promover para produção permanece humana, por desenho.

Passo 3 — Referências oficiais

Não reinvente a roda. O AI-DLC tem material canônico:

awslabs/aidlc-workflows — o repositório open source de referência. Hoje é um orquestrador nativo (não mais só "workflows para copiar") com instalação via aidlc e documentação própria em awslabs.github.io/aidlc-workflows. É o ponto de partida para rodar o AI-DLC "de fábrica" no Kiro.
White paper do AI-DLC — o documento aberto onde Raja SP formaliza as duas dimensões, o modelo mental e as fases.

No Caminho A, o Kiro é o harness que executa o orquestrador oficial. No Caminho B, o que o Kiro adiciona é a execução artesanal: steering para o ritual, specs para os artefatos de cada fase, e o repositório como memória persistente entre bolts. A metodologia diz o quê; o Kiro entrega o como.

Benefícios (sem exagero)

O white paper elenca cinco benefícios. Vale enumerá-los com honestidade — eles são consequências prováveis de um processo bem executado, não garantias automáticas por instalar uma ferramenta:

Velocity: o ciclo elaboração→construção→validação encolhe de semanas (sprint) para horas/dias (bolt), porque a IA executa e o humano só decide nos pontos caros.
Innovation: com menos atrito para prototipar uma Unit of Work, o custo de testar uma ideia cai — e times testam mais ideias.
Quality: requisitos em EARS, design validado em mob e testes escritos na Construction empurram a verificação para antes do código existir, não depois.
Market responsiveness: bolts curtos significam que uma mudança de prioridade custa horas de replanejamento, não um sprint inteiro.
Developer experience: o desenvolvedor sai da revisão linha a linha (tédio de baixo valor) e passa a decidir arquitetura e negócio (o trabalho que dá orgulho).

O trade-off honesto: o AI-DLC exige disciplina de ritual. Se o time pular o "plano → perguntas → validação" para "ir mais rápido", ele recai no vibe coding e perde exatamente a qualidade que a metodologia promete. A velocidade vem da disciplina, não da ausência dela.

Armadilhas comuns

Tratar o steering como decoração: se o arquivo ai-dlc-bolt.md existe mas ninguém o invoca (no modo manual) nem confia nas perguntas da IA, o ritual não acontece. Codificar não é o suficiente; é preciso respeitar o loop.
Units of Work grandes demais: se a Unit não cabe num bolt, ela vira o velho epic disfarçado. Recorte até caber em horas/dias.
Pular a fase de perguntas: aprovar o plano da IA sem responder às ambiguidades é convidar a suposição silenciosa de volta. As perguntas são o mecanismo de defesa.
Automação até dentro de produção: gerar IaC é ótimo; promover para produção sem gate humano contraria a própria dimensão de "human oversight".

Principais aprendizados

O erro dominante não é a IA — é colar IA sobre um processo ineficiente. O AI-DLC reimagina o ciclo com a IA como executora e o humano como decisor.
As 2 dimensões são execução por IA com supervisão humana + colaboração dinâmica (mob). Juntas, movem a atenção humana de "revisar código" para "validar planos e decisões".
O modelo mental — plano → perguntas → validação → implementação — se repete em cada atividade e é o coração da metodologia.
As 3 fases (Inception, Construction, Operations) persistem contexto no repositório; o vocabulário muda (sprints→bolts, Epics→Units of Work) porque a ordem de grandeza do tempo muda.
No Kiro, isso vira concreto: steering codifica o ritual, specs materializam as fases (requirements.md→Inception, design.md+tasks.md→Construction, IaC→Operations). Comece pelo awslabs/aidlc-workflows e pelo white paper.

Referências

AI-Driven Development Life Cycle (AWS DevOps Blog, Raja SP): https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
Open-Sourcing Adaptive Workflows for AI-DLC (AWS): https://aws.amazon.com/blogs/devops/open-sourcing-adaptive-workflows-for-ai-driven-development-life-cycle-ai-dlc/
Building with AI-DLC using Amazon Q Developer (AWS): https://aws.amazon.com/blogs/devops/building-with-ai-dlc-using-amazon-q-developer/
awslabs/aidlc-workflows (GitHub): https://github.com/awslabs/aidlc-workflows
Documentação do awslabs/aidlc-workflows (5 fases, 33 stages, harnesses): https://awslabs.github.io/aidlc-workflows/
Rodando AI-DLC no Kiro CLI: https://awslabs.github.io/aidlc-workflows/guide/harnesses/kiro-cli/
AI-Driven Development Lifecycle for Financial Services (AWS): https://aws.amazon.com/blogs/industries/ai-driven-development-lifecycle-for-financial-services/
Kiro Steering: https://kiro.dev/docs/steering/
Kiro Specs: https://kiro.dev/docs/specs/

Este artigo foi publicado originalmente no Medium em julho/2026 e **atualizado em setembro/2026* para refletir a evolução do awslabs/aidlc-workflows (orquestrador nativo, 5 fases/33 stages, suporte a Kiro CLI/IDE e outros harnesses). Preços, nomes de modelos e detalhes de produto refletem o estado do Kiro em meados de 2026 e podem mudar — confirme em kiro.dev e na documentação do awslabs/aidlc-workflows antes de tomar decisões. Este é um conteúdo educacional independente, sem vínculo oficial com a AWS.*

Tags: kiro, aws, ai-dlc, spec-driven-development, ai-agents

DEV Community: Victor Batista