Refatorar para gastar menos tokensEngenharia de software · IA generativa
Refatorar para gastar menos tokens
Um experimento com uma base de código escrita por agentes mostra que a qualidade da estrutura influencia diretamente quanto contexto um modelo precisa ler para mudar o sistema.
Por Lucas Fogaça · 1 de agosto de 2026 · Leitura: 5 min
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.
159.564 → 27.360tokens de entrada para a mesma mudança−83%redução aproximada do contexto consumido17.155 → 3.695linhas no maior arquivo
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.