O Gate de Três Estágios do Kiro: Modelos Propõem, Código Decide

Uma frase nas descrições de ferramentas do Kiro fazia uma afirmação falsa sobre o comportamento do harness. Essa frase chegou ao modelo 61.742 vezes em 445 amostras. Ninguém abriu um ticket. Ninguém notou. Um sistema automatizado de rastreamento encontrou a frase, propôs sua remoção, e um gate determinístico confirmou que a remoção era segura. A frase sumiu.

Essa correção é uma das sete que o sistema interno do Kiro, o kiro-trace, mergeou na primeira semana. Zero foram devolvidas em code review. Cada uma mirava um padrão de falha específico medido a partir de execuções reais do agente. O sistema que as produziu é a descrição pública mais rigorosa de autoaperfeiçoamento automatizado de agentes publicada até hoje, e sua restrição central merece estudo: modelos propõem mudanças, mas código decide se essas mudanças sobrevivem.

O Problema dos Loops que se Autoavaliam

A maioria dos loops de autoaperfeiçoamento deixa o agente avaliar o próprio trabalho. O agente lê seus traces, encontra um problema, corrige a si mesmo, re-executa uma vez, vê o número subir e faz o deploy. Isso falha de formas previsíveis.

O time do Kiro encontrou um modo de falha cedo. Um candidato a correção passava mais tarefas e usava menos tokens. A média parecia uma vitória. Quando separaram os resultados por host, quase todo o ganho vinha de uma única execução onde o agente por acaso escapou de um loop no qual normalmente fica preso. Sem esse host, a correção era mais lenta, mais cara e menos precisa. Um loop de autoavaliação teria feito o deploy.

A lição: decidir por médias convida contaminação por outlier. Decidir por deltas, com um controle novo a cada rodada, isola a contribuição da mudança específica da variância que o modelo produziria de qualquer forma.

Três Estágios, Custo Crescente

O kiro-trace submete cada candidato a correção a um gate de três estágios. Cada estágio é mais caro que o anterior. A maioria dos candidatos morre no estágio um, então as verificações caras raramente rodam.

Estágio 1: Triagem de mecanismo. Roda apenas nas falhas-alvo. Dez execuções por braço. A correção precisa marcar 10/10 na tarefa visada enquanto o controle marca 4/10 ou menos. Isso é barato e rápido, e elimina a maioria dos candidatos fracos antes de consumir compute real.

Estágio 2: Triagem de regressão. Cada correção que o Kiro já confirmou vive como uma asserção determinística em uma suíte permanente de regressão. O candidato precisa manter 100% dessas asserções. Uma falha é parada total. Isso previne o dano cumulativo onde a correção N quebra o que a correção N-3 reparou, um modo de falha que loops ingênuos não conseguem detectar porque verificam cada mudança apenas contra seu próprio alvo.

Estágio 3: Confirmação offline. O benchmark completo de 89 tarefas com cinco execuções por braço. O candidato precisa demonstrar superioridade nas tarefas-alvo, superioridade nas tarefas de controle, e não inferioridade dentro de uma margem em todo o resto. Uma verificação de contaminação descarta qualquer aprovação onde o agente usou a rede para buscar a resposta da tarefa em vez de resolvê-la.

Depois dos três estágios, um humano ainda revisa o pull request. O gate não faz deploy. O gate decide o que chega a um humano.

Separação de Papéis

A arquitetura impõe uma separação estrita. O Kiro é o agente sendo melhorado. O loop lê falhas, diagnostica causas raiz e propõe uma mudança por vez. O gate, escrito em código puro, aceita ou rejeita. Um humano faz a decisão de merge.

Qualquer coisa que escreva uma mudança e decida se ela funcionou tende a aceitá-la. O time do Kiro aprendeu isso pela própria experiência: ao julgar comparações manualmente, uma vez leram a mesma execução de três maneiras diferentes. Por isso a decisão agora vive em código que o modelo não alcança.

O Que as Correções Revelam

As sete correções mergeadas na primeira semana contam uma história sobre o que mineração automatizada de traces encontra e humanos não encontram.

Releituras redundantes de arquivos caíram cerca de 83%. A correção: parar de reler um arquivo que não mudou. Contratos de ferramentas excessivamente rígidos causaram 205 rejeições de schema em leitura e 167 rejeições de orquestração de sub-agentes em 80 sessões amostradas. Corrigido ajustando os contratos. Um bug silencioso de busca de arquivos quebrava aproximadamente uma em cada oito buscas. A spec retornava resultados vazios sem erro, então o agente buscava e não encontrava nada. Corrigido. Delegação excessiva criava sub-agentes para edições diretas simples. Corrigido removendo instruções genéricas de delegação.

Nenhuma dessas falhas aparecia como erro visível para o usuário. Nenhum ticket apontava para elas. Uma pessoa poderia tê-las encontrado, mas apenas lendo muito mais execuções do que qualquer um tem tempo para ler.

Compactação: De 0,82 para 0,92

O caso da compactação mostra o loop funcionando do diagnóstico até o release em um único problema.

Compactação é como o Kiro resume uma conversa longa quando atinge o limite de contexto para que uma instância nova possa continuar. O design antigo anexava um dump bruto de mensagens passadas do usuário, do mais novo ao mais velho, ao final de cada resumo. Quando a mensagem que disparava a compactação era um simples “sim, faz isso”, seu contexto já tinha sido resumido enquanto um thread mais antigo sobrevivia intacto. O agente vinculava a confirmação ao pedido errado.

O kiro-trace testou 11 prompts candidatos de resumo frente a frente : dois do Kiro, cinco de agentes de codificação em produção e práticas públicas de handoff, quatro de design próprio. A métrica era retenção: um agente novo, recebendo apenas o resumo, conseguia continuar o trabalho? A pontuação cobria se o resumo era acionável, se os caminhos de arquivos sobreviviam, se decisões anteriores estavam declaradas e se o thread se mantinha coerente.

O design vencedor carregava menos contexto, não mais. Um resumo curto escrito em um template fixo e conciso, limitado em tamanho, mais os turnos mais recentes. Sem dump de mensagens brutas. Sem nomeação de tarefas na instrução de retomada. A retenção subiu de 0,82 para 0,92.

O Resultado Ainda Não Publicado

A maior mudança ainda não foi para produção. Removendo agressivamente, o loop construiu um perfil menor de ferramentas e prompts que marcou 82,4% de pass@1 contra 77,5% no Terminal-Bench 2.1, com aproximadamente um terço do custo em tokens. Não foi publicada porque mudar as ferramentas padrão para cada usuário do Kiro é uma decisão de produto, não de benchmark. O time está decidindo quais ferramentas removidas devem voltar apenas quando uma tarefa precisar delas.

Isso sinaliza maturidade do gate. Um sistema confiante o suficiente para segurar uma melhoria de 4,9 pontos por razões de produto é um sistema que trata publicação como decisão de produto a jusante da medição, não como a medição em si.

Por Que Isso Importa Além do Kiro

O padrão generaliza. Todo time que opera agentes em produção acumula dívida de prompt e ferramentas: instruções que não ajudam mais, descrições de ferramentas que mentem, contratos que rejeitam inputs válidos por tecnicidade. O volume de execuções torna revisão manual impossível. A solução não é deixar modelos avaliarem o próprio trabalho. A solução é construir gates determinísticos que separam proposta de decisão.

O design de três estágios do Kiro oferece um template. Triagem barata por mecanismo. Triagem permanente por regressão. Confirmação cara no benchmark completo. Cada correção confirmada vira uma asserção de regressão para que a suíte cresça com cada melhoria. E a decisão de merge fica com um humano.

Já escrevemos sobre agentes que se autoaperfeiçoam e a lacuna de auditoria em sistemas autocorretivos. A publicação do Kiro é a primeira evidência pública de que a abordagem de gate determinístico funciona em escala, com números.

---

Fontes

• Kim, Myeongsoo et al. “How Kiro Fixes Itself.” Kiro/AWS, Outubro de 2026.

A Victorino ajuda equipes a construir gates determinísticos para autoaperfeiçoamento de agentes. contato@victorino.com.br | www.victorino.com.br