Kiro IDE na prática: quando a IA promete produtividade, mas entrega mais uma camada de trabalho

O mercado de desenvolvimento com inteligência artificial entrou em uma fase curiosa.

Praticamente toda semana surge uma nova IDE, agente, framework, protocolo ou plataforma prometendo mudar completamente a maneira como desenvolvemos software.

A promessa geralmente é parecida: menos código manual, mais automação, agentes capazes de compreender projetos inteiros e integrações que eliminariam boa parte do trabalho operacional.

Na teoria, parece excelente.

Na prática, depois de utilizar algumas dessas ferramentas em projetos reais, comecei a adotar uma métrica bem mais simples:

quanto trabalho humano essa ferramenta realmente eliminou?

Foi com essa expectativa que comecei a utilizar o Kiro, ambiente de desenvolvimento com IA ligado ao ecossistema da Amazon.

E minha experiência, pelo menos até agora, ficou consideravelmente abaixo da expectativa.

Não testei o Kiro criando uma calculadora, uma landing page ou algum projeto demonstrativo preparado especificamente para funcionar bem com IA.

Usei a ferramenta em dois projetos reais que já desenvolvo há algum tempo:

• o GA4 Assistant Bot, integrado ao Google Analytics 4 e ao ChatGPT;

• a Alexa Skill Meus Jogos Futebol, integrada ao ecossistema Alexa e AWS.

Os dois projetos já foram documentados anteriormente aqui no blog da Ad Rock:

GA4 Assistant Bot: consultas inteligentes ao Google Analytics 4 com IA e linguagem natural

Alexa Skill de jogos do futebol brasileiro evolui: agora com IA, notificações e múltiplos jogos

Foi justamente por serem projetos reais, com arquitetura existente, integrações, APIs, autenticação e regras de negócio, que eles acabaram funcionando como bons testes para uma IDE agentic.

Como conheci o Kiro

Meu primeiro contato mais aprofundado com o Kiro aconteceu durante um evento da Amazon realizado por um reseller.

Assisti a uma apresentação sobre a ferramenta e a proposta chamou bastante minha atenção.

Eu já trabalhava com Skills da Alexa e, durante a apresentação, as possibilidades de integração com o ecossistema AWS, incluindo serviços como Lambda, pareceram especialmente interessantes para o tipo de projeto que eu desenvolvia.

Minha expectativa era bastante objetiva.

Se estou utilizando uma IDE inserida no ecossistema Amazon para trabalhar em uma aplicação que utiliza Alexa e AWS Lambda, espero conseguir reduzir significativamente a quantidade de contexto, configuração e alternância entre ferramentas necessárias durante o desenvolvimento.

Não esperava que a IDE magicamente administrasse toda a AWS por mim.

Esperava redução de fricção.

E existe uma diferença importante entre as duas coisas.

O Kiro é tecnicamente interessante

Antes de entrar nos problemas, é importante reconhecer que a arquitetura conceitual do Kiro tem elementos interessantes.

Atualmente, a plataforma trabalha com recursos como:

• Specs;

• Steering;

• Hooks;

• MCP;

• Custom Agents;

• Skills;

• Powers;

• Sub-agents;

• Checkpoints;

• integração entre IDE, CLI e ambiente Web.

A documentação atual apresenta o Kiro como um ambiente agentic construído sobre uma base semelhante à experiência do VS Code, mas com uma camada de agentes capaz de trabalhar com contexto do projeto.

Os Specs procuram transformar requisitos em uma sequência estruturada de requirements, design e tasks.

O Steering permite manter arquivos persistentes com regras, arquitetura e convenções do projeto.

Hooks podem executar ações automaticamente diante de eventos como alterações de arquivos, execução de ferramentas ou conclusão de tarefas.

MCP, ou Model Context Protocol, permite conectar ferramentas externas, APIs e fontes de informação ao agente.

No papel, portanto, existe uma arquitetura interessante para resolver um dos maiores problemas do desenvolvimento com IA: contexto.

O problema que encontrei não está necessariamente no conceito.

Está na experiência prática do agente trabalhando em projetos reais.

Primeiro teste: evoluindo o GA4 Assistant

Um dos projetos em que utilizei o Kiro foi o GA4 Assistant Bot.

Esse projeto nasceu com uma proposta relativamente simples: permitir consultas aos dados do Google Analytics 4 utilizando linguagem natural.

Mas sua arquitetura foi crescendo.

O backend utiliza Python e FastAPI, Google Analytics APIs, OAuth 2.0, OpenAPI, autenticação, isolamento de clientes e integração com ChatGPT.

Cada cliente possui seu próprio contexto e propriedade GA4.

Isso significa que não estamos falando apenas de gerar algumas funções Python.

Existe arquitetura.

Existe autenticação.

Existe contexto.

Existem decisões anteriores que precisam ser respeitadas.

E esse tipo de projeto evidencia rapidamente uma diferença fundamental entre gerar código e entender software.

O problema das alucinações

Minha maior dificuldade utilizando o Kiro nesse projeto foi a quantidade de situações em que o agente parecia compreender perfeitamente uma instrução, mas logo depois executava algo diferente.

Em várias interações, a resposta começava com algo equivalente a:

Understood.

O problema é que, algumas linhas ou ações depois, ficava evidente que o requisito não havia sido realmente compreendido.

Esse comportamento é particularmente perigoso em desenvolvimento assistido por IA.

Uma resposta linguisticamente convincente cria a impressão de que existe alinhamento entre desenvolvedor e agente.

Mas concordância textual não significa compreensão arquitetural.

O agente pode afirmar que entendeu uma restrição e, logo depois:

• alterar algo que deveria permanecer intacto;

• propor uma arquitetura incompatível com o projeto;

• assumir a existência de componentes que não existem;

• interpretar incorretamente uma regra;

• resolver um problema diferente daquele solicitado;

• introduzir complexidade desnecessária.

Nesse momento, o ganho de produtividade começa a desaparecer.

Você deixa de programar determinada parte manualmente, mas passa a trabalhar como supervisor da IA.

E supervisão também possui custo.

O novo trabalho: administrar a própria IA

Existe uma narrativa recorrente de que ferramentas agentic eliminam trabalho.

Minha experiência tem sido um pouco diferente.

Elas frequentemente substituem um tipo de trabalho por outro.

Antes eu precisava escrever determinada implementação.

Agora posso pedir para um agente escrever.

Porém preciso:

1. explicar detalhadamente o problema;

2. fornecer contexto;

3. verificar se o contexto foi realmente compreendido;

4. revisar a implementação;

5. identificar alucinações;

6. explicar novamente o requisito;

7. corrigir decisões arquiteturais;

8. executar testes;

9. revisar o diff;

10. eventualmente desfazer parte do trabalho.

Dependendo da complexidade da tarefa, isso pode continuar sendo vantajoso.

Mas não podemos simplesmente chamar isso de automação sem medir o custo da supervisão.

Segundo teste: Alexa Skill e AWS

O segundo projeto tornou essa questão ainda mais interessante.

Tenho uma Alexa Skill chamada Meus Jogos Futebol.

Ela começou como uma aplicação relativamente simples para consultar o próximo jogo de um clube brasileiro e evoluiu para uma arquitetura com:

• Node.js;

• Express;

• Axios;

• APIs esportivas;

• MongoDB;

• cache;

• notificações;

• AWS Lambda;

• integração com Alexa;

• API executada em infraestrutura externa.

Existe, portanto, uma arquitetura híbrida.

Parte do sistema está na AWS e outra parte utiliza infraestrutura própria.

Quando conheci o Kiro durante a apresentação relacionada ao ecossistema Amazon, esse projeto imediatamente me veio à cabeça.

Parecia um caso perfeito.

A expectativa da integração nativa

Aqui existe uma diferença importante entre marketing, percepção e implementação técnica.

Atualmente, o Kiro realmente possui mecanismos para integração com serviços e ferramentas externas.

Existe suporte a MCP.

Existem Skills.

Existem Powers.

A própria documentação da AWS possui instruções específicas para utilizar tooling serverless com o Kiro.

Por exemplo, para trabalhar com recursos serverless, a documentação da AWS orienta a instalação de uma skill específica e do AWS Serverless MCP Server.

A configuração envolve itens como:

{
  "mcpServers": {
    "awslabs.aws-serverless-mcp": {
      "command": "uvx",
      "args": ["awslabs.aws-serverless-mcp-server@latest"]

{
  "mcpServers": {
    "awslabs.aws-serverless-mcp": {
      "command": "uvx",
      "args": ["awslabs.aws-serverless-mcp-server@latest"]

{
  "mcpServers": {
    "awslabs.aws-serverless-mcp": {
      "command": "uvx",
      "args": ["awslabs.aws-serverless-mcp-server@latest"]

Além disso, existem Powers específicos relacionados a tecnologias como AWS SAM e Lambda.

Portanto, seria incorreto afirmar que o Kiro não possui integração com AWS.

Possui.

A questão é outra.

Integração disponível não significa integração transparente.

E essa diferença ficou muito evidente durante meu uso.

Eu ainda precisava conhecer e operar a infraestrutura

Minha expectativa era conseguir reduzir significativamente a necessidade de navegar entre ambientes e realizar configurações separadamente.

Na prática, continuei precisando compreender e configurar os componentes envolvidos.

Isso inclui credenciais, perfis AWS, regiões, permissões, serviços e configurações específicas.

Em outras palavras, a IA pode ajudar a operar a infraestrutura.

Mas ela não elimina necessariamente a necessidade de compreender essa infraestrutura.

Para alguém técnico, isso não é exatamente um problema.

Na verdade, prefiro que exista controle explícito sobre credenciais, permissões e infraestrutura.

O problema aparece quando a expectativa criada é de uma experiência muito mais integrada do que aquela encontrada durante o desenvolvimento real.

MCP não é mágica

Esse ponto merece atenção porque MCP virou uma das grandes buzzwords do desenvolvimento com IA.

O Model Context Protocol é extremamente interessante.

Ele permite que agentes utilizem ferramentas externas por meio de uma interface padronizada.

Mas instalar um MCP Server não transforma automaticamente um agente em especialista naquele sistema.

Existe uma cadeia inteira:

Cada camada pode introduzir:

• configuração;

• autenticação;

• permissões;

• contexto;

• erros;

• interpretações incorretas;

• limitações da ferramenta.

O MCP resolve um problema importante de interoperabilidade.

Ele não resolve automaticamente o problema de raciocínio.

Essa distinção é fundamental.

O verdadeiro gargalo está mudando

Durante décadas, boa parte do desenvolvimento de software esteve concentrada em transformar requisitos em código.

Com agentes de IA, esse gargalo começa a mudar.

Código ficou barato.

Contexto ficou caro.

O problema agora é garantir que o agente compreenda:

• o que já existe;

• por que existe;

• o que pode mudar;

• o que não pode mudar;

• quais decisões arquiteturais precisam ser preservadas;

• quais dependências estão envolvidas;

• qual é o estado atual do projeto.

É exatamente por isso que ferramentas como Steering, Specs e arquivos AGENTS.md estão se tornando importantes.

Não estamos apenas ensinando a IA a programar.

Estamos construindo mecanismos para impedir que ela esqueça como nosso software funciona.

Specs ajudam, mas também têm custo

A abordagem Spec-Driven Development do Kiro faz sentido.

Em vez de simplesmente escrever:

o processo pode ser estruturado em requisitos, design e tarefas.

Isso reduz ambiguidade.

Mas existe uma questão econômica que raramente aparece nas demonstrações.

Quem escreve, revisa e valida a especificação?

O desenvolvedor.

Portanto, Specs não eliminam trabalho.

Elas deslocam parte do esforço da implementação para a especificação.

Isso pode ser extremamente positivo em projetos complexos.

Uma boa especificação reduz retrabalho.

Mas novamente precisamos medir o resultado real.

Se gasto 40 minutos criando uma especificação que economiza quatro horas de desenvolvimento, excelente.

Se gasto 40 minutos criando uma especificação, mais 30 corrigindo interpretações e mais 30 revisando código que poderia ter escrito diretamente, o ROI muda completamente.

O problema do "Understood"

Talvez uma das coisas que mais tenha me incomodado durante o uso do Kiro tenha sido justamente a recorrência dessa sensação:

O agente confirma.

Executa.

Erra.

Você explica novamente.

Ele confirma novamente.

Executa novamente.

Esse ciclo representa um dos principais problemas atuais dos agentes de desenvolvimento.

O modelo é otimizado para continuar a interação.

O desenvolvedor precisa de outra coisa.

Precisa de confiabilidade operacional.

Prefiro um agente que diga:

do que um agente que responda:

e altere cinco arquivos baseado em uma interpretação incorreta.

Existe diferença entre demo e produção

Esse talvez seja o ponto mais importante deste artigo.

Ferramentas de desenvolvimento com IA normalmente impressionam muito em demonstrações.

Crie um aplicativo.

Adicione autenticação.

Crie uma API.

Gere testes.

Faça deploy.

Tudo acontece rapidamente.

Mas projetos reais raramente começam do zero.

Eles possuem histórico.

Possuem decisões antigas.

Possuem dívida técnica.

Possuem integrações.

Possuem APIs externas.

Possuem credenciais.

Possuem regras de negócio.

Possuem infraestrutura.

Possuem usuários.

Possuem coisas que simplesmente não podem quebrar.

É nesse ambiente que uma ferramenta agentic precisa ser avaliada.

A métrica errada: quantidade de código gerado

Não me interessa quantas linhas de código uma IA consegue escrever.

Essa métrica praticamente perdeu relevância.

Um agente pode gerar 5.000 linhas em poucos minutos.

Se eu precisar gastar três horas entendendo o que ele fez, corrigindo decisões e removendo código desnecessário, isso não representa necessariamente produtividade.

Uma métrica muito mais interessante seria:

Se o resultado for positivo, a ferramenta gerou valor.

Se for negativo, apenas automatizamos a criação de retrabalho.

O custo não é apenas a assinatura

Esse é outro ponto especialmente relevante para empresas.

Hoje temos assinaturas de:

• ChatGPT;

• Claude;

• Codex;

• Cursor;

• Kiro;

• GitHub Copilot;

• agentes especializados;

• plataformas de automação;

• ferramentas MCP;

• IDEs agentic;

• serviços de infraestrutura.

Cada ferramenta individualmente pode parecer barata.

US$ 20 aqui.

US$ 40 ali.

Mais alguns créditos.

Mais consumo de API.

O Kiro, por exemplo, possui atualmente planos pagos baseados em créditos, com diferentes faixas de utilização.

Mas assinatura é apenas uma pequena parte do custo.

O maior custo pode estar no tempo do profissional.

Uma ferramenta de US$ 20 que economiza dez horas por mês é barata.

Uma ferramenta de US$ 20 que consome cinco horas por mês em configuração, correção e supervisão é cara.

Esse cálculo deveria fazer parte de qualquer decisão empresarial envolvendo IA.

Estamos comprando produtividade ou colecionando ferramentas?

Existe hoje um forte incentivo para experimentar tudo.

Eu faço isso também.

Faz parte do meu trabalho entender novas tecnologias e identificar aquilo que pode melhorar meus processos e os projetos dos clientes da Ad Rock.

Mas existe um risco.

Começamos com:

Depois adicionamos:

Depois:

Depois:

Depois:

Depois:

E, quando percebemos, criamos uma arquitetura inteira apenas para administrar ferramentas que deveriam simplificar nosso trabalho.

Isso não significa que essas tecnologias sejam inúteis.

Significa que precisamos parar de avaliá-las pelo hype.

Meu problema atual é orquestração

Hoje meu fluxo de desenvolvimento com IA frequentemente funciona assim:

Funciona.

Mas existe fricção.

Existe troca de contexto.

Existe trabalho manual de orquestração.

Existe a necessidade de explicar o estado atual do projeto entre etapas.

O que eu realmente quero resolver agora não é simplesmente encontrar "uma IA que programe melhor".

Quero reduzir essa fricção operacional.

Próximo teste: Orca

Por isso meu próximo experimento será com o Orca.

O posicionamento da ferramenta é diferente.

Em vez de tentar ser apenas mais um modelo ou simplesmente mais uma interface de chat para programação, o Orca se apresenta como um ambiente para executar e orquestrar diferentes coding agents.

A documentação atual cita agentes como:

• Codex;

• Claude Code;

• Cursor CLI;

• OpenCode.

Cada tarefa pode trabalhar em seu próprio Git worktree, com terminal, browser e ambiente isolado.

Isso é conceitualmente interessante porque ataca um problema diferente.

Em vez de perguntar:

a pergunta passa a ser:

É justamente o problema que quero resolver.

Mas depois da experiência com outras ferramentas, minha postura mudou.

Não estou interessado na demonstração.

Estou interessado no resultado.

Vou colocar projetos reais dentro dele.

Se economizar tempo, ótimo.

Se apenas adicionar mais uma interface, mais configuração e mais uma assinatura ao meu fluxo, será apenas outra ferramenta interessante tecnicamente que não resolveu meu problema.

IA precisa passar pelo teste do ROI

Para empresas, existe uma lição importante nisso tudo.

Não compre IA porque a apresentação foi impressionante.

Não compre porque todo mundo está falando.

Não compre porque existe "agent", "MCP", "autonomous", "copilot" ou qualquer outra palavra da moda na página inicial.

Defina primeiro o problema.

Depois estabeleça uma métrica.

Por exemplo:

Isso transforma IA de hype em investimento.

O que aprendi com o Kiro

Minha experiência com o Kiro até agora não significa que a ferramenta seja tecnicamente irrelevante.

Muito pelo contrário.

Specs, Steering, Hooks, MCP, Skills, Powers e agentes especializados apontam para uma direção interessante na evolução das IDEs.

O problema é que arquitetura interessante não garante boa experiência.

No meu uso, principalmente durante a evolução do GA4 Assistant e da Alexa Skill, a quantidade de correções, perda de contexto e interpretações equivocadas reduziu significativamente o ganho que eu esperava obter.

No caso da Alexa, também percebi que minha expectativa sobre a integração com o ecossistema AWS era maior do que a automação que encontrei na prática.

A integração existe.

A infraestrutura continua existindo também.

E alguém ainda precisa entendê-la.

Talvez estejamos entrando na segunda fase do desenvolvimento com IA

A primeira fase foi:

A segunda parece estar se tornando:

Mas acredito que a próxima questão será:

É por isso que ferramentas de orquestração começam a me interessar mais do que simplesmente outra IDE com chat embutido.

O problema deixou de ser apenas geração.

Agora temos agentes, ferramentas, contextos, permissões, worktrees, modelos, APIs e infraestrutura trabalhando simultaneamente.

Precisamos coordenar tudo isso.

Conclusão

Continuo utilizando IA intensamente para desenvolvimento.

Ela já mudou completamente meu processo de trabalho.

Mas justamente por utilizar essas ferramentas diariamente, estou cada vez menos impressionado com demonstrações e cada vez mais interessado em produtividade mensurável.

O Kiro me chamou atenção em uma apresentação porque parecia aproximar desenvolvimento agentic e infraestrutura AWS de uma maneira especialmente interessante para projetos que eu já possuía.

Coloquei essa expectativa à prova.

No meu caso, o resultado ficou abaixo do esperado.

Isso não significa que o conceito do Kiro esteja errado.

Significa que, no estágio atual dessas ferramentas, ainda existe uma distância considerável entre:

e:

Para mim, essa segunda frase é a única que realmente importa.

Agora o próximo teste será o Orca.

A hipótese também é simples: talvez eu não precise de outra IA programando.

Talvez eu precise de uma maneira melhor de orquestrar as IAs que já tenho.

Vamos descobrir.

Referências e projetos relacionados

Kiro IDE

Documentação do Kiro

Model Context Protocol no Kiro

Documentação AWS para configuração de agentes com AWS Lambda

Orca

GA4 Assistant Bot: consultas inteligentes ao Google Analytics 4 com IA e linguagem natural

Alexa Skill de jogos do futebol brasileiro evolui: agora com IA, notificações e múltiplos jogos