DevOps

Kiro: Dicas Avançadas para Desenvolvimento Agêntico na AWS (Guia 2026)

Equipe RFX Tecnologia 07 Jul 2026 13 min de leitura
Atualizado em Julho 2026

O Kiro é a IDE agêntica da AWS, construída sobre o Code OSS e centrada em spec-driven development: em vez de gerar código solto a partir de prompts, ele estrutura o trabalho em requisitos, design e tarefas antes de escrever uma linha, e oferece steering files, agent hooks e suporte a MCP para reduzir alucinação e manter contexto em bases grandes. Este guia assume que você já saiu do básico e quer extrair produtividade real da ferramenta em um time que entrega na AWS.

A diferença entre um time que adota Kiro e ganha velocidade e um que vira refém de retrabalho não está na ferramenta, está na disciplina de configuração. Spec mal escrito gera código que parece pronto e quebra no primeiro edge case. Steering vazio devolve um agente que reinventa convenções a cada sessão. Hooks ausentes deixam tarefas repetitivas no colo do dev. As dicas abaixo atacam exatamente esses pontos.

Cada seção traz o recurso, o porquê e o ganho concreto. Onde a documentação oficial confirma um detalhe, citamos com precisão; onde o comportamento depende do seu contexto, descrevemos de forma geral em vez de inventar.

1. Spec-driven bem feito: o spec é o contrato, não o rascunho

O coração do Kiro são os specs, gerados em .kiro/specs como três artefatos: requirements.md, design.md e tasks.md (para correção de bug, o requisito vira bugfix.md, capturando comportamento atual, esperado e o que não deve mudar). O erro de quem está saindo do básico é tratar o spec como um rascunho descartável. Trate-o como contrato.

  • requirements.md com critérios verificáveis: escreva user stories com critérios de aceitação que um humano consiga marcar como atendido ou não. Um critério como "deve ser rápido" não é verificável; "p95 de latência abaixo de 300 ms sob 100 RPS" é. Quanto mais mensurável o critério, menos o agente preenche lacunas com suposição.
  • design.md antes de codar: o design documenta arquitetura, componentes, diagramas de sequência, fluxo de dados, tratamento de erro e estratégia de teste. É aqui que você cravas decisões que o agente respeitaria errado se deixasse para a implementação.
  • tasks.md granular: tarefas pequenas e independentes são mais fáceis de revisar e habilitam execução paralela. O Kiro analisa a lista de tarefas, identifica dependências e roda as independentes em ondas concorrentes. Tarefa monolítica mata esse paralelismo.

O Kiro escreve os critérios de aceitação em notação EARS (no formato "WHEN [condição] THE SYSTEM SHALL [comportamento]"), que força cada critério a ser testável. Veja um trecho de requirements.md bem feito:

## Requisito: captura de lead no formulário

**User story:** Como visitante, quero enviar meu contato no formulário,
para que o time comercial me responda.

### Critérios de aceitação (EARS)
1. WHEN o visitante envia o formulário com e-mail válido e consentimento marcado,
   THE SYSTEM SHALL persistir o lead no DynamoDB e responder HTTP 201.
2. WHEN o e-mail é inválido ou o consentimento não foi dado,
   THE SYSTEM SHALL rejeitar com HTTP 422 e não gravar nada.
3. IF o mesmo e-mail for reenviado em menos de 24h,
   THEN THE SYSTEM SHALL tratar como idempotente e não duplicar o registro.

O design vira então um tasks.md granular, com tarefas pequenas, rastreáveis por checkbox e amarradas aos requisitos que cada uma atende:

# Plano de implementação

- [ ] 1. Modelar a tabela DynamoDB do lead (PK, SK, TTL de 24h)
  - [ ] 1.1 Definir access patterns e GSI no design
  - [ ] 1.2 Criar o recurso no template SAM
  - _Requisitos: 1, 3_

- [ ] 2. Implementar o handler de captura
  - [ ] 2.1 Validar e-mail e consentimento (retorno 422)
  - [ ] 2.2 Gravação idempotente por e-mail + janela de 24h
  - _Requisitos: 1, 2, 3_

- [ ] 3. Cobrir o handler com testes
  - [ ] 3.1 Casos de sucesso (201) e validação (422)
  - [ ] 3.2 Caso de reenvio idempotente
  - _Requisitos: 1, 2, 3_

Tarefas nesse nível de recorte são o que habilita o Kiro a identificar dependências e rodar as independentes em ondas concorrentes.

"Quando confiar no spec e quando iterar: confie quando os critérios de aceitação são verificáveis e o design fecha. Volte a iterar assim que o agente começar a perguntar o óbvio, isso é sinal de requisito ambíguo, não de modelo fraco."

Ganho: menos rodadas de correção por feature, código com decisões documentadas e onboarding mais rápido, porque o spec explica o porquê para quem chegar depois.

2. Spec para construir, vibe para descobrir

O Kiro distingue sessões spec de sessões vibe. A sessão spec parte de uma especificação formal e é indicada para features complexas, correções onde regressões custam caro e trabalho que precisa de documentação para o time. A sessão vibe é conversacional, boa para exploração e prototipagem.

A regra avançada é simples: use vibe para descobrir o formato da solução e spec para construir o que vai para produção. Prototipar uma integração nova em vibe, entender o contrato da API, e só então escrever o spec evita dois extremos: o spec prematuro que engessa a exploração e o vibe eterno que entrega código sem rastro de decisão.

O Kiro também faz detecção de intenção: pergunta gera explicação, instrução direta gera mudança de código, execução de comando ou manipulação de arquivo. Vale calibrar o fraseado conforme o que você quer naquele turno.

Ganho: você para de pagar o custo de cerimônia (spec) em tarefa exploratória e para de pagar o custo de improviso (vibe) em feature crítica.

3. Steering files: crave convenção e mate a alucinação

Steering files são arquivos Markdown em .kiro/steering (escopo de workspace) ou ~/.kiro/steering (escopo global, com o workspace tendo prioridade no conflito). O Kiro gera três base, incluídos em toda interação:

  • product.md: propósito do produto, usuários-alvo, features principais e objetivos de negócio.
  • tech.md: frameworks, bibliotecas, ferramentas e restrições técnicas (por exemplo, "Node 22, arm64, sem dependência que não tenha suporte a Lambda").
  • structure.md: organização de arquivos, convenções de nomenclatura e decisões arquiteturais.

Veja como fica um .kiro/steering/tech.md com front-matter de inclusão sempre ativa, cravando o stack do projeto para o agente não adivinhar versão nem dependência:

---
inclusion: always
---

# Stack e restrições técnicas

- Runtime: Node 22 (arm64), TypeScript estrito.
- Backend: AWS Lambda (container) + API Gateway + DynamoDB, via AWS SAM.
- Banco: DynamoDB single-table; modele por access pattern, sem scan em rota quente.
- Nunca usar dependência sem suporte a Lambda arm64.
- IAM por privilégio mínimo: sem wildcard em policy, escopo por ARN.
- Logs nunca registram PII (LGPD).

O salto avançado está nos steering customizados com modo de inclusão por arquivo, controlados por front-matter YAML. Este .kiro/steering/typescript.md só entra no contexto quando o arquivo aberto casa o padrão:

---
inclusion: fileMatch
fileMatchPattern: ["**/*.ts", "**/*.tsx"]
---

# Convenções de TypeScript do time
- Tudo com tipo explícito no boundary do módulo.
- Sem `any`; use `unknown` e estreite.
- Erro de domínio é classe, nunca string solta.

Os modos disponíveis são: always (carrega em toda interação, default), fileMatch (carrega só quando o arquivo aberto casa o padrão), manual (sob demanda via #nome-do-arquivo no chat) e auto (carrega quando o pedido casa a descrição declarada). Isso evita inflar o contexto com regra de frontend numa tarefa de backend.

Boas práticas oficiais que valem disciplina de time: um domínio por arquivo (API, testes, deploy), nome descritivo como api-rest-conventions.md, explicar o porquê e não só o quê, dar exemplos com antes e depois, nunca guardar segredo (chave de API) e tratar mudança de steering como mudança de código, sujeita a review.

Ganho: o agente para de reinventar padrão a cada sessão e a alucinação cai, porque ele opera dentro das suas convenções em vez de adivinhar.

4. Agent hooks: automatize o repetitivo no evento certo

Agent hooks são automações armazenadas como JSON em .kiro/hooks (workspace) ou ~/.kiro/hooks (usuário). Cada hook observa um evento do IDE e dispara uma ação, que pode ser um prompt de agente ou um comando de shell. Os gatilhos confirmados incluem:

  • PostFileSave: depois que um arquivo é salvo. Caso clássico: gerar ou atualizar testes do módulo recém-salvo.
  • PostFileCreate: após criação de arquivo. Útil para aplicar boilerplate ou cabeçalho de licença padronizado.
  • PostFileDelete: após remoção, por exemplo para limpar referências órfãs.
  • PreToolUse e PostToolUse: antes ou depois do uso de uma ferramenta, bons para checagem de política antes de uma ação ou pós-processamento.
  • UserPromptSubmit: no envio do prompt, para injetar contexto ou validação.

A documentação cita aplicações comuns: manter qualidade de código consistente, prevenir vulnerabilidades, reduzir esforço manual e padronizar processos do time. Na prática, três hooks resolvem a maior parte da dor: gerar testes ao salvar, atualizar a documentação quando o código muda e rodar uma varredura de segurança em pontos sensíveis.

O exemplo a seguir é um .kiro/hooks/atualizar-testes.json que, ao salvar qualquer arquivo *.ts, dispara um prompt de agente para criar ou atualizar os testes correspondentes:

{
  "version": "v1",
  "hooks": [
    {
      "name": "atualizar-testes-ts",
      "trigger": "PostFileSave",
      "matcher": "\\.ts$",
      "action": {
        "type": "agent",
        "prompt": "O arquivo TypeScript salvo mudou. Crie ou atualize o arquivo de teste correspondente (mesmo nome, sufixo .test.ts), cobrindo caminhos felizes e de erro. Nao altere o codigo de producao."
      },
      "timeout": 120,
      "enabled": true
    }
  ]
}

E este .kiro/hooks/doc-endpoint.json mantém a documentação de API em dia: ao criar um arquivo de rota, ele pede ao agente para atualizar a doc do endpoint:

{
  "version": "v1",
  "hooks": [
    {
      "name": "doc-novo-endpoint",
      "trigger": "PostFileCreate",
      "matcher": "src/routes/.*\\.ts$",
      "action": {
        "type": "agent",
        "prompt": "Um novo arquivo de rota foi criado. Atualize docs/api.md com o metodo, o path, os parametros, o corpo da requisicao e os codigos de resposta deste endpoint, seguindo o formato dos endpoints ja documentados."
      },
      "timeout": 90,
      "enabled": true
    }
  ]
}

Os campos centrais são trigger (o evento do IDE), matcher (regex que filtra path de arquivo ou nome de ferramenta) e action, que pode ser {"type": "agent", "prompt": "..."} para um prompt de agente ou {"type": "command", "command": "..."} para um comando de shell direto, com timeout e enabled como ajustes finos.

Ganho: tarefas repetitivas saem do colo do dev e viram garantia mecânica. Teste desatualizado e doc defasada deixam de depender de lembrança.

5. MCP: pluge o contexto e as ferramentas do seu stack

Via Model Context Protocol, o Kiro conversa com servidores externos que expõem ferramentas, prompts e recursos, dando acesso a bases de conhecimento e APIs específicas do seu domínio. A configuração fica em .kiro/settings/mcp.json (workspace) ou ~/.kiro/settings/mcp.json (usuário):

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": ["search_documentation"]
    }
  }
}

Os campos centrais são command (executável, com uvx sendo comum para servidores em Python), args, env (credenciais via sintaxe ${VARIAVEL}, nunca chave literal no arquivo), disabled (liga/desliga) e autoApprove (ferramentas pré-aprovadas, que rodam sem pedir confirmação a cada chamada). Use autoApprove só em ferramentas idempotentes e de leitura, como busca em documentação.

O ganho prático para quem vive na AWS é direto: um servidor MCP de documentação da AWS deixa o agente responder com base na doc oficial atual em vez de memória do modelo, reduzindo resposta defasada sobre serviço e parâmetro. Servidores para banco de dados ou APIs internas dão ao Kiro contexto real do seu sistema.

Ganho: o agente opera com a verdade do seu stack e da AWS, não com aproximação, o que reduz erro de configuração e correção depois.

6. Gestão de contexto em codebase grande

Em base grande, o problema deixa de ser capacidade do modelo e passa a ser higiene de contexto. A combinação de steering por fileMatch, specs bem recortados e MCP para puxar só o que importa é o que mantém o agente focado. Algumas práticas avançadas:

  • Recorte o spec por capability, não por épico inteiro: um spec gigante dilui o foco e atrapalha a execução paralela. Prefira specs menores e encadeados.
  • Use steering manual para conhecimento pesado: documento de arquitetura extenso entra como inclusion: manual e é puxado com # só quando a tarefa precisa, em vez de pesar em toda interação.
  • Deixe o MCP buscar em vez de colar: em vez de despejar doc no chat, conecte a fonte como servidor MCP e deixe o agente consultar sob demanda.

Ganho: respostas mais precisas e estáveis em monorepos e sistemas legados, onde excesso de contexto irrelevante degrada a qualidade.

7. Autopilot ou supervisionado: escolha pelo raio de explosão

O Kiro tem dois modos de execução, alternáveis pelo switch de autopilot na interface de chat:

  • Autopilot (padrão): o agente trabalha de ponta a ponta, cria arquivos, altera código em vários lugares, roda comandos e toma decisões de arquitetura sem pedir aprovação a cada passo. Você mantém controle por poder ver todas as mudanças, reverter tudo ou interromper a execução a qualquer momento.
  • Supervisionado: o Kiro pausa para sua aprovação após cada turno que contém edições. As mudanças são apresentadas em hunks (grupos lógicos de linhas relacionadas), com controle fino para aceitar, rejeitar ou discutir cada parte, no nível do hunk, por arquivo ou tudo de uma vez.

A regra prática é escolher pelo raio de explosão da tarefa. Refatoração ampla em código bem testado ou scaffolding novo vão bem em autopilot. Mudança em caminho crítico, migração de schema ou qualquer coisa difícil de reverter pede supervisionado, com revisão hunk a hunk. O histórico de sessão registra ações e permite restaurar, o que dá uma rede extra, mas rede não substitui revisão em mudança sensível.

Ganho: velocidade onde o erro é barato e controle onde o erro dói, sem tratar tudo com a mesma régua.

8. Versione o .kiro no git e padronize no time

Specs, steering e hooks são artefatos de engenharia, não preferência individual. Versione o diretório .kiro/ no git para que toda a configuração que molda o comportamento do agente viaje com o repositório. Isso transforma "como o time usa o Kiro" em algo revisável em pull request, com diff e histórico, em vez de conhecimento tribal na cabeça de quem configurou primeiro.

  • Steering em PR: a própria doc recomenda tratar atualização de steering como mudança de código, sujeita a review. Um steering mal escrito propaga viés para todo o time.
  • Specs como rastro de decisão: o spec versionado documenta por que a feature ficou daquele jeito, o que ajuda auditoria e onboarding.
  • Atenção a segredo: nunca commite chave em steering ou em mcp.json. Use variáveis de ambiente via ${VARIAVEL} e mantenha o segredo fora do repositório.

Ganho: consistência entre devs e máquinas. Quem clona o repo já recebe convenções, automações e contexto, sem reconfigurar do zero.

9. Combine Kiro com Bedrock e serviços AWS

O Kiro fica mais forte quando o desenvolvimento agêntico encontra o runtime agêntico da AWS. Para nós da RFX, o padrão que mais entrega é usar o Kiro para projetar e implementar workloads que rodam em serviços gerenciados da AWS e, quando o produto precisa de IA em produção, ancorar isso em Amazon Bedrock.

  • Do spec ao serverless: escreva o spec da função, deixe o Kiro gerar o handler e o template de infraestrutura, e feche o ciclo com um pipeline de CI/CD no GitHub Actions para deploy reproduzível.
  • MCP apontando para a AWS: o servidor MCP de documentação da AWS mantém o agente alinhado a serviço, limite e parâmetro corretos, reduzindo configuração errada.
  • Bedrock para a camada de IA do produto: o Kiro acelera a construção da aplicação; o Bedrock entrega o modelo em produção com governança e isolamento de conta.

Ganho: um fluxo único, do requisito ao deploy na AWS, com IA agêntica na construção e, quando faz sentido, na execução.

Checklist de adoção avançada

Antes de declarar que o time adotou o Kiro de verdade, confirme:

  • Specs com critérios verificáveis e tarefas granulares, não rascunhos vagos.
  • Steering versionado com product, tech e structure preenchidos e customizados por fileMatch onde faz sentido.
  • Hooks ativos para teste ao salvar, doc e segurança.
  • MCP configurado para a doc da AWS e fontes internas, com autoApprove só em leitura.
  • Política clara de autopilot vs supervisionado por raio de explosão.
  • .kiro/ no git e segredo sempre via variável de ambiente.

Próximos passos

O Kiro entrega produtividade real quando a configuração é tratada como engenharia: spec é contrato, steering é convenção versionada, hooks automatizam o repetitivo e MCP dá contexto verdadeiro do stack. O resto é disciplina de time, e é exatamente aí que uma consultoria experiente acelera a adoção.

Na RFX Tecnologia, ajudamos times a estruturar fluxos de DevOps e automação na AWS, do desenho do spec ao pipeline de deploy, com governança e segurança no padrão da plataforma. Se o seu time está avaliando ou já usa o Kiro e quer extrair mais valor, fale com nossos especialistas.

Vai estar em João Pessoa em julho? Aprofunde esses temas presencialmente na Jornada AWS João Pessoa 2026, nosso evento técnico com a comunidade AWS.

Kiro AWS DevOps IA Generativa
Fale Conosco
Quer DevOps agêntico na sua AWS?
Falar com um Especialista