IA agêntica no desenvolvimento de software: categorias, raio de ação e como escolher a abordagem do time

Ferramentas de IA para desenvolvimento de software diferem menos pelo modelo que usam e mais por três variáveis: quanto agem sozinhas, com que contexto trabalham e que controle o time mantém sobre o resultado. Escolher a abordagem do time é decidir o raio de ação do agente: o que ele pode ler, alterar e executar sem uma pessoa no meio, e por qual caminho o trabalho dele chega à revisão.

Verificado contra a documentação do Kiro e da AWS na atualização de 15/10/2026, incluindo as regiões e os controles do Kiro Web.

Raio de ação é o termo adotado neste guia para essa decisão. Ele começa no cursor do editor, passa pelo repositório inteiro, chega ao terminal e ao pipeline e, no limite, sai da máquina do desenvolvedor para um ambiente isolado na nuvem que entrega pull requests. Cada degrau amplia o que a IA resolve sozinha e desloca o controle: do aceite de cada sugestão para a revisão do diff, dos testes automatizados e da configuração de permissão. O Kiro, a IA agêntica da AWS para desenvolvimento de software, cobre vários desses degraus, e por isso a pergunta útil para o time é qual degrau o processo atual sustenta.

Do autocompletar ao agente: cinco categorias

As ferramentas do mercado se distribuem em cinco categorias. Uma mesma ferramenta pode atuar em mais de uma, e a definição abaixo é da categoria, independente do produto.

1. Completar no editor. Sugere a continuação da linha ou do bloco enquanto a pessoa digita. O contexto é o arquivo aberto e o entorno do cursor. A revisão acontece sugestão por sugestão: a pessoa aceita, edita ou descarta.
2. Chat no editor. Responde perguntas e propõe trechos de código a partir dos arquivos que a pessoa seleciona ou menciona. Aplica a alteração quando a pessoa aceita. O raio de ação continua sendo o que a pessoa mostra e aprova.
3. IDE agêntica orientada a spec. O agente lê o repositório, planeja, edita vários arquivos, roda comandos e testes. Antes do código, uma especificação registra requisitos, desenho e tarefas, e cada fase passa por aprovação. A revisão acontece em dois pontos: na spec, onde a intenção é validada, e no diff, onde a implementação é validada.
4. Agente de terminal. Roda no shell, com as permissões do usuário ou do processo que o chamou. Lê e escreve arquivos, executa comandos e se conecta a ferramentas externas. Em modo headless, roda sem uma pessoa presente, dentro de um pipeline de CI, e a permissão deixa de ser uma aprovação na tela para virar configuração versionada.
5. Agente em segundo plano na nuvem. Recebe uma tarefa, clona o repositório em um sandbox isolado, trabalha sem depender da máquina do desenvolvedor e entrega o resultado como pull request. A revisão é a do pull request, com o mesmo rigor aplicado a qualquer contribuição de outra pessoa.

As categorias se acumulam. Um mesmo time pode usar várias delas ao mesmo tempo, cada uma para um tipo de trabalho: completar e chat no dia a dia, spec para funcionalidade nova, terminal para automação e agente na nuvem para o backlog de tarefas bem definidas.

O que muda de uma categoria para outra

A tabela compara as cinco categorias nas dimensões que mais pesam na decisão. O modelo de cobrança de cada produto está na página de preços do fornecedor e não entra na comparação, porque varia dentro de uma mesma categoria.

Dois efeitos aparecem na tabela. O primeiro é o deslocamento do controle: nas duas primeiras categorias, a pessoa controla na hora da escrita; nas três últimas, o controle está na spec, nos testes, na permissão e na revisão. Um time com revisão frágil ganha velocidade de escrita e perde a rede de proteção ao mesmo tempo.

O segundo é a mudança do vetor de custo. Quando a cobrança é por pessoa, o custo acompanha o tamanho do time; quando é por uso, como crédito ou token, acompanha o número de passos que o agente executa. A FAQ do Kiro define crédito como uma unidade de trabalho em resposta às solicitações do usuário e registra que tarefas mais complexas consomem mais créditos e que um modelo mais capaz custa mais por tarefa que o modo Auto. Para agentes que chamam modelos diretamente pela API, o Amazon Bedrock cobra por token de entrada e de saída. Como a fatura é em dólar, o câmbio entra na conta; tratamos estimativa e limite desse tipo de custo em FinOps de IA generativa na AWS.

Onde o Kiro e os serviços da AWS se encaixam

A AWS distribui esse território entre três ofertas com papéis distintos. Separar os papéis evita usar a ferramenta de um problema para resolver outro.

Kiro: o trabalho do time no código. A FAQ oficial descreve o Kiro como uma IA agêntica com IDE, CLI, interface web, aplicativo móvel e Kiro Crew, e a página institucional do produto registra que ele é construído e operado por uma equipe dentro da AWS. Cada superfície corresponde a uma ou mais categorias:

• Kiro IDE: baseada no Code OSS, cobre completar, chat e a IDE agêntica orientada a spec. A documentação de specs descreve três arquivos por spec: requirements.md (ou bugfix.md), design.md e tasks.md, com requisitos em notação EARS. Detalhamos o método em specs no Kiro.
• Kiro CLI: o agente de terminal. Em modo headless, roda em pipeline com a chave na variável KIRO_API_KEY e a flag --no-interactive.
• Kiro Web: o agente em segundo plano. Cada tarefa roda em um sandbox isolado, com repositórios do GitHub ou do GitLab. O modo autônomo, desligado por padrão, deixa o agente planejar e executar com subagentes especializados; quando o trabalho exige mudança no código, entrega pull request, mas nem toda tarefa termina em PR, e algumas se encerram com resposta ou análise no chat. As automações executam uma solicitação nos repositórios em agenda (de hora em hora, diária ou por expressão CRON, em UTC) e abrem pull request ou merge request quando há mudança. A documentação do Kiro Web é explícita: o Kiro nunca faz merge automaticamente.
• Kiro Crew: segundo a documentação, um agente pessoal open source que roda localmente ou remotamente no seu hardware, com sessões, memória e agendamentos que persistem entre conversas, acessível também por canais como Slack e Teams.

AWS Transform: a mesma mudança em muitos repositórios. O AWS Transform custom usa IA agêntica para modernização em larga escala: atualização de versão de linguagem, migração de API e de framework, refatoração e transformações específicas da organização. A transformação é descrita como uma skill (SKILL.md, com references/ e scripts/ opcionais), publicada em um registry da conta, executada em lote pela CLI atx e melhorada a cada execução pelo aprendizado contínuo, que gera lições revisáveis. A unidade de trabalho é a transformação repetida, e não a funcionalidade nova.

Amazon Bedrock AgentCore: os agentes do produto. O AgentCore é a plataforma para construir, implantar e operar agentes em produção, com Runtime, Memory, Gateway, Identity, Policy, Observability e Evaluations, entre outros serviços. Ele atende o agente que o seu cliente usa, e não o agente que ajuda o seu time a escrever código. Mostramos o AgentCore aplicado por setor em agentes de IA com Amazon Bedrock AgentCore.

  TRABALHO DO TIME NO CÓDIGO                     PRODUTO EM PRODUÇÃO
+-------------------------------------------+   +--------------------------+
| Kiro                                      |   | Amazon Bedrock AgentCore |
|   IDE    completar, chat, specs           |   |   Runtime, Memory        |
|   CLI    terminal e pipeline (headless)   |   |   Gateway, Identity      |
|   Web    sandbox na nuvem, entrega em PR  |   |   Policy, Observability  |
|   Crew   agente persistente no seu HW     |   |   Evaluations            |
+-------------------------------------------+   +--------------------------+
| AWS Transform custom                      |
|   a mesma transformação em muitos repos   |
+-------------------------------------------+

Um detalhe de residência de dados entra cedo na análise: a documentação do Kiro Web informa que ele está disponível apenas na região US East (N. Virginia), us-east-1, e que organizações com AWS IAM Identity Center precisam de um administrador para habilitar as Cloud Sessions. Para repositório com dado pessoal, esse é um ponto do mapeamento de LGPD, e não um detalhe de configuração.

O que a pesquisa diz

O relatório DORA 2025 sobre desenvolvimento de software assistido por IA reúne respostas de quase 5.000 profissionais de tecnologia e mais de 100 horas de dados qualitativos, segundo a página do relatório. A conclusão central, nas palavras do resumo: o papel principal da IA no desenvolvimento de software é o de amplificador, que magnifica as forças das organizações de alto desempenho e as disfunções das que estão em dificuldade.

O anúncio do relatório, de 23/09/2025, registra que 90% dos respondentes usam IA no trabalho e que 30% relatam pouca ou nenhuma confiança no código gerado por IA. Adoção alta com confiança parcial é exatamente o cenário em que a forma de revisão pesa mais que a ferramenta.

O relatório acompanha um Modelo de Capacidades de IA com sete práticas que amplificam o efeito da IA. A página de capacidades do DORA marca estas sete como parte do modelo:

• Posição clara e comunicada sobre IA (Clear and communicated AI stance)
• Ecossistemas de dados saudáveis (Healthy data ecosystems)
• Dados internos acessíveis à IA (AI-accessible internal data)
• Controle de versão (Version control)
• Trabalho em pequenos lotes (Working in small batches)
• Foco no usuário (User-centric focus)
• Engenharia de plataforma (Platform engineering)

O relatório também agrupa os times em sete perfis, que vão de times presos a desafios de fundação (Foundational challenges) a times que vão bem em bem-estar, resultado de produto e entrega de software (Harmonious high achievers), conforme o anúncio.

A leitura prática que fazemos para a escolha de categoria: controle de versão e pequenos lotes determinam se um pull request de agente é revisável e reversível; engenharia de plataforma determina se a governança da ferramenta é central ou depende de cada máquina; a posição clara sobre IA determina se o time sabe o que pode entregar ao agente. A ferramenta herda essas condições, para o bem e para o mal.

Como escolher IA agêntica para desenvolvimento de software

A matriz abaixo é o método que a RFX propõe para escolher a categoria inicial. Cada pergunta tem resposta verificável no repositório e no processo, sem depender de opinião.

A última linha exige leitura cuidadosa da documentação. A governança corporativa do Kiro permite ao administrador controlar modelos, servidores MCP, chaves de API, ferramentas web, login e sessões na nuvem. A mesma página registra que parte das configurações administrativas, incluindo configuração de MCP, disponibilidade de modelos e chaves gerenciadas pelo cliente, não se aplica às sessões do Kiro Web. Quem libera o agente na nuvem precisa de controles próprios para ele.

Nas máquinas, as políticas de permissão do administrador ficam em um managed-settings.json em caminho protegido do sistema operacional, lido pela IDE e pela CLI. O exemplo da documentação nega busca na web e comandos destrutivos no shell:

{
  "rules": [
    { "capability": "web_fetch", "effect": "deny" },
    { "capability": "shell", "match": ["rm *", "sudo *"], "effect": "deny" }
  ]
}

Três regras da documentação orientam o desenho. Regras do administrador só usam deny ou ask: restringem, nunca concedem. No conflito com a regra do usuário, vale a mais restritiva (deny, depois ask, depois allow). E a aplicação acontece no cliente, então quem tem privilégio de administrador na própria máquina consegue contorná-la. Para o dado mais sensível, a política local complementa o controle de rede e de identidade, sem substituí-lo.

Um cuidado operacional antes de distribuir o arquivo por MDM: a mesma página registra que o Kiro falha fechado. JSON malformado, regra com effect fora de deny e ask ou campo desconhecido fazem o arquivo inteiro ser rejeitado, e todas as chamadas de ferramenta são negadas até a correção ou a remoção. Valide o JSON no pipeline que publica a política, antes que ele chegue às máquinas.

No pipeline, o raio de ação vira linha de comando. Um job de revisão que só lê e busca no código, conforme o exemplo da documentação de headless:

- name: Revisão do PR com o Kiro CLI
  env:
    KIRO_API_KEY: ${{ secrets.KIRO_API_KEY }}
  run: kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search "Review the changes in this PR for security issues"

A escolha de --trust-tools com IDs exatos, no lugar de --trust-all-tools, é a recomendação da própria documentação para a versão V3: o job lê e busca, e nada além disso.

Armadilhas e como evitar

• Adotar pela demonstração. A demonstração roda em um projeto novo, pequeno e sem histórico. Como evitar: avaliar no repositório mais representativo do time, com uma tarefa real do backlog e o pipeline real ligado.
• Dar autonomia sem teste automatizado. Sem teste, o agente não tem como verificar o próprio trabalho e o revisor não tem como confiar no diff. Como evitar: autonomia proporcional à cobertura; onde ela falta, a primeira tarefa do agente é escrever o teste.
• Medir linhas geradas. Volume de código premia o que alguém vai revisar e manter depois. Como evitar: medir entrega e estabilidade com as métricas do DORA, junto com taxa de aceite de PR e retrabalho, comparando com a linha de base anterior ao piloto.
• Deixar governança para depois. A ferramenta entra antes da política, e cada pessoa conecta o que quer, com a credencial que tem. Como evitar: posição sobre IA escrita, modelos aprovados e servidores MCP liberados antes do primeiro acesso; tratamos o risco em shadow AI e governança e a conexão de ferramentas em MCP no Kiro.
• Espalhar várias ferramentas sem política. Cada ferramenta tem seu modelo de permissão, de configuração e de cobrança, e as convenções do projeto se fragmentam. Como evitar: convenções em arquivo versionado que mais de uma ferramenta lê, como o AGENTS.md, e regras específicas no steering; permissões no managed-settings.json e nas regras de permissão (permitir, perguntar, negar), que são o controle de fato; e automações por evento, como rodar testes ou atualizar documentação ao salvar, em hooks do Kiro, revisados como código. Hook automatiza, e não substitui a regra de permissão como barreira.

Por onde começar

Um piloto com um time, uma categoria e critérios de sucesso escritos antes da primeira linha gerada. O documento abaixo é o modelo proposto; os valores ficam em branco até a medição da linha de base.

# Piloto de IA agêntica: critérios de sucesso

## Escopo
- Time: <nome do time>
- Categoria: IDE agêntica orientada a spec (Kiro IDE)
- Repositório: <repositório representativo, com CI ativo>
- Duração: <n> semanas, com revisão no meio e no fim
- Fora do escopo: produção, dado pessoal real, credenciais de deploy

## Linha de base (medida ANTES do piloto)
- Lead time de mudança: <valor>
- Taxa de falha de mudança: <valor>
- Tempo até a primeira revisão de PR: <valor>

## Sucesso (todos verdadeiros)
- [ ] Nenhuma métrica de estabilidade piorou em relação à linha de base
- [ ] Toda tarefa do piloto passou por spec aprovada e PR revisado
- [ ] O time sabe dizer em que tipo de tarefa o agente ajuda e em qual atrapalha
- [ ] O consumo de créditos ficou dentro do limite definido em <valor>

## Encerramento antecipado (qualquer um)
- Segredo ou dado pessoal enviado ao agente
- Mudança feita fora do fluxo de PR
- Regra de permissão contornada para "destravar" uma tarefa

Com o critério escrito, a ordem prática é: steering do repositório e regras de permissão configurados no primeiro dia; tarefas do piloto escolhidas no backlog real; revisão no meio do período para ajustar regras, sem ampliar o escopo; decisão no fim, com dados, sobre manter, expandir para outra categoria ou para outro time.

O steering do primeiro dia registra convenções e limites de escopo do agente. Segundo a documentação de steering, os arquivos do workspace ficam em .kiro/steering/, o front matter de inclusão precisa ser o primeiro conteúdo do arquivo e o modo always carrega o arquivo em toda interação. Um modelo para o piloto:

---
inclusion: always
---
# Convenções e escopo do agente

## Convenções
- Toda mudança de código vem com teste no mesmo PR
- Dependência nova só com justificativa no design.md da spec
- Commits em pt-BR, no formato <tipo>: <resumo>

## Limites de escopo
- Alterar infra/ e .github/workflows/ só com tarefa explícita na spec
- Usar apenas fixtures/sinteticos/ como massa de teste
- Comandos de deploy, migração de banco e acesso a contas AWS ficam com o time
- Diante de dúvida sobre escopo, parar e perguntar antes de seguir

Steering é instrução ao modelo, e não barreira técnica. O que o agente não pode executar fica nas regras de permissão e no managed-settings.json descritos acima; o steering explica o porquê e reduz as tentativas que a permissão bloquearia. Se o time usa mais de uma ferramenta, as convenções comuns podem ir para um AGENTS.md na raiz do workspace, que a mesma documentação registra como sempre incluído e sem modos de inclusão; o que é específico do Kiro, como arquivos carregados por fileMatch, fica em .kiro/steering/. Organização por domínio e modos de inclusão estão em steering no Kiro.

Na primeira tarefa do piloto, a spec registra os critérios de aceite na notação EARS, no formato WHEN [condição ou evento] THE SYSTEM SHALL [comportamento esperado] descrito na documentação de feature specs. Um requisito genérico, como exemplo:

## Requisito 1: exportar relatório filtrado em CSV

**História de usuário:** Como analista, quero exportar o relatório
filtrado em CSV, para tratar os dados em outra ferramenta.

### Critérios de aceite
1. WHEN o usuário solicita a exportação de um relatório filtrado
   THE SYSTEM SHALL gerar um CSV com as mesmas linhas e colunas
   exibidas na tela
2. WHEN o filtro aplicado retorna zero linhas
   THE SYSTEM SHALL informar que não há dados para exportar
3. WHEN um usuário sem permissão de leitura no relatório solicita
   a exportação THE SYSTEM SHALL recusar a solicitação e registrar
   a tentativa no log de auditoria

Cada critério tem gatilho e resultado observáveis, e por isso vira um caso de teste. A revisão da spec é o ponto de pegar ambiguidade: "as mesmas colunas" inclui as ocultas? O critério 3 cobre usuário sem sessão? Resolver isso no requirements.md custa uma edição de texto; no diff, custa retrabalho. O método completo, de requisitos a design.md e tasks.md, está em specs no Kiro.

Para quem chega agora ao produto, o ponto de partida é o guia do Kiro. Times que usam os plugins de IDE do Amazon Q Developer têm prazo: a documentação da AWS informa o fim do suporte em 30/04/2027 e orienta migrar para o Kiro, com sugestões inline, chat e geração de código. O caminho da transição está em Amazon Q Developer para o Kiro. Para comparar casos de uso de IA por esforço e risco, a matriz de IA da RFX ajuda a priorizar, e a visão completa do pilar está em IA aplicada.

Para definir o piloto, a categoria inicial e os critérios de sucesso com a RFX, fale com a gente. Para levar o Kiro a vários times, com steering, specs e governança desenhados para a sua operação na AWS, conheça a adoção do Kiro com a RFX.

Perguntas frequentes

O que é IA agêntica no desenvolvimento de software?

É a IA que recebe um objetivo e executa os passos para alcançá-lo: lê o repositório, planeja, edita vários arquivos, roda comandos e testes e entrega o resultado para revisão. A diferença para o assistente que só sugere código está no raio de ação, isto é, no que a ferramenta pode ler, alterar e executar sem uma pessoa aprovando cada passo.

Qual a diferença entre completar código, chat no editor e agente?

O completar sugere a continuação da linha e a pessoa aceita cada sugestão. O chat no editor responde e propõe trechos a partir dos arquivos que a pessoa mostra. O agente trabalha sobre o repositório inteiro, executa comandos e entrega um diff ou um pull request. Quanto maior o raio de ação, mais o controle migra do momento da escrita para a revisão, os testes e a configuração de permissão.

O Kiro substitui o Amazon Q Developer?

Para os plugins de IDE, é o caminho indicado pela AWS. A documentação informa que o suporte aos plugins de IDE do Amazon Q Developer termina em 30 de abril de 2027 e orienta migrar para o Kiro, que oferece sugestões inline, chat e geração de código, além de recursos agênticos e suporte a MCP.

Kiro e Amazon Bedrock AgentCore fazem a mesma coisa?

Não. O Kiro, a IA agêntica da AWS para desenvolvimento de software, apoia o time enquanto ele escreve, revisa e mantém código. O Amazon Bedrock AgentCore é a plataforma para construir, implantar e operar os agentes que fazem parte do produto, em produção, com runtime, memória, identidade, política e observabilidade.

Por qual categoria de IA agêntica um time deve começar?

Pela categoria que o processo atual do time consegue revisar com segurança. Com testes automatizados e CI que bloqueia merge, uma IDE agêntica orientada a spec é um bom ponto de partida. Sem essa base, comece por completar e chat e use o agente para escrever os testes que faltam. Em qualquer caso, um piloto com um time, uma categoria e critérios de sucesso escritos antes.

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.