Ajuste suas instruções de ferramentas de agente: redução de 20% nos custos de revisão do GitHub

Resumo

O GitHub substituiu as ferramentas personalizadas de revisão de código do Copilot por ferramentas melhores e mais gerais — grep, glob e view do Copilot CLI — e o agente ficou mensuravelmente pior: custo médio mais alto, menos problemas detectados do que o controle. A solução não foram novas ferramentas ou menos ferramentas. Manter o mesmo conjunto de ferramentas e reescrever apenas as instruções da ferramenta do agente — o texto que diz ao modelo quando usar cada uma — reduziu o custo médio de revisão em cerca de 20% enquanto manteve a qualidade da revisão estável.

Qual é a função das instruções da ferramenta do agente?

Instruções da ferramenta do agente são as regras de ordenação que dizem a um modelo qual ferramenta usar em cada etapa e o que fazer quando uma não retorna nada. Elas não são a mesma coisa que descrições de ferramentas, e a lacuna entre elas é onde a maior parte do custo do agente se esconde.

As descrições são a parte que cada equipe escreve. As instruções são sobre sequência, e quando estão ausentes, o modelo infere uma ordenação a partir de quaisquer prioridades genéricas que possui. Para um modelo de codificação, essas prioridades são um fluxo de trabalho de exploração.

A exploração é o padrão correto para "me ajude a entender este repositório." É o padrão errado para revisão, migração ou triagem — qualquer tarefa que comece a partir de uma entrada delimitada e precise terminar.

Por que ferramentas melhores tornaram a revisão de código do Copilot pior

O artigo do GitHub (Napalys Klicius, 10 de julho de 2026) nomeia o comportamento precisamente. O agente "pesquisaria amplamente, adivinharia caminhos prováveis, leria amplamente, encontraria mais coisas para pesquisar e carregaria esse contexto extra adiante."

Leia essa sequência novamente e note o que está faltando. Não há um passo que termine.

Cada leitura produz novas perguntas, cada pergunta justifica outra pesquisa, e o contexto acumulado ao longo do caminho se transporta para cada turno subsequente. Não é um bug em nenhuma chamada única. É um loop sem condição de término, que é uma coisa muito diferente de depurar — e parece diligência até você ler a conta.

Um revisor humano nunca trabalha assim. Eles abrem o diff, formam uma suspeita específica — esta verificação nula cobre o caminho que o chamador realmente toma? — e vão encontrar exatamente a evidência que a resolve. Eles não leem o módulo.

O diff delimita o trabalho, e a pergunta delimita a leitura. Esse é o fluxo de trabalho que as instruções reescritas codificaram.

As quatro regras que resolveram isso

A orientação revisada do GitHub se comprime em uma ordem de turno declarada para três ferramentas:

• Comece a partir do diff e forme perguntas específicas de revisão. As linhas alteradas são todo o escopo. Não o arquivo, não o módulo.
• Use glob quando o caminho for incerto e grep para encontrar arquivos candidatos. Ambos são baratos. Nenhum arrasta o conteúdo do arquivo para o contexto.
• Agrupe descobertas baratas antes de ler arquivos. Várias pesquisas, depois várias leituras — não pesquisar, ler, pesquisar, ler.
• Use view apenas quando o agente souber qual arquivo ou intervalo de linha precisa. Esta é a única chamada cara no conjunto, então é a única com uma pré-condição.

Há uma quinta regra escondida no artigo que é mais importante do que seu comprimento sugere: em uma pesquisa falhada, mude para glob em vez de adivinhar um caminho. Adivinhar é o que um agente faz quando uma pesquisa retorna vazia e nada lhe disse o que fazer a seguir. Cada resultado vazio não tratado é um lugar onde seu agente improvisará, e a improvisação é onde o loop reinicia.

Nada naquela tabela é uma mudança de implementação. Cada célula é uma frase em um prompt.

O que os 20% realmente medem

O resultado publicado é aproximadamente 20% menor no custo médio de revisão com qualidade de revisão estável, medido nos benchmarks internos de revisão de código do GitHub em produção.

Seja preciso sobre o que a barra do meio representa. O GitHub publicou a direção da regressão — custo alto, problemas detectados baixos — mas não sua magnitude, então é desenhada aberta na parte superior. Uma lacuna honesta supera um número que ninguém mediu.

A comparação que carrega o argumento são as barras dois e três, e essas operam em um conjunto de ferramentas idêntico. Qualquer que seja o custo da regressão, tudo isso e mais 20% além foi recuperado pela prosa.

Por que isso é a coisa de maior alavancagem que você não está fazendo

A orientação da Anthropic sobre escrita de ferramentas para agentes chega ao mesmo lugar a partir de uma direção diferente. Ela relata que Claude Sonnet alcançou o estado da arte no SWE-bench após "preci