Refatorar para gastar menos tokens

Quando agentes escrevem software em grande escala, a dívida de design não desaparece. Ela muda de forma: além de tornar o código mais difícil de entender, aumenta a quantidade de contexto que o agente precisa consumir a cada alteração.

Giles Edwards-Alexander descreve um caso particularmente útil para pensar nisso. Ele construiu, com Claude Code e Cursor, uma aplicação de cerca de 150 mil linhas — sobretudo em Rust — sem revisar sistematicamente o código produzido. A camada de acesso a dados acabou concentrada em um único arquivo de 17.155 linhas, com repetição de montagem de requisições HTTP e serialização de JSON.

A hipótese do experimento: investir tokens agora em refatoração pode reduzir os tokens necessários para implementar as próximas mudanças.

O que foi medido

O autor definiu uma mudança representativa e a executou, com um agente novo a cada rodada, antes e depois de etapas de refatoração. Assim, evitou que um agente acumulasse conhecimento do código ao longo do caminho. Em cada ponto, registrou linhas de código, tokens de entrada e saída e tempo de execução.

O resultado mais expressivo não veio de apagar código em massa. A camada de acesso a dados terminou praticamente do mesmo tamanho: 16.608 linhas. O que caiu foi o maior arquivo, de 17.155 para 3.695 linhas, depois de extrair duplicações e separar responsabilidades em arquivos menores.

Métrica	Resultado
Tokens de entrada para a mesma mudança	159.564 → 27.360
Redução aproximada do contexto consumido	83%
Linhas no maior arquivo	17.155 → 3.695

O mecanismo importa mais que o corte

Dividir um arquivo arbitrariamente não garante economia. Se a divisão espalhar uma responsabilidade por muitos lugares, o agente ainda precisará abrir e atravessar todos eles. O ganho observado parece depender de duas coisas: limites mais claros e um conjunto menor de arquivos relevantes para cada mudança.

Essa distinção é importante. A arquitetura não reduz apenas a dificuldade humana de navegar pelo sistema; ela orienta a recuperação de contexto do agente. Em termos práticos, a refatoração ajuda quando torna mais fácil identificar onde a alteração realmente deve acontecer.

O que isso muda no trabalho diário

• Use arquivos gigantes como sinal. Não por uma regra estética de tamanho, mas porque eles forçam o agente a ler muito contexto irrelevante.
• Refatore antes de delegar uma sequência de mudanças. O custo inicial pode ser compensado se a área continuar recebendo trabalho.
• Meça uma mudança recorrente. Escolha uma tarefa representativa e compare tokens, tempo e arquivos lidos antes e depois.
• Não espere autonomia arquitetural. No relato, os agentes precisaram de direção humana tanto para escolher quanto para aplicar várias refatorações.

Há limites para a conclusão

Trata-se de um experimento único, em uma aplicação ainda greenfield e mantida por uma pessoa. A contagem de tokens também foi aproximada a partir de caracteres, porque a ferramenta não oferecia uma medição confiável ao vivo. E o custo total da própria refatoração não foi isolado: o autor estima apenas um teto de cinco milhões de tokens para todo o trabalho de planejamento e execução.

Mesmo com essas ressalvas, o experimento oferece uma tese concreta: em desenvolvimento assistido por IA, uma boa refatoração não é só uma aposta em manutenção futura. Ela pode diminuir, já na próxima tarefa, o contexto que o agente precisa carregar para trabalhar bem.

---

Fonte: adaptação e comentário a partir de “The Economic Benefit of Refactoring”, de Giles Edwards-Alexander, publicado em MartinFowler.com em 30 de julho de 2026.