Refatoração como alavanca de custo de token: um experimento na série de gen-AI de Fowler

Na série *exploring-gen-ai* de Fowler, Giles Edwards-Alexander realiza um pequeno experimento: decompõe uma função grande e observa o que acontece com o custo de tokens das alterações assistidas por IA. O refatoramento de alavancagem que você obtém agora é mensurável em dólares.

Em termos simples. Em um novo episódio da série exploring-gen-ai de Martin Fowler, Giles Edwards-Alexander realiza um experimento: decompõe uma função grande e mede se o custo de tokens das alterações subsequentes assistidas por IA realmente diminui. A jogada interessante não é o resultado — é o método. O caso econômico para refatoração torna-se numericamente visível pela primeira vez de uma forma que um contador reconheceria.

Onde isso se conecta

A thread hype-fatigue-2026 tem, até agora, sido conduzida por vozes que alertam que os LLMs não eliminam a parte difícil da programação — eles a redistribuem. O artigo de Edwards-Alexander adiciona um quadro específico e mensurável a esse argumento: ganhos de velocidade sem limpeza aparecem na fatura mensal de tokens, não apenas no moral do mantenedor.

A medição, não a moral

O que importa no experimento é a unidade. Historicamente, "refatorar vale a pena" era defendido com tempo de lead de mudança, taxa de defeitos ou velocidade da equipe — todos reais, todos ruidosos, todos resistidos na hora do orçamento. O custo de tokens é diferente. É uma linha em uma fatura de nuvem. Se um módulo bem decomposto custa significativamente menos tokens por alteração assistida por IA do que um monolítico — porque o assistente precisa de menos contexto por turno — refatorar se traduz em um número que um CFO já acompanha.

Se os números específicos de Edwards-Alexander se generalizam não é o ponto. A contribuição metodológica é que o debate agora pode ser conduzido em tokens por mudança, não em "vibes" por sprint.

O modo de falha, nomeado

O que me traz ao padrão que continuo vendo em trabalhos com clientes: ossificação conduzida por assistente. Um LLM adiciona uma funcionalidade a um módulo que não modela bem. A funcionalidade funciona, mas não se encaixa — duplicação de função auxiliar, condicional de escape, inverso privado de uma utilidade existente. Os testes passam. Três dias depois, o mesmo assistente modela a bagunça como verdade absoluta e a estende. Ao longo de um trimestre, o assistente se torna tanto causa quanto preservador da dívida técnica.

O enquadramento de Edwards-Alexander é útil porque dá à ossificação uma conta. Um módulo que fica progressivamente mais difícil para o assistente raciocinar é um módulo cujo custo de tokens por mudança sobe. Esse é um sinal monitorável.

Por baixo do capô: duas métricas

Números que eu instrumentaria em qualquer base de código com uso intenso de IA, aproveitando o enquadramento do experimento:

• Tokens por alteração assistida por IA, por módulo, rastreados mensalmente. Se subir enquanto o uso do assistente sobe, a ossificação está em andamento.
• Taxa de duplicação em diffs autorados por IA. Barato de calcular com uma ferramenta de similaridade de código; um indicador antecipado da curva de tokens.

Nenhum é um KPI para relatar para cima. Ambos são medidores de alerta precoce.

Onde o artigo fica aquém

O experimento não aborda a próxima pergunta honesta: quando a própria refatoração é delegada a um assistente, o que impede um "limpeza" por LLM de deletar algo crítico. Essa lacuna de pesquisa é real — e é por isso que eu leria o enquadramento de custo de tokens como uma ferramenta diagnóstica, não como piloto automático.

Então, o que fazer

Para um líder: 15-25% de qualquer sprint com uso intenso de IA deve ser dedicado explicitamente à refatoração, tratado como custo de produção, não como folga. Para um tomador de decisão: desconte a velocidade relatada de IA pela trajetória de custo de tokens. Velocidade que aumenta tokens por mudança não é produtividade — é deslocamento para a próxima fatura de nuvem.