O que é o Kiro? A IDE agêntica da AWS para Spec-Driven Development

A ferramenta que embute a spec na IDE não garante uma boa spec. Garante um caminho rápido para uma spec medíocre, se você pular a parte de pensar. O método vem primeiro.

O Kiro é a IDE agêntica da AWS construída em torno de spec-driven development. Você dá um prompt e ele gera uma especificação estruturada: três arquivos markdown com requisitos, design de arquitetura e tarefas de implementação em sequência. Depois entrega esses arquivos para agentes em paralelo, que escrevem o código. Ele roda como IDE para download, como CLI e como interface no navegador. É construído sobre o Code OSS (a base open source do VS Code) e roda os modelos Claude da Anthropic (até Opus 5.5 e Sonnet 5), a família GPT-5.6 da OpenAI e uma série de alternativas open-weight. Você não precisa de conta na AWS para começar.

Pratico spec-driven development todo dia com Claude Code e o meu pi-sdd-kit. Não rodei o Kiro em produção na escala da fintech cripto que construí (13 apps, 70 dias, sozinho), mas estudei a documentação a fundo, acompanhei a conversa na comunidade e li a avaliação prática da Birgitta Böckeler na Thoughtworks. O que segue é a leitura honesta de quem pratica: o que o Kiro é, como o workflow funciona de verdade, onde ele entrega valor real e onde estão os limites.

O que o Kiro é de fato

O Kiro é uma IDE que faz do spec-driven development o workflow padrão, em vez de algo que você monta sozinho. Onde eu construo arquivos de contexto, documentos de steering e um gate .status com markdown puro e Claude Code, o Kiro embala as mesmas ideias num painel gráfico, em arquivos nomeados numa pasta .kiro/ do workspace e numa UI que te conduz passo a passo por requisitos, design e tarefas antes de qualquer código ser escrito.

A ideia central de SDD é a mesma que uso todo dia: a spec é a fonte da verdade e o código é o resultado. O que muda é a superfície. O Kiro é IDE primeiro, não agente mais toolkit. Você instala, abre um projeto, clica no painel Specs e o workflow começa. O trabalho estrutural que me leva uma hora para montar num projeto novo já está lá.

O fluxo de specs em três arquivos

Toda feature no Kiro começa com um prompt. A partir dele, o Kiro gera três documentos markdown em sequência, com um gate de aprovação humana entre cada um. O workflow tem duas variantes: Requirements-First (comportamento primeiro, depois design, depois tarefas) e Design-First (arquitetura técnica primeiro, depois requisitos, depois tarefas). Requirements-First é o padrão para a maior parte do trabalho guiado por produto. Design-First serve para sistemas restritos, em que a arquitetura é a restrição de partida. Bugs ganham o próprio tipo de spec: uma bugfix spec troca requirements.md por bugfix.md, que guarda a análise do bug em vez de user stories. E, para features bem entendidas, o Quick Spec gera os três arquivos sem os gates de aprovação.

O workflow Requirements-First do Kiro

Entrada

Um prompt descrevendo a feature ou o comportamento que você quer construir

↓

1. 01requirements.md

   O Kiro gera requisitos no formato EARS: condições WHEN e comportamentos THE SYSTEM SHALL. Antes de ir para o design, você pode pedir ao Kiro que analise os requisitos em busca de contradições, ambiguidades e lacunas. Gate humano antes de seguir.

   ↓
2. 02design.md

   Arquitetura, fluxo de dados, modelos de dados, tratamento de erros e estratégia de testes. Cada requisito do passo um vira uma decisão de design. Gate humano antes de gerar as tarefas.

   ↓
3. 03tasks.md

   Uma lista sequenciada de tarefas de implementação, cada uma ligada a números de requisitos específicos. A IDE tem controles para rodar as tarefas uma a uma e revisar as mudanças de cada tarefa.

   ↓
4. 04Implementação

   Agentes em paralelo executam as tarefas do tasks.md. Na IDE, testes baseados em propriedades opcionais (asserções de corretude no estilo fuzz) pegam problemas que passam nos testes unitários mas quebram com entradas de edge case.

↓

Saída

Código funcionando, com uma cadeia rastreável do prompt original até requisitos, design e tarefas aprovados

A estrutura de workspace que o Kiro cria em torno desse workflow:

Layout do workspace do Kiro

• .kiro/
  • steering/memory bank
    • product.md// propósito do produto, usuários-alvo, objetivos de negócio
    • tech.md// frameworks, bibliotecas, restrições, stack preferida
    • structure.md// organização de arquivos, convenções de nomes, arquitetura
  • hooks/automação
    • lint-on-save.json// exemplo: rodar o linter depois de cada arquivo que o agente salva
  • specs/trabalho de feature
    • user-auth/
      • requirements.md// comportamentos em EARS e critérios de aceite
      • design.md// arquitetura, modelos de dados, contratos de API
      • tasks.md// tarefas em sequência, rastreáveis até os requisitos

A pasta steering é o equivalente, no Kiro, ao que chamo de camada steering/ no meu setup com Claude Code: contexto estável de produto que o agente carrega em toda sessão, para você nunca ter que explicar de novo as mesmas decisões. A pasta hooks guarda os gatilhos de automação. A pasta specs guarda o trabalho de feature em andamento.

Os requisitos usam a notação EARS

O Kiro escreve requisitos em EARS, o Easy Approach to Requirements Syntax. O padrão é simples:

WHEN a user submits a form with invalid data
THE SYSTEM SHALL display validation errors next to the relevant fields

Isso não deixa espaço para o agente interpretar. “Erros de validação” vira um resultado específico e testável, não uma instrução vaga. O Kiro também pode rodar uma etapa de análise antes do design, checando a lista completa de requisitos em busca de inconsistências lógicas, ambiguidades e lacunas. Pegar uma contradição nos requisitos custa segundos. Pegar depois que o design já foi gerado custa um redesign.

A explicação completa do EARS e de por que ele importa está no artigo base sobre spec-driven development. A versão curta: é um formato de 30 anos, da engenharia de requisitos, feito exatamente para a ambiguidade que destrói código gerado por IA. O Kiro adotou ele como formato padrão, e acertou.

Hooks transformam disciplina em automação

Os hooks são um dos diferenciais mais práticos do Kiro. Um hook é um gatilho orientado a eventos que roda um prompt de agente ou um comando de shell quando algo específico acontece na IDE. Você define os hooks como arquivos JSON em .kiro/hooks/.

A lista completa de gatilhos:

• PostFileSave, PostFileCreate, PostFileDelete (o agente mexeu num arquivo)
• UserPromptSubmit e Stop (eventos da conversa)
• PreToolUse e PostToolUse (ciclo de vida das ferramentas do agente)
• PreTaskExec e PostTaskExec (antes ou depois de uma tarefa da spec rodar)
• SessionStart e SessionEnd (só na CLI, adicionados em setembro de 2026)

Alguns gatilhos podem bloquear o agente (PreToolUse, UserPromptSubmit, PreTaskExec) retornando exit code 2. Outros rodam depois do fato e acrescentam contexto. Um hook PostFileSave que roda o lint em cada arquivo TypeScript que o agente salva são três linhas de JSON. Um hook PostTaskExec que atualiza a documentação depois de cada tarefa concluída é um prompt curto. Aquilo que você teria que lembrar de fazer na mão vira estrutura.

No meu setup com Claude Code, dependo de hábito e de um subagent revisor para pegar o que eu possa esquecer. No Kiro, os hooks colocam essas checagens no projeto, não na memória de quem desenvolve. Para times em que nem todo mundo tem a mesma disciplina, a diferença é grande.

Steering é o memory bank que sobrevive à sessão

O Kiro chama o seu sistema de contexto persistente de “steering”. Os arquivos de steering ficam em .kiro/steering/ e são carregados em toda interação com o agente por padrão. Os três arquivos de base que o Kiro gera automaticamente são product.md, tech.md e structure.md. Você pode adicionar quantos arquivos quiser.

Os arquivos de steering suportam quatro modos de inclusão, mais granular do que qualquer coisa que eu montei na mão:

• Always: carregado em toda interação, para os padrões centrais
• fileMatch: carregado só quando você trabalha com arquivos que batem com um padrão definido
• manual: carregado sob demanda, referenciando o arquivo no chat com um prefixo de hash
• auto: carregado quando o pedido bate semanticamente com a descrição do arquivo

Os modos condicionais fazem com que um security-standards.md só carregue quando você mexe em código de autenticação, deixando o contexto limpo nas sessões que não têm nada a ver com isso. Arquivos de steering globais (em ~/.kiro/steering/) valem para todos os workspaces, o que permite aos times distribuir convenções compartilhadas para as máquinas de todo mundo automaticamente.

Isso é paralelo direto à abordagem que descrevo em spec-driven development com Claude Code, em que a pasta steering/ tem quatro arquivos (produto, stack técnica, convenções, princípios) que dão ao agente o contexto de produto de que ele precisa antes mesmo de você começar uma sessão. O Kiro formaliza o mesmo padrão com uma UI e um carregamento mais flexível.

Como o Kiro se compara às alternativas

Hoje existem três abordagens distintas de spec-driven development em AI coding: o Kiro, o GitHub Spec Kit e setups de agente mais toolkit, como Claude Code com pi-sdd-kit. Um não substitui o outro. Eles atendem workflows diferentes e preferências diferentes de controle.

Kiro vs GitHub Spec Kit vs Claude Code com pi-sdd-kit

Os três ficam em pontos diferentes da escala entre integração e controle. Mais integração é começo mais rápido e menos setup sob medida. Mais controle é mais configuração, mas o workflow se ajusta exatamente às suas restrições e ao seu editor.

Dimensão	Kiro	GitHub Spec Kit	Claude Code + pi-sdd-kit
Formato de entrega	IDE (baseada no VS Code), CLI, interface web	CLI mais skills em 40+ agentes	Agente de terminal mais kit npm, qualquer editor
Pipeline de specs	requirements.md, design.md, tasks.md com gates de aprovação na UI	spec, plan, tasks, depois implement e converge	PRD, SPEC, TASKS, EXEC, REVIEW via gate de token no .status
Sistema de memória	Arquivos de steering em .kiro/steering/, quatro modos de inclusão	constitution.md (arquivo de regras de alto nível)	steering/ com arquivos de produto, tech, convenções e princípios
Gate de aprovação	Passo visual na UI, no painel da IDE, entre cada fase	Nenhum: --require-spec só confere se o arquivo existe	Token explícito no .status: arquivo existir não é aprovação
Automação	Hooks: gatilhos por evento de arquivo, ferramenta e tarefa	Workflows em YAML e hooks de extensão	Subagent revisor, hábito e disciplina de workflow
Checagens de corretude	Testes baseados em propriedades opcionais (estilo fuzz), só na IDE	Converge checa o código contra os artefatos	Subagent revisor checa contra os critérios da spec
Exigência de editor	A IDE Kiro substitui o seu editor; a CLI roda em qualquer lugar	Qualquer editor, com qualquer agente suportado	Qualquer editor, o Claude Code roda no terminal
Preço	Plano gratuito (50 créditos), pagos a partir de US$ 20/mês	Open source, gratuito	pi-sdd-kit é gratuito, exige assinatura do Claude Code

A comparação mais funda entre o GitHub Spec Kit e a abordagem do pi-sdd-kit está no artigo sobre o workflow com Claude Code, incluindo por que uso um gate de token no .status em vez de um passo visual na UI: a checagem mecânica tira a ambiguidade que uma pessoa lendo um arquivo pronto ainda pode deixar passar. Para a decisão entre os dois, veja Kiro vs Claude Code.

A crítica honesta: três pontos de atenção

Birgitta Boeckeler, Distinguished Engineer na Thoughtworks, publicou em outubro de 2025 uma avaliação prática do Kiro, do GitHub Spec Kit e do Tessl. As observações dela são a crítica independente mais confiável do Kiro nos primeiros tempos e, embora o produto tenha evoluído desde então, as perguntas que ela levantou continuam valendo.

Um workflow só para todo tamanho de problema. Boeckeler testou o Kiro num bug fix pequeno e recebeu quatro user stories com dezesseis critérios de aceite. O documento de requisitos transformou uma mudança simples em algo que ela descreveu como “usar uma marreta para quebrar uma noz”. Desde então o Kiro ganhou o Quick Spec, que gera os três arquivos sem os gates de aprovação para features bem entendidas, um tipo de spec bugfix dedicado, e um caminho Design-First para trabalho com restrição técnica. Mas a pergunta continua de pé: um workflow de três arquivos com gates humanos agrega mais valor do que overhead numa mudança de duas horas? Nem sempre.

Revisar markdown em vez de revisar código. O workflow spec-driven produz documentos para revisar antes de o código existir. Na teoria, pegar erros nos requisitos é mais barato do que pegar na implementação. Na prática, Boeckeler achou a revisão tediosa e disse que preferia revisar código a revisar markdown verboso. É um custo de atrito real. Se você não der atenção de verdade à revisão, vai passar correndo por ela, e revisão feita às pressas anula o sentido do gate. Não é uma falha exclusiva do Kiro, mas o Kiro gera três documentos separados para aprovar antes de você ver uma linha de código.

Falsa sensação de controle. Mesmo com specs estruturadas, Boeckeler viu os agentes pularem instruções com frequência ou aplicarem outras além da conta. Context windows maiores aumentam o risco de o agente achar um padrão e seguir ao pé da letra, ou ignorar uma restrição que nunca veio à tona. Uma spec cria as condições para um bom resultado. Não garante. A spec é a memória. O agente ainda interpreta. Isso vale igualmente para o Kiro, o GitHub Spec Kit e o setup que uso com Claude Code.

Quando o Kiro é a escolha certa

O Kiro faz mais sentido quando você quer spec-driven development sem ter que montar tudo sozinho. Instale a IDE, abra um projeto, escreva um prompt no painel Specs e o workflow começa. Não há sistema de contexto para configurar, convenção de gate para definir nem prompt de subagent para escrever. O custo é trocar de editor e aceitar o workflow do jeito que o Kiro desenhou.

Mais especificamente: o Kiro encaixa bem em times em que nem todo dev tem paciência para escrever arquivos de steering à mão e gerenciar convenções de gate manualmente. O passo de aprovação visual na IDE é mais difícil de pular do que um arquivo que você pode simplesmente não atualizar. O sistema de hooks elimina categorias inteiras de erro do tipo “esqueci de rodar o linter”. Os testes baseados em propriedades pegam problemas de corretude que os testes unitários deixam passar, afirmando regras sobre muitas entradas geradas, não só sobre os casos que você lembrou de escrever.

O Kiro encaixa pior se você precisa de controle preciso sobre a lógica do gate, trabalha com vários modelos e quer trocar entre eles à vontade, tem requisitos de corretude complexos que pedem etapas de verificação sob medida, ou já tem um setup com Claude Code que funciona. Trocar de IDE tem custo real: memória muscular, extensões, configuração do editor, os terminais e ferramentas que você organizou em volta do seu ambiente atual.

A comparação com vibe coding também vale aqui. O Kiro fica entre o vibe coding e um pipeline de SDD totalmente customizado. É mais estruturado do que mandar prompt direto e menos configurável do que construir o seu próprio workflow. Isso não é crítica. A maioria dos times ganha com mais estrutura e menos configuração. Depende do que você está otimizando.

FAQ

O que é o Kiro?+

O Kiro é uma IDE agêntica construída e operada pela AWS que faz do spec-driven development o workflow padrão de código. Você dá um prompt descrevendo uma feature e ele gera requirements.md, design.md e tasks.md em sequência, com gates de aprovação humana entre cada um. Depois, agentes em paralelo implementam o código a partir desses arquivos.

Ele está disponível como IDE para download (construída sobre o Code OSS, a base open source do VS Code), como CLI headless e como interface web. Você não precisa de conta na AWS. Dá para entrar com GitHub, Google, AWS Builder ID ou AWS IAM Identity Center.

O Kiro é gratuito?+

Sim, há um plano gratuito permanente com 50 créditos por mês. Ele inclui acesso ao Claude Sonnet 4.5 e a modelos open-weight como DeepSeek 3.2, Qwen3 Coder Next e MiniMax M2.1. Há limites de uso.

Os planos pagos começam em US$ 20 por mês por 1.000 créditos (Pro), depois US$ 40 (Pro+, 2.000 créditos), US$ 100 (Pro Max, 5.000 créditos) e US$ 200 (Power, 10.000 créditos). Créditos extras custam US$ 0,04 cada nos planos individuais. Os planos de time acrescentam cobrança consolidada, SSO via AWS IAM Identity Center, analytics de uso e controles de segurança enterprise.

Quem faz o Kiro?+

O Kiro é construído e operado pela AWS (Amazon Web Services). Roda na infraestrutura da AWS e herda os padrões de segurança, confiabilidade e privacidade da AWS. Oferece autenticação por IAM e SSO, recursos de governança enterprise e suporte a GovCloud (US) para ambientes regulados.

Os modelos de IA são os Claude da Anthropic (variantes Sonnet, Haiku e Opus, até o Opus 5.5), o GPT-5.6 da OpenAI (Sol, Terra e Luna) e modelos open-weight como DeepSeek, Qwen, MiniMax e GLM. Um modo Auto escolhe o melhor modelo para cada tarefa com base em complexidade, latência e custo.

O Kiro usa spec-driven development?+

Sim. SDD é o workflow central do Kiro, não um complemento opcional. Ele gera requirements.md, design.md e tasks.md a partir de um prompt, com um gate de aprovação humana entre cada fase. Os requisitos usam a notação EARS (condição WHEN, comportamento THE SYSTEM SHALL), o que torna cada requisito diretamente testável.

O Kiro também adiciona uma etapa de análise de requisitos antes do design (buscando contradições e lacunas) e testes baseados em propriedades depois da implementação, que afirmam regras de corretude sobre uma faixa de entradas geradas, em vez de um conjunto fixo de exemplos.

Kiro vs Cursor: qual a diferença?+

O Cursor é um fork do VS Code focado em código assistido por IA: sugestões inline, edições em vários arquivos e um agente conversacional. Ele não tem um workflow spec-driven nativo. Dá para aplicar práticas de SDD no Cursor adicionando o GitHub Spec Kit ou montando a sua própria estrutura, mas o Cursor em si é um editor de IA de uso geral.

O Kiro é construído especificamente em torno de SDD como workflow principal. O pipeline de specs (requisitos, design, tarefas) é a porta de entrada de toda feature, não um modo opcional. Se spec-driven development é central no jeito que você quer trabalhar, essa diferença pesa.

Kiro vs Claude Code: qual escolher?+

São coisas de natureza diferente, não concorrentes diretos. O Kiro é uma IDE com SDD embutido na interface. O Claude Code é um agente de terminal que você roda dentro do editor que já usa. Os dois suportam workflows spec-driven, mas o pipeline do Kiro está embutido na UI; no Claude Code você mesmo monta ou importa a estrutura (via pi-sdd-kit, GitHub Spec Kit ou markdown puro).

Se você quer um workflow de SDD pronto, com gates visuais, automação por hooks e o mínimo de setup, o Kiro é o começo mais rápido. Se quer controle máximo sobre o pipeline, a lógica do gate de aprovação e os modelos que usa, o Claude Code com um kit estruturado dá mais flexibilidade, ao custo de mais configuração.

Onde isso se encaixa no quadro maior

O Kiro é uma tentativa honesta de tornar o spec-driven development o caminho de menor resistência para devs que não montariam o workflow sozinhos. O pipeline de três arquivos está certo. O sistema de hooks resolve um atrito real. Os arquivos de steering atacam o problema de memória que sabota todo projeto assistido por agente que dura mais de uma sessão.

As críticas também são reais. Um workflow opinativo não serve para todo tamanho de problema. Revisar markdown sob pressão de prazo produz a mesma qualidade de revisão que revisar código sob pressão de prazo: insuficiente. Uma spec ajuda a disciplina, não substitui a disciplina.

A ferramenta vem depois do método. Spec-driven development funciona porque escrever requisitos, design e tarefas antes do código força uma clareza que prompt nenhum alcança. O Kiro deixa essa força mais fácil de alcançar. Seja com Kiro, GitHub Spec Kit ou Claude Code com um kit e alguma disciplina, o que importa é a spec. A ferramenta é só a superfície.

Se você já roda SDD com Claude Code e está funcionando, não há motivo forte para trocar. Se está começando do zero e quer o workflow pronto desde a primeira sessão, o Kiro é o caminho mais direto.