O Refactoring Agora Tem Retorno Medido, e Ele É de 83%

Um prompt de mudança idêntico custou 159.564 tokens de entrada antes do refactoring e 27.360 depois. Quinze passos de refactoring no meio. A contagem de linhas do código alterado foi de 17.155 para 16.608, ou seja, ficou parada. Giles Edwards-Alexander, CTO para Europa, Oriente Médio e Índia na Thoughtworks, rodou essa medição sobre uma aplicação de cerca de 150.000 linhas escrita quase inteiramente por agentes, e publicou o resultado na série Exploring Gen AI de Martin Fowler. A frase dele sobre o mecanismo é a que vale guardar: a economia acontece “porque o agente precisa ler menos código. Mas não porque há menos código para ler”.

Isso tira o refactoring do território da preferência artesanal e o coloca numa linha de custo. Toda mudança futura naquele módulo passa a cobrar 83% menos na entrada.

O Protocolo É a Contribuição

O número importa menos do que a forma como foi obtido, porque a forma é reproduzível no seu repositório na semana que vem.

A aplicação tem cerca de 120.000 linhas de Rust, mais TypeScript e Terraform, construída com Claude Code e algum uso de Cursor, mantida por um único desenvolvedor. A camada de acesso a dados havia passado de 6.000 linhas e chegou a 17.155, tudo em um único arquivo Rust. Edwards-Alexander escolheu uma mudança representativa e repetiu este laço após cada passo de refactoring: instanciar um sub-agente novo, entregar o mesmo prompt, registrar os tokens de entrada consumidos para fazer a mudança, descartar o sub-agente.

O descarte é o experimento inteiro. O enquadramento dele é preciso: “Precisamente porque agentes nunca aprendem, isso agora podia ser rodado como um experimento”. Um engenheiro humano medido dessa forma carregaria o conhecimento da base de código do passo um até o passo quinze e contaminaria toda leitura seguinte. A amnésia do agente, normalmente aquilo de que reclamamos, é o que deixa a medição limpa. Mesmo prompt, mesma tarefa, sem transporte de contexto, quinze pontos de dado.

Duas variáveis são acompanhadas por passo: tokens de entrada da mudança representativa e linhas do maior arquivo individual. A segunda é a métrica operável, e a maioria dos times sequer a acompanha.

A Curva Tem um Joelho

A economia se acumula de forma irregular ao longo dos quinze passos, e esse é o achado que um gestor precisa ver antes de aprovar o trabalho.

Os tokens de entrada oscilaram entre aproximadamente 131.000 e 171.000 nos primeiros onze passos. Onze passos de refactoring de verdade, com praticamente nada no medidor. No passo doze, com o maior arquivo já em 9.269 linhas, os tokens caíram para 104.080. No passo quinze, maior arquivo em 3.695 linhas, chegaram a 27.360. Edwards-Alexander descreve o formato como algo que fica “razoavelmente estável até o maior arquivo começar a cair, e então despencam antes de, nas palavras do Claude, cair de um penhasco”.

Quem avaliar uma iniciativa de refactoring depois de duas semanas e vir uma linha de tokens plana vai matá-la um passo antes do retorno. A contagem de linhas do maior arquivo se move primeiro. A conta de tokens só reage depois. Acompanhe o indicador antecedente ou você vai encerrar o trabalho olhando para o atrasado.

O ponto final foram 19 arquivos Rust, sendo o maior deles uma biblioteca de testes com 3.695 linhas. Nada de decomposição heroica. Um arquivo que ainda faria um revisor torcer o nariz, porém pequeno o bastante para que o agente parasse de arrastar o módulo inteiro para o contexto ao alterar uma função.

A Cifra em Dólar É Propositalmente Modesta

Aos US$ 3 por milhão de tokens de entrada que o Sonnet 5 cobrava à época, os 132.204 tokens economizados dão 39,7 centavos. O autor diz isso sem rodeio: “Não é muito”.

Apresentar de qualquer outra forma seria desonesto, e é justamente a honestidade que faz o argumento funcionar. Uma mudança economiza trocado. A tese é sobre recorrência: “essa economia não é pontual. Cada mudança que tocar a camada de acesso a dados daqui em diante custa significativamente menos”. Multiplique 40 centavos por toda edição futura de um módulo central, e lembre que os tokens de saída custam cinco vezes o preço dos de entrada e que um contexto menor também corta latência e taxa de erro. A economia deixa de ser sobre os centavos e passa a ser sobre uma mudança permanente na inclinação da curva.

O lado do custo recebe o mesmo tratamento. Cerca de oito horas, em boa parte sem supervisão, com uma intervenção humana após seis horas e quarenta minutos. Os tokens queimados no próprio refactoring não foram contados, embora ele estabeleça um teto: “O limite superior é de cinco milhões”. Ou seja, o investimento é real e o retorno depende da frequência com que aquele módulo é tocado. Para uma camada de acesso a dados, isso é o tempo todo. Para um arquivo que ninguém edita, refatorar compra zero, e poder afirmar isso com números já é útil.

O Que o Claude Não Conseguiu Fazer

O agente não escolheu os refactorings. Edwards-Alexander é direto: “Claude não era bom em refactoring” e “é incapaz de olhar o código, olhar refactorings em geral e descobrir quais são adequados para aplicar: um humano precisa guiá-lo ativamente”. O plano seguiu movimentos nomeados por Fowler, Extract Class, Extract Function, Replace Inline Code with Function Call, Move Function, escolhidos por uma pessoa que sabia qual deles servia para qual bagunça.

Há um detalhe mecânico que deveria preocupar quem planeja automatizar isso. As edições foram executadas por scripts Python usando grep e sed, e esses scripts “frequentemente se confundiam com a indentação. Ah, a ironia”. Agentes de código escrevendo scripts frágeis de manipulação de texto para reestruturar código que poderiam ter reestruturado semanticamente.

Ele também sinaliza que “cortar o arquivo aleatoriamente em arquivos menores provavelmente não ajuda tanto”, e que aplicou “um refactoring mais rigoroso do que a maioria dos engenheiros humanos seguiria”. Dividir apenas por contagem de linhas falharia em reproduzir essa curva. Fronteiras coerentes são o que permite ao agente ler um arquivo em vez de dezenove.

O Portão Que Não Disparou

Enterrada no texto há uma falha que nada tem a ver com qualidade de código. O harness que construía essa aplicação já tinha um passo explícito de refactoring. Ele rodou. E “não induziu o Claude a melhorar esse arquivo” enquanto o arquivo crescia até 17.155 linhas.

Um controle automático de qualidade existia, estava ligado, executava conforme previsto e não produziu sinal algum enquanto a condição exata que deveria capturar piorava vinte vezes. Um humano acabou reparando no tamanho do arquivo. Isso é falha de plano de controle, e é a lição mais transferível, porque a maioria dos times que adiciona portões de qualidade para agentes está adicionando portões que reportam sucesso ao deixar de reclamar. Silêncio de um portão não prova que o portão funciona. Prova que o portão rodou.

Já argumentamos que código escrito por agentes acumula dívida que ninguém varre, e que a estrutura do contexto dirige o custo em tokens. Este experimento fornece o medidor para os dois, e acrescenta um terceiro: o varredor automático pode estar presente e inerte.

Os Limites Honestos

Um experimento, uma aplicação greenfield, um desenvolvedor. O autor declara isso e nós deveríamos preservar a aresta. As contagens de tokens são aproximações, calculadas com tiktoken dividindo a contagem de caracteres por quatro, porque o Claude “não oferece métodos confiáveis para contar tokens ao vivo”. Os 83% são um caso único bem instrumentado. Tratar a cifra como benchmark seria esticá-la além do que ela sustenta. O que sobrevive à replicação segue desconhecido até alguém replicar, e o protocolo é barato o suficiente para que repliquem.

Faça Isto Agora

Meça o maior arquivo individual do módulo que seus agentes mais editam. Se passar de 5.000 linhas, você tem um candidato.

Escolha uma mudança representativa, do tipo que cai naquele módulo toda semana. Rode-a em um sub-agente novo, registre os tokens de entrada, jogue o sub-agente fora. Essa é sua linha de base. Depois aplique refactorings nomeados, com julgamento humano sobre quais deles se encaixam, e rode o prompt idêntico em um sub-agente novo após cada passo. Plote os tokens de entrada contra a contagem de linhas do maior arquivo e pare quando a curva achatar embaixo.

Duas regras mantêm o exercício honesto. Espere que a linha de tokens fique parada nos primeiros passos, e desconfie de qualquer portão de qualidade que passou o mês inteiro em silêncio. Vá olhar o tamanho do arquivo você mesmo.

Fontes

Giles Edwards-Alexander, Thoughtworks. “The Economic Benefit of Refactoring.” Julho de 2026.

A Victorino ajuda times a instrumentar o custo recorrente em tokens das suas bases de código e a transformar refactoring em investimento com retorno medido: contato@victorino.com.br | www.victorino.com.br