AWS Kiro: O IDE Construído do Zero para SDD — E Por Que Isso Muda Tudo

Tem uma diferença fundamental entre um IDE com IA e um IDE para IA.

O Cursor, o Windsurf, o GitHub Copilot no VS Code — todos são IDEs com IA. Pegaram uma ferramenta existente e adicionaram capacidades de IA em cima: autocompletar, chat, refactor, geração de código. A IA é um add-on, uma camada sobre um IDE que foi projetado para humanos digitando código.

O Kiro é diferente. A AWS partiu de uma premissa: e se o IDE fosse projetado do zero para um mundo onde agentes de IA executam a maior parte do código? Qual seria a interface adequada não para escrever código, mas para especificar o que o sistema deve fazer e deixar o agente implementar?

A resposta é um IDE onde o ponto de partida não é um arquivo TypeScript em branco — é uma spec.

O Que É o Kiro

O Kiro é um IDE em public preview desenvolvido pela AWS, construído sobre o Code OSS (a base open source do VS Code), mas com uma filosofia de design completamente diferente.

Em vez de começar com "abra um arquivo e escreva código", o Kiro começa com "descreva o que você quer construir". A partir dessa descrição em linguagem natural, o Kiro:

1. Gera requirements detalhados com critérios de aceitação em notação EARS
2. Produz uma especificação técnica com decisões de design e arquitetura
3. Decompõe em tasks discretas e implementáveis
4. Tem agentes que executam as tasks, guiados pelos artefatos acima

Isso é exatamente o ciclo do SDD — e o Kiro é a primeira ferramenta que implementa esse ciclo como fluxo nativo do IDE, não como um processo externo.

A Notação EARS

Um detalhe que diferencia o Kiro de outros IDEs com IA: os requirements são escritos em EARS (Easy Approach to Requirements Syntax), uma notação semi-formal para especificações de software.

EARS define templates de frases para diferentes tipos de requisitos:

# Tipos de requisitos EARS

UBIQUITOUS (sempre verdadeiro):
"O sistema SHALL [ação]"
→ "O sistema SHALL validar o formato do email antes de criar um usuário"

EVENT-DRIVEN (disparado por evento):
"WHEN [condição] THE [sistema] SHALL [ação]"
→ "WHEN um usuário tenta fazer login com senha incorreta 3 vezes
   THE sistema SHALL bloquear a conta por 15 minutos"

UNWANTED BEHAVIOR (tratamento de erro):
"IF [condição indesejada] THEN THE [sistema] SHALL [resposta]"
→ "IF o serviço de email estiver indisponível
   THEN THE sistema SHALL enfileirar o email e tentar novamente em 5 minutos"

STATE-DRIVEN (baseado em estado):
"WHILE [estado] THE [sistema] SHALL [ação]"
→ "WHILE o usuário não estiver autenticado THE sistema SHALL redirecionar para /login"

Por que EARS importa? Porque transforma intenção ambígua em critério de aceitação verificável. "O sistema deve ser rápido" não é um requirement. "O sistema SHALL retornar a lista de posts em menos de 200ms para 95% das requisições" é.

Quando o Kiro gera requirements a partir da sua descrição, ele usa EARS para estruturar os critérios de aceitação. Isso significa que cada requirement já vem com a resposta para "como eu sei que isso está implementado corretamente?"

A Anatomia de um Projeto no Kiro

.kiro/specs/

O coração do projeto Kiro. Cada funcionalidade tem sua própria spec:

.kiro/
  specs/
    user-authentication/
      requirements.md    # o que o sistema deve fazer (EARS)
      design.md          # como vai ser implementado
      tasks.md           # decomposição em tasks executáveis
    post-scheduling/
      requirements.md
      design.md
      tasks.md

requirements.md — gerado pelo Kiro a partir da sua descrição, editável por você:

# Requirements: User Authentication

## User Stories

**US-001**: Como usuário, quero fazer login com email e senha para acessar
minha conta.

**US-002**: Como usuário, quero redefinir minha senha via email para recuperar
acesso caso esqueça.

## Functional Requirements

1. WHEN um usuário submete email e senha válidos THE sistema SHALL criar uma
   sessão autenticada e redirecionar para o dashboard.

2. WHEN um usuário submete credenciais inválidas THE sistema SHALL exibir
   mensagem de erro genérica (sem indicar se o email ou senha está incorreto).

3. IF um usuário tenta login com senha incorreta 5 vezes consecutivas THEN
   THE sistema SHALL bloquear o IP por 30 minutos e notificar o email
   cadastrado.

4. O sistema SHALL invalidar a sessão após 24 horas de inatividade.

5. O sistema SHALL suportar autenticação via Google OAuth como alternativa
   ao email/senha.

## Acceptance Criteria

- [ ] Login com credenciais válidas redireciona para dashboard em < 500ms
- [ ] Tentativas inválidas não revelam se o email existe na base
- [ ] Após 5 tentativas falhas, conta é bloqueada por 30 min
- [ ] Sessões expiram após 24h de inatividade
- [ ] OAuth Google funciona como alternativa

tasks.md — gerado a partir do design, com granularidade de implementação:

# Tasks: User Authentication

## Phase 1: Core Login

- [ ] **T001** — Criar tabela `users` com campos: id, email, password_hash,
      created_at, last_login_at, is_blocked, block_expires_at
- [ ] **T002** — Implementar endpoint POST /auth/login com validação de
      credenciais e criação de sessão JWT
- [ ] **T003** — Implementar middleware de rate limiting: máximo 5 tentativas
      por IP em janela de 10 minutos
- [ ] **T004** — Implementar lógica de bloqueio de conta após 5 tentativas

## Phase 2: Password Recovery

- [ ] **T005** — Implementar endpoint POST /auth/forgot-password com envio
      de email via SES
- [ ] **T006** — Implementar endpoint POST /auth/reset-password com validação
      de token e expiração
...

Agent Hooks: O Diferencial Mais Poderoso

Os Agent Hooks são o que transforma o Kiro de "IDE com specs" para "IDE onde agentes trabalham ao seu lado continuamente".

Um Agent Hook é uma automação event-driven: quando algo acontece no ambiente de desenvolvimento (você salva um arquivo, cria um componente, modifica uma interface), um agente é disparado para executar uma tarefa relacionada.

Exemplos práticos:

# .kiro/hooks/hooks.yaml

hooks:
  - name: "Generate tests on save"
    trigger:
      type: file_save
      pattern: "src/**/*.ts"
      exclude: "**/*.test.ts"
    agent:
      instruction: |
        Analise o arquivo salvo. Se contém funções públicas sem testes
        correspondentes, crie ou atualize o arquivo de teste colocado com
        o código (mesmo diretório, extensão .test.ts) cobrindo os casos
        principais incluindo edge cases e tratamento de erros.
      max_tokens: 4000

  - name: "Update API docs on interface change"
    trigger:
      type: file_save
      pattern: "src/types/**/*.ts"
    agent:
      instruction: |
        Verifique se as mudanças no arquivo de tipos impactam a documentação
        da API em docs/api/. Se sim, atualize automaticamente os arquivos
        de documentação afetados.

  - name: "Check spec compliance on task completion"
    trigger:
      type: task_completed
      spec: "*"
    agent:
      instruction: |
        Compare a implementação com os acceptance criteria da spec.
        Gere um relatório em .kiro/reports/{spec_name}-validation.md indicando
        quais critérios passam e quais ainda precisam de trabalho.

O ganho é enorme: coisas que você normalmente esquece de fazer (escrever testes, atualizar docs, validar contra a spec) acontecem automaticamente no momento certo.

Kiro vs. Cursor: Uma Comparação Honesta

O Cursor continua sendo o melhor IDE para quem quer IA como copiloto de código — autocomplete superior, chat contextual muito bom, edição inline fluida. Se você está feliz com o Cursor e seu fluxo é principalmente "escrevo código com ajuda da IA", o Cursor é provavelmente a escolha certa.

O Kiro é melhor quando:

Você está começando algo do zero: o fluxo specs → design → tasks é mais valioso no início de um projeto ou feature. Pegar uma codebase existente e tentar retroativamente aplicar specs a ela é mais trabalhoso.

Você trabalha em times: as specs do Kiro são artefatos compartilháveis que toda a equipe pode consultar. O CLAUDE.md do seu Cursor é um arquivo local, pessoal. As specs do .kiro/specs/ vivem no repositório e servem de referência para humanos e agentes igualmente.

Você quer Agent Hooks: a automação event-driven é única do Kiro hoje. Cursor não tem equivalente nativo.

SDD já é seu processo: se você já trabalha com specs antes de implementar, o Kiro vai parecer um IDE feito para você. Se você está tentando adotar SDD, o Kiro pode ser a ferramenta que torna a adoção mais natural — o processo está na interface, não é algo que você força externamente.

Por outro lado, o Kiro ainda está em public preview. A edição de código direto é menos fluida que o Cursor, o ecossistema de extensões é muito menor (herda do Code OSS, mas não é 100% compatível com extensões do VS Code), e o suporte a linguagens e frameworks menos populares ainda é inconsistente.

A minha avaliação: para projetos novos onde SDD é o processo e você tem um time alinhado, vale experimentar o Kiro. Para código legado ou workflow onde você já é produtivo no Cursor, a troca provavelmente não vale o custo de adaptação agora.

O Ciclo Completo: Do Problema ao Código

Para tornar isso concreto, veja como fica um ciclo completo no Kiro para uma feature real — "adicionar autenticação com Google OAuth ao blog".

Passo 1: Você descreve o problema

"Quero adicionar login com Google ao blog. O usuário clica em
'Entrar com Google', autentica via OAuth 2.0, e o sistema cria
uma conta local se for o primeiro acesso ou faz login se já existe."

Passo 2: Kiro gera os requirements

# Requirements: Google OAuth Authentication

1. WHEN um usuário clica em "Entrar com Google" THE sistema SHALL
   redirecionar para o fluxo de autorização Google OAuth 2.0.

2. WHEN o Google retorna um código de autorização válido THE sistema SHALL:
   a) Trocar o código por access token e profile do usuário
   b) Se email não existe na base: criar conta com nome, email e avatar do Google
   c) Se email já existe: fazer login na conta existente
   d) Criar sessão JWT e redirecionar para a página anterior ou /dashboard

3. IF o Google retornar erro de autorização THEN THE sistema SHALL
   redirecionar para /login com mensagem de erro amigável.

4. O sistema SHALL armazenar apenas: nome, email, avatar_url, google_id.
   NÃO SHALL armazenar o access token do Google.

5. WHEN um usuário com conta OAuth tenta fazer login por email/senha
   THE sistema SHALL exibir mensagem sugerindo login via Google.

## Acceptance Criteria
- [ ] Fluxo completo funciona em < 3 segundos
- [ ] Primeiro acesso cria conta automaticamente
- [ ] Acesso subsequente faz login sem criar conta duplicada
- [ ] Erro de cancelamento pelo usuário é tratado graciosamente
- [ ] Testes cobrindo todos os cenários do fluxo OAuth

Passo 3: Kiro gera o design técnico

O Kiro analisa o código existente — stack, bibliotecas já instaladas, padrões de auth já presentes — e propõe uma implementação que se encaixa no projeto:

# Design: Google OAuth

## Abordagem
Usar next-auth v5 (já presente no projeto) com o provider Google.
Tabela users já existe — adicionar coluna google_id nullable.

## Mudanças necessárias
1. Adicionar GOOGLE_CLIENT_ID e GOOGLE_CLIENT_SECRET ao .env
2. Configurar GoogleProvider no next-auth config
3. Adicionar migration: ALTER TABLE users ADD COLUMN google_id TEXT
4. Atualizar callback de signIn para merge de conta por email
5. Adicionar botão "Entrar com Google" na página de login

Passo 4: Tasks geradas automaticamente

- [ ] T001 — Adicionar variáveis GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET ao .env.example
- [ ] T002 — Configurar GoogleProvider em src/lib/auth.ts
- [ ] T003 — Criar migration SQL para adicionar google_id na tabela users
- [ ] T004 — Implementar lógica de merge de conta por email no callback
- [ ] T005 — Criar componente GoogleLoginButton em src/components/
- [ ] T006 — Atualizar página /login para incluir o botão
- [ ] T007 — Escrever testes para o fluxo OAuth (mock do provider)
- [ ] T008 — Verificar acceptance criteria contra implementação

Passo 5: Agentes executam as tasks

Você seleciona as tasks, o Kiro as delega para agentes, e cada uma é implementada seguindo os artefatos criados nos passos anteriores. Os agentes têm o contexto completo — o requirement original, o design escolhido, as convenções do projeto via steering files — e produzem código alinhado com tudo isso.

O que levaria um ciclo de planejamento em reunião + implementação manual se transforma em um fluxo guiado onde o plano e a execução vivem no mesmo lugar.

O Modelo por Baixo

O Kiro é construído sobre Amazon Bedrock e usa Claude Sonnet como modelo principal (com opção de escolher entre Claude 4.0 e 3.7). Isso significa que se você já usa Claude Code ou tem familiaridade com como o Claude raciocina, o comportamento dos agentes do Kiro vai ser familiar.

A escolha da Anthropic pela AWS não é acidental — é uma parceria estratégica. A Anthropic usa AWS como cloud principal, e o Kiro é o veículo pelo qual a AWS distribui Claude para o mercado de desenvolvedores. Para a Anthropic, é distribuição. Para a AWS, é diferenciação no mercado de ferramentas de IA para devs.

Como Começar

O Kiro está em public preview gratuito (com limites de uso).

# Download em kiro.dev
# Após instalar, inicie um novo projeto:
kiro new meu-projeto

# Ou abra um projeto existente e inicialize o Kiro:
kiro init

No primeiro uso, o Kiro vai pedir que você descreva o projeto. A partir daí, ele gera a estrutura inicial de specs e você começa a trabalhar a partir dela.

Para explorar sem compromisso: tente criar um projeto novo com uma feature pequena e bem definida. O ciclo specs → tasks → implementação fica mais claro em algo simples do que em um projeto grande com muitas variáveis.

Recursos

• Kiro — Site oficial e download
• Introducing Kiro — Blog oficial
• AWS re:Post — Kiro como Agentic IDE
• Spec-Driven Development com GitHub Spec Kit
• Posts relacionados: Steering Files: CLAUDE.md e AGENTS.md · SDD Cases Reais · Ferramentas SDD Agêntico