Kiro e spec-driven development: o que é e como a ferramenta organiza spec, plano e tarefas?

Você já pediu uma feature pra IA, recebeu quinze arquivos de volta e não fez ideia de como auditar aquilo?

Pois é, esse é o buraco que o vibe coding sem baliza abre: começo rápido, e depois ninguém sabe explicar por que o sistema faz o que faz

O Kiro é a resposta da AWS pra isso: em vez de sair gerando código, ele transforma o seu pedido em documento antes, e só depois parte pra implementação

Neste post eu explico o que a ferramenta é, como ela organiza spec, plano e tarefas, quanto custa e pra que tipo de projeto esse formato faz sentido

Bora ver? 🙂

De onde vem o Kiro: AWS, Code OSS e o fim do Amazon Q Developer

O Kiro é um ambiente de desenvolvimento agêntico da AWS (Amazon Web Services)

Ele existe em três formatos: IDE, CLI e interface web

O IDE não foi criado do zero: ele é construído sobre o Code OSS, que é a base open source do VS Code, e usa o registro de extensões Open VSX

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Que diferença isso faz? Se você conhece o VS Code, o ambiente vai parecer familiar, e o onboarding permite importar suas configurações e temas de lá

Sobre onde roda: o Kiro IDE está disponível para macOS, Windows e Linux, e o Kiro CLI para macOS e Linux

A disponibilidade geral (GA) foi anunciada em 17 de novembro de 2025, junto com o Kiro CLI, planos para times via AWS IAM Identity Center, checkpointing e property-based testing

E por que a AWS está empurrando esse formato agora?

Tem um contexto que ajuda a entender o movimento

A AWS anunciou o fim de suporte do Amazon Q Developer: novos cadastros ficaram indisponíveis a partir de 15 de maio de 2026, e os plugins de IDE e as assinaturas pagas chegam ao fim de suporte em 30 de abril de 2027

Ou seja, o Kiro não é um experimento paralelo, é pra onde a casa está apontando

Os três arquivos de uma spec: requirements.md, design.md e tasks.md

Aqui está o coração da coisa

Toda spec do Kiro segue um fluxo de três fases: requisitos (ou análise do bug), design técnico e tarefas de implementação

E cada fase vira um arquivo markdown com nome fixo, dentro do seu projeto

Repare num detalhe que muda tudo: os artefatos ficam salvos no próprio projeto, na pasta .kiro/specs/

Isso significa que eles entram no seu versionamento como qualquer outro arquivo do repo

Dá pra revisar em pull request, dá pra ver o diff, dá pra discutir a mudança de requisito antes de alguém escrever uma linha de código

Bem diferente de um plano que vive só dentro do chat e some quando você fecha a janela, né? 😀

Como o Kiro escreve requisitos testáveis: a notação EARS e os portões de aprovação

"Requisito" costuma ser sinônimo de texto vago que ninguém consegue verificar

O Kiro tenta resolver isso com uma notação: EARS, de Easy Approach to Requirements Syntax

O padrão é WHEN <condição/evento> THE SYSTEM SHALL <comportamento esperado>

Parece burocrático, mas o ganho é direto: o requisito vira uma frase que dá pra checar como verdadeira ou falsa, não uma intenção genérica

E quem aprova o que, em qual momento?

Nas Feature Specs existem portões de aprovação entre as fases

Você revisa e aprova os requisitos antes do design, e aprova o design antes da implementação

Também existem dois pontos de partida possíveis, dependendo de onde o seu projeto nasce:

• Requirements-First: parte do comportamento desejado e deriva o design e as tarefas a partir dele
• Design-First: parte da arquitetura e do design técnico e deriva os requisitos e as tarefas

Útil quando a decisão técnica já está tomada e o que falta é escrever o comportamento em volta dela

O ciclo fecha na verificação

E aí vem a parte que eu achei mais massa: o property-based testing

Em vez de gerar exemplos individuais de teste, ele extrai propriedades dos requisitos em formato EARS e roda centenas de casos com entradas geradas aleatoriamente

Ou seja, o requisito que você aprovou lá no começo é o mesmo que vira critério de verificação no fim

Especificação e verificação amarradas, não dois documentos que se contradizem depois de três sprints

Feature Spec, Quick Spec e Bugfix Spec: qual usar em cada situação

Nem todo trabalho merece o ritual completo, e o Kiro reconhece isso

Esse Unchanged Behavior da Bugfix Spec é um achado

Quantas vezes o conserto de um bug quebrou outra coisa que estava de pé? Ter um campo explícito pro que precisa continuar igual é exatamente o tipo de baliza que falta quando a IA sai mexendo sozinha

Steering, hooks e checkpoints: o que segura o contexto entre uma spec e outra

Uma spec resolve uma feature

Mas e o conhecimento do projeto inteiro, aquele que você repete em todo prompt?

Pra isso existe o steering: arquivos markdown na pasta .kiro/steering/ do workspace, funcionando como conhecimento persistente do projeto

Entre os arquivos de base estão o tech.md (stack e ferramentas) e o structure.md (organização de arquivos, convenções de nome e decisões arquiteturais)

É a diferença entre explicar sua convenção de pastas toda santa vez e escrever isso uma vez só

Hooks: automação amarrada em gatilho

O Kiro também tem hooks, configurados por arquivos JSON em .kiro/hooks/ no nível do workspace

Os gatilhos disponíveis incluem agentSpawn, userPromptSubmit, preToolUse, postToolUse e stop

Quem já montou agentes de IA para tarefas específicas vai reconhecer a lógica na hora: evento acontece, ação dispara, você não precisa lembrar de fazer

Checkpoints: o botão de desfazer do agente

E tem os checkpoints, gerados a cada mudança ou ação do agente

Com isso dá pra voltar quantos passos quiser

Se o agente entrou numa espiral e destroçou o que estava funcionando, você rebobina em vez de rezar pro git stash

O que aconteceu quando testei o fluxo de spec na prática

No vídeo eu aplico spec-driven development num projeto de exemplo (um gerador de QR Code), escrevendo os três documentos na mão e rodando os prompts com a IA tarefa por tarefa

Eu sugiro 3 etapas de planejamento antes de programar: requisitos, design e tarefas, podendo ser mais ou menos dependendo do projeto

Bate com as três fases que o Kiro automatiza, e não é coincidência: essa é a espinha do método

No documento de requisitos eu escrevi a visão geral do projeto, detalhei cada funcionalidade e criei uma seção explícita de "o que o app NÃO faz", justamente pra IA não inventar escopo

O documento de design não é sobre cor de botão, se liga: ali entram stack, esquema de banco, rotas, páginas, componentes e decisões técnicas

Já as tarefas eu ordenei pela sequência que faz sentido no uso: setup inicial (pastas e bibliotecas), depois a autenticação por ser complexa e vital, depois a funcionalidade principal

E cada prompt executa UMA tarefa, sendo tarefa algo concreto (uma página, um recurso), não um ajustezinho de cor

O número que resume o custo-benefício

Com o planejamento pronto, a IA construiu a autenticação desse projeto de exemplo em cerca de 2 minutos

Mas olha a leitura honesta: o tempo caro não está na geração, está no planejamento

A etapa inicial demorou bem mais, e as tarefas seguintes é que andaram rápido

Se você odeia escrever requisito, vai sentir atrito nas primeiras horas, sem romantizar

A compensação vem depois, quando os prompts seguintes ficam simples e o processo fica previsível e sequencial

No vídeo você me vê montando os três documentos do zero, explicando o que entra em cada um e rodando os prompts tarefa por tarefa

Para que tipo de projeto o spec-driven development compensa (e para qual não)

Bora ser prático

O formato faz sentido quando:

• A feature tem regra de negócio de verdade: se existe critério de aceite pra discutir, escrever em EARS antes economiza retrabalho depois
• O bug mexe em área sensível: a Bugfix Spec com Current, Expected e Unchanged Behavior te obriga a declarar o que não pode quebrar
• Tem time revisando: os portões de aprovação das Feature Specs colocam a revisão no plano, não no código pronto, e existem planos para times via AWS IAM Identity Center
• O projeto é longo e tem convenção: o steering em .kiro/steering/ guarda stack e decisões arquiteturais pra não repetir contexto toda vez

E quando NÃO compensa?

Script descartável, protótipo de dez minutos, aquela POC que você vai jogar fora amanhã

Nesses casos os três documentos custam mais caro que o próprio código, e o caminho razoável é Quick Spec ou simplesmente nada

Spec pra tudo vira burocracia, e burocracia ninguém aguenta por muito tempo

Quanto custa o Kiro: planos, créditos e modelos disponíveis

Como o crédito é consumido?

Não é um crédito por prompt, e isso importa

Prompts simples podem consumir menos de 1 crédito

Prompts complexos, como executar uma tarefa de spec, costumam custar mais de 1

Ou seja, justamente o uso principal da ferramenta é o que pesa mais na conta

O processamento padrão é feito pelo Auto, um agente de roteamento que combina modelos de fronteira com modelos especializados, detecção de intenção e cache, pra equilibrar qualidade, latência e custo

E tem um detalhe de escolha de modelo: uma tarefa que consome X créditos no Auto custa 1,3X via Sonnet 4.6

Se acabar antes do mês virar, os planos individuais pagos podem comprar créditos adicionais avulsos a US$ 0,04 cada, cobrados na hora da compra

Vale a pena adotar o Kiro hoje?

O que a proposta entrega de concreto:

• Rastreabilidade do requisito até a tarefa, com os três arquivos amarrados no mesmo fluxo
• Artefatos versionáveis dentro do projeto, em .kiro/specs/, revisáveis como código
• Verificação por propriedades derivadas dos próprios requisitos em EARS

O que ela cobra em troca:

• Disciplina de ler e aprovar documento antes de ver código rodando, e isso é chato pra quem gosta da dopamina do resultado imediato
• Consumo maior de crédito exatamente nas tarefas de spec, que são o motivo de usar a ferramenta

Minha recomendação sem hype: comece pelo free tier de 50 créditos antes de colocar US$ 20 por mês nisso

50 créditos não é muito, mas dá pra sentir se o formato combina com o seu jeito de trabalhar

Conclusão

O Kiro spec-driven development não inventa uma tecnologia nova, ele inverte a ORDEM

Em vez de gerar e depois tentar entender, você especifica, revisa e só então deixa o agente escrever

Os três arquivos (requirements.md, design.md e tasks.md) são o que sobra dessa inversão: material auditável dentro do projeto, e não um plano que evaporou junto com o chat

Se quiser testar, o caminho mais barato é claro: baixa no free tier, roda uma Quick Spec numa feature pequena e LÊ o requirements.md gerado antes de aprovar qualquer coisa

É nessa leitura que você descobre se a IA entendeu o que você quis dizer, ou se ia sair construindo outra coisa

Dá uma olhada no vídeo aí em cima pra ver o método funcionando na prática, e fica de olho que vem mais post sobre spec-driven development por aqui

até o próximo post! 😀