Instruir a IA a não usar identação no código economiza token?

Esse é o primeiro post de uma série que pretendo manter aqui: comentários rápidos sobre estudos, ferramentas e novidades que me chamam atenção durante a semana. Esse foi o primeiro assunto que pegou minha atenção agora, então vou direto ao ponto.

Vi um vídeo no X comentando um estudo que dizia: instruir a IA a não usar identação, espaço nem quebra de linha no código economiza uma boa quantidade de tokens. Fui atrás da fonte e encontrei o paper original, The Hidden Cost of Readability: How Code Formatting Silently Consumes Your LLM Budget, de pesquisadores da Monash University e da Singapore Management University.

O que eles testaram

Os autores testaram dez modelos de IA (incluindo GPT, Claude e Gemini) fazendo uma tarefa comum pra qualquer assistente de código em IDE: completar um trecho de código que está com o meio faltando. Fizeram isso em quatro linguagens (Java, Python, C++ e C#), comparando código formatado do jeito normal (identado, espaçado, como qualquer editor faz automaticamente) contra código "espremido": sem identação, sem espaço extra, sem quebra de linha, mas com exatamente o mesmo significado pro compilador.

Os números certos

Em Java, a linguagem que mais se beneficia, a redução média de tokens de entrada foi de 34,9%, com um dos modelos (DeepSeek) chegando a 42% em casos específicos. Daí o "quase 40%" que eu tinha ouvido, que é real, mas é o teto, não a média geral. A média geral, olhando todas as linguagens e modelos, ficou em 24,5%. Python quase não ganha nada (6,5%), porque identação e quebra de linha fazem parte da sintaxe da linguagem e não dá pra tirar sem quebrar o código.

E o mais importante: a qualidade das respostas praticamente não muda. Em nenhum caso a queda de acerto passou de 4,2%, e em alguns modelos o resultado até melhorou sem a formatação.

O detalhe que muda a conta inteira

Aqui está o que o vídeo não deixava claro: essa economia de tokens é só de entrada. O que o modelo gera de volta continua vindo formatado, do jeito que ele aprendeu no treino. A redução na saída fica em torno de 2,5% em média, quase irrelevante.

Pra economizar também na saída, os autores testaram duas saídas: instruir o modelo explicitamente a gerar sem formatação, ou fazer fine-tuning com poucos exemplos. Prompt funcionou bem pro GPT (27,2% de redução na saída, mantendo a qualidade), mas quebrou o Gemini-1.5: o modelo removeu espaços que a sintaxe exige, gerando código inválido como staticbool em vez de static bool, e a taxa de acerto em C++ despencou de 67,2% pra 11,1%. Fine-tuning com só 50 amostras funcionou melhor e sem esse risco, reduzindo a saída em até 35,9% no Gemini-1.5 e 24,8% no GPT-4o.

O que muda na prática

Isso bate com o que eu já desconfiava, mas com uma correção importante: dá pra economizar de graça só cortando a formatação do que você manda pro modelo: funciona bem, sem quebrar nada, em qualquer um dos dez modelos testados. Só que isso resolve metade do custo. A outra metade, o que o modelo devolve, exige ou um prompt bem específico (com risco em modelos menos robustos) ou fine-tuning.

Os próprios autores foram além da medição e construíram uma ferramenta que faz a conversão nos dois sentidos: tira a formatação antes de mandar pro modelo e devolve formatado pro humano ler, verificando que o código gerado continua exatamente equivalente ao original em 100% dos casos testados, levando cerca de 76ms por arquivo.

Meu veredito

Economizar em entrada é praticamente grátis e sem risco, então faz sentido em qualquer pipeline que manda muito código pra IA como contexto. Economizar em saída já exige mais cuidado: um prompt malfeito pode quebrar sintaxe em modelos mais fracos, então vale medir antes de confiar cegamente na instrução. Pra código que um humano vai ler direto, a formatação continua sendo a escolha certa; o ganho de token não compensa o custo de legibilidade.