Waydev: a corrida por tokens reduz o retorno da programação com AI e infla o volume de retrabalho

Um novo culto nas equipes que usam intensamente IA para codificação: não a qualidade dos lançamentos, mas o volume de tokens queimados. O problema é que mais código e mais PRs não necessariamente significam mais trabalho útil: uma parcela significativa desse volume acaba sendo reescrita.

Como funciona o tokenmaxxing

O termo tokenmaxxing descreve uma lógica simples: se um desenvolvedor gasta muitos tokens no Claude Code, Cursor ou Codex, supostamente ele trabalha com mais produtividade. Dentro das empresas, grandes orçamentos de computação com IA já se tornaram um elemento de status, quase como o número de linhas de código ou commits faziam antes. Mas é o mesmo erro antigo em embalagem nova.

Tokens são uma entrada no processo, não um resultado. Eles mostram quanto de recursos foi queimado, mas não respondem se a equipe tem mais código confiável, útil e sustentável. De acordo com a Waydev, que trabalha com aproximadamente 50 empresas e mais de 10 mil engenheiros, gerentes frequentemente veem um quadro de alto nível muito bonito: 80–90% do código gerado por IA é inicialmente aceito e entra no repositório.

Mas então começa uma parte menos visível do trabalho—correções, reversões e reescritas nas semanas seguintes. Se você considerar essa cauda, a parcela real de código que realmente "pegou" cai para 10–30%. É aqui que a ilusão de produtividade instantânea desmorona.

Métricas contra ilusões

Várias empresas que trabalham com análise de engenharia agora estão tentando medir esse quadro. A demanda cresceu tanto que grandes players também começaram a investir em tais ferramentas: a Atlassian comprou a startup DX por $1 bilhão em 2025 para medir melhor o retorno de agentes de IA no desenvolvimento. A conclusão geral entre diferentes plataformas é similar: o volume de código produzido está crescendo, mas a parcela de resultados sustentáveis não está.

• GitClear relata que usuários regulares de ferramentas de IA mostram code churn 9,4 vezes mais alto do que desenvolvedores sem IA, embora o crescimento ano-a-ano limpo pareça muito mais modesto—cerca de 25%.
• Faros AI em seu relatório de março de 2026 registrou um aumento de 51% no tamanho do PR com alta participação de IA no desenvolvimento, aumento de 28% em bugs por PR, aumento de cinco vezes no tempo médio de revisão e um pico de code churn de 861%.
• Jellyfish em uma amostra de 7.548 engenheiros descobriu que os desenvolvedores mais "orçamentosos em tokens" fazem mais PRs, mas a dependência rapidamente se torna não lucrativa em preço.
• Nos dados da Jellyfish, os 20% principais em gastos com tokens lançaram em média 23 PRs mesclados por trimestre contra 11 para os 20% inferiores, mas gastaram cerca de $1.822 nisso versus aproximadamente $3.

O custo do código extra

O principal problema não é que a IA escreve muito, mas que o volume extra desloca o custo do trabalho para mais abaixo no pipeline. A equipe gera rascunhos mais rapidamente, mas depois paga por leitura, revisão, integração e manutenção deste código. Se PRs ficam maiores, bugs mais numerosos e revisões mais longas, então parte da "aceleração" é simplesmente movida para o futuro como débito técnico.

Isso é especialmente notável em desenvolvedores juniores: eles frequentemente aceitam sugestões de IA sem muita filtragem e depois frequentemente voltam a essas mudanças. Com engenheiros sênior, a situação é melhor porque eles definem contexto com mais precisão e cortam lixo na entrada de forma mais impiedosa. Mas mesmo nesse caso, o retorno marginal declina.

Jellyfish escreve quase linearmente: no extremo superior da curva, desenvolvedores gastam quase 10 vezes mais tokens para obter aproximadamente o dobro do throughput. Não é mais uma história sobre eficiência, mas sobre aceleração muito cara.

"Esta é uma nova era do desenvolvimento de software, e as empresas terão que se adaptar de qualquer forma," diz

Alex Chirchey, CEO da Waydev.

O que isso significa

A codificação com IA não vai desaparecer, mas um culto de gasto máximo de tokens parece uma métrica de gestão ruim. Se as empresas querem produtividade real, elas terão que olhar não para a quantidade de código gerado, mas para quantas mudanças passam pela revisão sem quebrar a produção, não retornam para reescrita e pagam pelo seu custo em tokens.