Kiro, a IA agêntica da AWS para desenvolvimento de software: o que é, como funciona e como adotar no time

O Kiro, a IA agêntica da AWS para desenvolvimento de software, é um agente que lê o repositório, planeja e escreve código, executa comandos e chama ferramentas externas, disponível como IDE, CLI e na web (kiro.dev). O que o diferencia de um assistente de autocompletar é o método: antes do código, ele transforma a solicitação em uma spec com requisitos, desenho e tarefas, e segue as convenções do time registradas em arquivos de steering dentro do repositório.

Verificado contra a documentação do Kiro e o aviso de fim de suporte do Amazon Q Developer na atualização de 15/10/2026. Superfícies, planos, preços e disponibilidade por região mudam entre versões: confira a página oficial de cada um antes de decidir.

Para um time de desenvolvimento, isso desloca a pergunta da revisão. Com um assistente, revisa-se a linha sugerida. Com um agente, é preciso decidir o que ele sabe do projeto, o que ele pode executar e quem aprova cada etapa. O Kiro responde a essas três perguntas com arquivos versionados: steering, specs, hooks e regras de permissão. Adotar o Kiro, na prática, é decidir o conteúdo desses arquivos e colocá-los sob revisão como qualquer código.

Este guia é o ponto de partida do conjunto de artigos da RFX sobre o Kiro. Cada seção responde uma pergunta em poucas frases e aponta o guia de aprofundamento.

O que é o Kiro?

O Kiro é o produto da AWS para desenvolvimento de software com agentes de IA. A documentação da AWS o indica como o caminho para quem usa os plugins de IDE do Amazon Q Developer, com sugestões inline, chat, geração de código, recursos agênticos e suporte a MCP. A RFX Tecnologia é parceira da AWS e conduz a adoção do Kiro em times; a fabricante do produto é a AWS.

Três ideias organizam o produto, e todas estão descritas na documentação oficial:

• Spec antes do código. A solicitação vira requisitos, desenho e plano de tarefas, revisados por uma pessoa antes da implementação.
• Contexto permanente no repositório. Produto, stack, estrutura e regras do time ficam em arquivos de steering que o agente carrega sem que alguém precise repetir a convenção a cada conversa.
• Automação e limites declarados. Hooks rodam verificações em pontos fixos do fluxo, e regras de permissão definem o que o agente executa sem perguntar, o que precisa de confirmação e o que é negado.

O que é uma spec no Kiro?

Segundo a documentação de specs, uma spec é um artefato estruturado que formaliza o desenvolvimento de uma funcionalidade ou correção em três arquivos dentro de .kiro/specs/: requirements.md (ou bugfix.md), design.md e tasks.md.

Há specs de funcionalidade, com as variantes Requirements-First e Design-First, specs de correção e o Quick Spec, que gera os três arquivos de uma vez, sem portões de aprovação, para trabalho bem conhecido. Na execução, o Kiro monta um grafo de dependências entre as tarefas e roda em ondas: as tarefas sem dependência rodam juntas, e cada onda começa quando a anterior termina.

A decisão de método está em escolher quando a spec compensa. Regra de negócio, integração com outro sistema, dado pessoal e caminho crítico pedem spec revisada. Ajuste de texto ou de estilo não pede. O checklist de revisão de cada arquivo está em Specs no Kiro: spec-driven development na prática.

O que é steering?

Steering é o conjunto de arquivos Markdown em .kiro/steering/ que dá ao agente o contexto permanente do projeto. A documentação de steering descreve três arquivos de base (product.md, tech.md e structure.md) e modos de inclusão que decidem quando cada arquivo entra no contexto.

Steering e spec trabalham em camadas diferentes. A spec diz o que construir em um incremento; o steering diz como este time constrói qualquer incremento. Um steering bem escrito encurta todas as specs seguintes, porque elas deixam de repetir o que vale para o projeto inteiro. Os modos de inclusão, a estrutura recomendada e os exemplos de arquivo estão em Steering no Kiro.

O que são hooks, MCP, Powers, skills e permissões?

São os mecanismos com que o time estende e limita o agente. Hooks automatizam por evento, MCP conecta ferramentas externas, Powers e skills empacotam conhecimento reutilizável e as permissões definem o que o agente pode executar. A tabela resume cada um com a página oficial.

Um ponto que entra no treinamento de qualquer time: a seção Autopilot versus supervised mode da documentação afirma que os dois modos dão ao agente as mesmas capacidades e que o modo supervisionado é um fluxo de revisão de código, não um controle de segurança. Na IDE e na CLI, o limite real do que o agente executa fica nas regras de permissão.

Onde o Kiro roda?

O Kiro roda como IDE de desktop, como CLI no terminal e no navegador, com o Kiro Web. Os três consomem os mesmos créditos, mas não têm o mesmo perímetro: cada superfície tem recursos próprios, listados nas tabelas de disponibilidade da documentação, e o Kiro Web roda num sandbox gerenciado na nuvem, onde as regras de permissão, o .kiroignore e os hooks não se aplicam.

A FAQ do Kiro lista ainda um aplicativo móvel e o Kiro Crew, espaço de trabalho open source que roda na máquina do usuário. Este guia trata das três superfícies que entram no fluxo do repositório; as demais estão nas categorias de IA agêntica no desenvolvimento.

Para quem usa outro editor: o guia de migração do Amazon Q Developer descreve o uso nas IDEs JetBrains pelo AI Assistant, via Agent Client Protocol, com a Kiro CLI instalada. O uso da CLI em pipeline, com permissão mínima e controle de créditos, está em Kiro CLI no pipeline.

O Kiro substitui o Amazon Q Developer?

Para os plugins de IDE, sim. O aviso oficial da AWS, publicado em 30/04/2026, informa que os plugins de IDE e as assinaturas pagas do Amazon Q Developer chegam ao fim do suporte em 30/04/2027, que novos cadastros deixam de ser aceitos a partir de 15/05/2026 e posiciona o Kiro como sucessor.

O mesmo aviso separa o que não muda: as experiências do Amazon Q no Console de Gerenciamento da AWS, no site de documentação, no app móvel do console e no Slack e no Microsoft Teams seguem disponíveis. As transformações de código (upgrade de Java e porte de .NET) feitas pelos plugins vão para o AWS Transform. O passo a passo da transição, por perfil de usuário, está em Amazon Q Developer para o Kiro: o que muda e como migrar.

Onde ficam os dados e como isso entra na LGPD?

Depende do plano e da superfície. No Free e nos planos individuais, a documentação de proteção de dados informa que o conteúdo fica armazenado em US East (N. Virginia). No Enterprise, segundo a página de regiões suportadas, os dados são armazenados e a inferência é feita na região do perfil do Kiro, que nas regiões comerciais é US East (N. Virginia) ou Europe (Frankfurt). São Paulo aparece na lista só como região possível do IAM Identity Center, onde ficam as identidades. E o Kiro Web, segundo a documentação dele, está disponível apenas em us-east-1.

Sobre treino de modelo, duas páginas oficiais precisam ser lidas juntas. A página Enterprise do Kiro declara que o conteúdo não é usado para treinar modelos de fundação nas assinaturas Pro, Pro+, Pro Max e Power. A documentação de proteção de dados lista "model training" entre os usos possíveis do conteúdo coletado para melhoria do serviço no Free e nos planos individuais, com opt-out na IDE em Settings, Telemetry and Content, e exclui o Enterprise desse uso. Antes de levar código de cliente ao agente, o método é reconciliar as duas declarações por escrito com a AWS e partir do Enterprise como configuração mínima, com o opt-out ligado em qualquer conta individual que participe do piloto.

O opt-out tem um limite que entra na conversa com o encarregado de dados. A mesma página informa que, no Free Tier, as entradas podem ser armazenadas por até 60 dias para detecção de abuso, salvo exigência legal, e que o opt-out não afeta essa retenção; para os assinantes individuais, menciona que podem valer requisitos de retenção específicos de cada modelo para o mesmo fim. Por isso o Free não entra no piloto com código de cliente, e o opt-out vale como redução de uso, não como garantia de que nada fica retido.

Como o processamento acontece fora do Brasil, o uso do Kiro entra na avaliação de LGPD como transferência internacional de dados. A decisão de método é dupla: escolher o plano e a configuração de uso de conteúdo descritos na documentação de proteção de dados e definir, no .kiroignore e no steering, o que nunca entra no contexto do agente. O artigo sobre LGPD na nuvem cobre a base legal e a transferência internacional.

Como adotar o Kiro no time?

Comece por um repositório real, registre a convenção do time no steering, defina as permissões antes de liberar o agente, conduza a primeira spec com revisão em pull request e só então automatize com hooks e com a CLI no pipeline. Cada passo produz um arquivo versionado, que o time revisa como código.

A ordem importa. Hooks e pipeline antes de steering e permissões automatizam um agente que ainda não conhece o projeto. Specs antes do steering repetem em cada documento as regras que valeriam para todos.

1. Escolher o repositório piloto. Um serviço com testes automatizados, dono claro e backlog ativo. Repositório sem teste não mostra se o código do agente está certo.
2. Escrever o steering de base. product.md, tech.md e structure.md, com os comandos que validam o código e as restrições que o time já aplica em revisão.
3. Definir o perímetro. .kiroignore para segredos e dados, regras de permissão com deny para operações destrutivas e ask para o que precisa de julgamento, e servidores MCP só de leitura no início. Esse perímetro vale para IDE e CLI. O Kiro Web pede decisão própria, habilitar ou não as Cloud Sessions, porque nele essas regras não se aplicam; o detalhe está em governança de IA no código e nas categorias de IA agêntica.
4. Conduzir a primeira spec. Um item real do backlog, com requisitos revisados antes do desenho e desenho revisado antes das tarefas. É nesse passo que o time descobre onde o requisito estava vago.
5. Automatizar o que é determinístico. Lint, testes e checagens de segurança como hooks de comando, que dão a mesma resposta para qualquer pessoa do time. Os gatilhos de arquivo respondem só ao que o agente altera, segundo os tipos de hook; a mesma checagem roda no CI para cobrir a edição manual, como detalha o guia de hooks no Kiro.
6. Levar ao pipeline e medir. A CLI em modo headless para revisão de pull request, e métricas de entrega e de qualidade definidas antes de comparar o antes e o depois.

Ao fim do piloto, o repositório tem uma estrutura parecida com esta:

.kiroignore                  # segredos, dumps e dados que o agente não lê
.kiro/
  steering/
    product.md                 # o que o serviço faz e para quem
    tech.md                    # stack, comandos de validação, restrições
    structure.md               # onde cada coisa mora no repositório
    testes.md                  # fileMatch: carregado só ao mexer em testes
  specs/
    <funcionalidade>/
      requirements.md          # critérios de aceitação revisados
      design.md                # arquitetura e decisões, com ADRs citados
      tasks.md                 # tarefas rastreáveis até o requisito
  hooks/
    lint-apos-edicao-do-agente.json  # comando determinístico; o CI repete a checagem
  settings/
    mcp.json                   # servidores aprovados, ferramentas de leitura
docs/adr/                      # decisões de arquitetura que a spec referencia

As regras de permissão não aparecem na árvore de propósito: a documentação de permissões guarda o permissions.yaml do workspace por usuário, fora do repositório. A distribuição dessas regras para o time é decisão de governança, tratada em Governança de IA no código. Para a medição, o método está em Como medir a adoção de IA no time.

Quais armadilhas aparecem na adoção?

As mais comuns vêm de tratar o agente como ferramenta individual. Cada dev configura o próprio contexto, as regras ficam fora do repositório e a revisão olha só o código final, sem olhar a spec que o originou.

• Steering genérico. Arquivo que repete boas práticas da linguagem e omite as decisões do time. O agente já conhece a linguagem; ele não conhece o seu repositório. Escreva o que um revisor do time corrigiria.
• Spec aprovada sem leitura. Aprovar requisitos para chegar logo ao código anula o ganho do método. Revise os critérios de aceitação como revisaria um contrato.
• Modo supervisionado como controle de segurança. A documentação é explícita: ele não é sandbox nem controle de acesso. O limite fica nas regras deny e no .kiroignore.
• MCP com credencial ampla. Servidor que age com a identidade do dev herda tudo que ela pode. Comece com leitura e credencial de curta duração.
• Crédito gasto em verificação determinística. Lint e teste não precisam de julgamento do modelo; rode como hook de comando.

Por onde aprofundar?

Os guias abaixo detalham cada parte, com exemplos de arquivo e as fontes oficiais.

• Fundamentos: specs, steering, hooks e MCP, Powers e contas AWS.
• Operação no time: transição do Amazon Q Developer, Kiro CLI no pipeline, governança de IA no código e medição da adoção.
• IA na AWS além do editor: categorias de IA agêntica no desenvolvimento, modernização com AWS Transform e Kiro, RAG com Amazon Bedrock Knowledge Bases, custo de IA generativa e agentes em produção com Amazon Bedrock AgentCore.
• Contexto de governança: IA generativa no ciclo de desenvolvimento e Shadow AI, o uso de IA sem governança na empresa.

Dois exemplos de escopo do catálogo mostram o Kiro em projeto: Kiro na operação com perfil somente leitura e software house com specs no Kiro e Amazon Bedrock AgentCore.

Quanto custa o Kiro?

Atualização de 15/10/2026. Planos e valores conferidos na página de preços do Kiro na atualização de 15/10/2026. Os preços mudam, estão em dólar e, segundo a própria página, não incluem impostos.

O Kiro cobra por créditos. Cada plano traz uma cota mensal por usuário, que não acumula para o mês seguinte. Nos planos individuais, o uso além da cota vem da compra de pacotes de créditos adicionais a US$ 0,04 por crédito, cobrados na compra; o crédito de pacote não usado vence 12 meses depois da compra. No Enterprise, o excedente começa desabilitado e, quando o administrador habilita, é cobrado a US$ 0,04 por crédito no fechamento do mês. Os créditos são consumidos do mesmo jeito em todas as superfícies, sem cobrança separada de computação em nuvem para o Kiro Web (kiro.dev/pricing).

Os mesmos níveis valem para empresas. Segundo a página de cobrança do Enterprise, as assinaturas de time usam Pro, Pro+, Pro Max e Power, por usuário, com cobrança na conta AWS e identidades no IAM Identity Center. O Enterprise é a camada de gestão (login único, cobrança centralizada, registro de modelos e servidores MCP, controle de overage), não um nível de preço à parte. Acima de 500 usuários, ou com requisitos customizados, a página de preços indica falar com vendas.

Dois esclarecimentos evitam confusão. O plano Power é a assinatura de maior cota; Powers é o recurso de extensão descrito acima, que não tem relação com o nome do plano. E a coluna de crédito adicional da tabela descreve a compra de pacote dos planos individuais; no Enterprise, a página informa que o consumo acima da cota começa desabilitado, precisa ser habilitado no console do Kiro e é faturado no fim do mês. Como estimar e limitar o gasto está em Custo de IA generativa na AWS.

Perguntas frequentes

O Kiro é da AWS?

Sim. O Kiro é um produto da AWS, com site e documentação em kiro.dev. A RFX Tecnologia é parceira AWS Advanced Tier Services e conduz oficinas e projetos de adoção do Kiro; não é a fabricante.

O Kiro funciona sem spec?

Sim. O chat do Kiro atende solicitações diretas, e o Quick Spec gera os três arquivos sem portões de aprovação para trabalho bem conhecido. A spec completa, com revisão por fase, é a escolha para regra de negócio, integração, dado pessoal e caminho crítico.

Preciso de conta AWS para usar o Kiro?

Para uso individual, não. O guia de migração lista login com GitHub, Google, AWS Builder ID ou IAM Identity Center. Em empresas, as assinaturas são gerenciadas no console do Kiro, dentro de uma conta AWS, com identidades no IAM Identity Center.

Qual a diferença entre o plano Power e os Powers do Kiro?

O plano Power é o nível de maior cota de créditos por usuário listado em kiro.dev/pricing. Powers são extensões que combinam ferramentas e conhecimento e são ativadas sob demanda, segundo a documentação.

Como funciona o crédito adicional do Kiro?

Segundo kiro.dev/pricing, consultada em 15/10/2026, a cota mensal de cada plano não acumula para o mês seguinte. Nos planos individuais, o uso além da cota vem da compra de pacotes de créditos adicionais a US$ 0,04 por crédito, cobrados na compra, e o crédito de pacote não usado vence 12 meses depois da compra. No Enterprise, o excedente começa desabilitado e, quando o administrador habilita, é cobrado a US$ 0,04 por crédito no fechamento do mês.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções, IA e Cloud | RFX Tecnologia

Arquiteto de Soluções, IA e Cloud na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.