Um agente propôs seis mudanças noturnas numa base de 205 mil linhas. Os engenheiros ficaram com duas
O Google rodou o Gemini 4 Argon sozinho por 11 horas no Agent Development Kit. Duas mudanças entraram, quatro foram recusadas com razão e uma rodada sem regras quebrou um schema público.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
A maioria dos relatos sobre agentes de código em bases grandes descreve o que o agente produziu. O relato do Google sobre uma execução de uma noite inteira no seu Agent Development Kit é mais útil, porque gasta tanto tempo com o que os engenheiros jogaram fora.
O cenário, publicado em 13 de outubro: o Gemini 4 Argon, rodando no Google Antigravity, trabalhou sem supervisão por 11 horas a partir das 21h11 no google/adk-python, cerca de 205 mil linhas em quase 800 arquivos, com perto de 17 mil testes unitários. O objetivo era encontrar e eliminar overhead de desempenho entre arquivos na inicialização, em sessões longas e em configurações multiagente, sem alterar as entradas do modelo nem a API pública, e abrir um único pull request, sem merge, com números de antes e depois.
A primeira tentativa é a que ensina
Antes da execução noturna, o time fez uma rodada de duas horas sem diretrizes do repositório. O agente passou cerca de 70 minutos medindo antes de editar, o que é boa prática, e encontrou gargalos reais. Também alterou um schema JSON público por meio de um hook do modelo de autenticação, deixou passar casos de borda em eventos de mock, rodou só 216 testes próximos e não incluiu os números do benchmark no pull request.
Nenhum desses é um erro de raciocínio. São os erros que um engenheiro novo e competente comete numa base de código cujas regras não escritas ninguém lhe contou. A segunda rodada resolveu isso de duas formas: diretrizes dos mantenedores guardadas no próprio repositório como .agents/skills, cada uma um índice curto que aponta para arquivos de referência carregados sob demanda (o agente leu 12 deles antes de editar), e um modo de objetivo que mantém a meta fixada através das compactações de contexto. Na segunda rodada o agente seguiu as convenções, rodou uma linha de base em quatro cargas de trabalho com 30 execuções cada e rodou a suíte completa antes de terminar.
Seis propostas, dois merges
| Proposta | Resultado | Motivo |
|---|---|---|
| Filtrar o histórico da sessão antes de copiar | Merge | Cerca de 40% menos overhead antes do modelo em sessões longas em memória |
| Carregar pacotes pesados sob demanda | Merge | Import a frio 21% mais rápido, mantendo atributos de módulo substituíveis em testes |
| Cache de eventos multiagente | Recusada | 17% num teste sintético, mas podia devolver dados velhos entre sessões |
| Verificação de telemetria | Recusada | Lia um atributo privado de biblioteca que podia quebrar num upgrade |
| Reescrita da formatação do histórico | Recusada | Mais difícil de ler, sem ganho de ponta a ponta no benchmark separado |
| Índice de replay de workflows | Recusada | Mais complexidade de estado, útil só em testes sintéticos |
A mudança aceita tocou 22 arquivos, acrescentou 17 funções de teste e entrou na main com a nota “Argon generated these changes”. Os resultados foram medidos num benchmark separado que o agente nunca viu, como medianas de 6 a 12 execuções, com requisições ao modelo idênticas byte a byte antes e depois. Uma execução de 158 turnos com chamadas de ferramenta caiu de 65,6 para 56,1 segundos. O tempo até a primeira requisição num processo novo ficou estável, porque os módulos adiados agora carregam no primeiro turno.
A mudança de carregamento sob demanda mostra o tipo de trabalho em que agentes vão bem. Simplesmente remover os imports do topo quebrou 25 alvos de teste internos do Google que substituem atributos de módulo diretamente. A correção usou acessores lazy que mantêm esses atributos substituíveis, um detalhe entre módulos que um profiler não revelaria.
O que vale para uma base de código enterprise
O resumo do próprio time é “o agente explora, o mantenedor subtrai”. Daí saem três lições para líderes de engenharia que planejam agentes de código de longa duração.
Escreva as regras antes da execução. A maior parte dos erros da primeira rodada veio de convenções que viviam na cabeça dos mantenedores. Skills de repositório são baratas de escrever e reaproveitáveis por todo agente e por toda pessoa nova no time. Em bases de código reguladas, é também onde você registra o que um agente nunca pode tocar.
Separe o benchmark do agente do seu. O cache de eventos recusado parecia um ganho de 17% num benchmark sintético. Um benchmark separado, que o agente não enxerga, é o equivalente em código a a prova vir de fora do modelo: impede o agente de otimizar para o teste.
Orce a revisão como o custo principal. Gerar seis propostas numa noite é barato. Julgar o risco de dados velhos num cache, o risco de upgrade num atributo privado e a legibilidade de um caminho central exigiu mantenedores experientes. Uma taxa de aceitação de duas em seis não é fraqueza da execução; é a cara de uma revisão que funciona. Um programa de agentes que mede sucesso por propostas geradas vai premiar exatamente as quatro mudanças que esse time recusou. Meça as mudanças aceitas, com a evidência de cada uma, como defendemos para mudanças escritas por agentes em geral.
O caso é o repositório do próprio Google, com as ferramentas e os engenheiros do Google, e os ganhos valem para operações específicas do ADK. Não é evidência de que agentes noturnos reduzem o custo de desenvolvimento em geral. É uma boa evidência de como rodar um deles para que o que chega à main mereça estar lá.