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

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: Inception (Mob Elaboration), Construction (Mob Construction) e Operations — com o contexto persistido no repositório entre elas.
Vocabulário novo: sprints viram bolts (horas/dias, não semanas); Epics viram Units of Work.
Dá para implementar hoje com Kiro combinando steering (que codifica o ritual e o modelo mental) e specs (Inception→requirements.md, Construction→design.md+tasks.md, Operations→IaC).

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.

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.
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. O AI-DLC é agnóstico de ferramenta, mas o Kiro tem exatamente as duas primitivas que ele exige: 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, com workflows que implementam a metodologia. É o ponto de partida para ver os rituais materializados.
White paper do AI-DLC — o documento aberto onde Raja SP formaliza as duas dimensões, o modelo mental e as três fases.

O que o Kiro adiciona é a execução: 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
Kiro Steering: https://kiro.dev/docs/steering/
Kiro Specs: https://kiro.dev/docs/specs/

Este artigo foi publicado originalmente no Medium. 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 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

Publicado originalmente em prompt.victorbatistax.com. Se você chegou por outra plataforma, esta é a versão canônica.