Tokenmaxxing: quando a métrica de IA virou o objetivo, e a produtividade foi a primeira baixa
Eu nunca pensei que precisaria escrever sobre funcionários fraudando métricas de IA para parecer que usam IA.
Mas aqui estamos.
Nos últimos meses, uma prática chamada tokenmaxxing ganhou nome e ganhou notoriedade em reportagens sobre Amazon, Meta e outros grandes empregadores. O conceito é simples ao ponto de ser constrangedor: funcionários inflam artificialmente o consumo de tokens dos modelos de linguagem para atingir metas internas de adoção de IA, mesmo quando isso não gera nenhum valor real para o trabalho deles.
Você leu certo. Gastar mais tokens virou objetivo. Não produzir melhor. Não resolver problemas mais rápido. Não entregar código com menos bugs. Gastar tokens.
Isso não é um problema de IA. É um problema de gestão com cara de problema de IA. E a diferença importa muito, porque o diagnóstico errado vai gerar a solução errada, e a solução errada vai piorar tudo.
O que é tokenmaxxing, exatamente
Antes de qualquer análise, vale definir o termo com precisão, porque ele está sendo usado de formas diferentes dependendo do contexto.
Um token, no vocabulário dos Large Language Models (LLMs), é a unidade básica de processamento de texto. Aproximadamente 750 palavras equivalem a 1.000 tokens no GPT-4 ou no Claude. O custo de uso da maioria das APIs de IA é medido em tokens consumidos, tanto na entrada (prompt) quanto na saída (resposta).
Tokenmaxxing é a prática de maximizar deliberadamente esse consumo sem uma razão técnica legítima. Na prática, isso pode significar:
- Enviar prompts desnecessariamente longos e redundantes para inflar o input
- Pedir ao modelo respostas excessivamente detalhadas que ninguém vai ler
- Criar loops de geração de conteúdo que são imediatamente descartados
- Usar IA para tarefas que seriam mais rápidas feitas manualmente, só para registrar uso
- Automatizar a geração de relatórios ou documentos que ninguém solicitou
O resultado final é um dashboard corporativo que mostra adoção de IA crescendo. Por baixo, nada mudou. O trabalho continua sendo feito do mesmo jeito que era antes, com o acréscimo de uma camada de teatro algorítmico.
Por que isso existe: o incentivo perverso em detalhe
Para entender tokenmaxxing, você não precisa entender IA. Você precisa entender a Lei de Goodhart.
Charles Goodhart era economista do Banco da Inglaterra. Em 1975, ele formulou uma observação que virou axioma da teoria de gestão: “quando uma medida se torna um objetivo, ela deixa de ser uma boa medida.”
Esse princípio destrói métricas em todos os setores. Hospitais que são avaliados por tempo de espera aprendem a registrar pacientes mais cedo no sistema, não a atender mais rápido. Escolas que são avaliadas por taxa de aprovação aprendem a passar alunos que não aprenderam. Desenvolvedores avaliados por linhas de código aprendem a escrever código verboso.
O tokenmaxxing é a versão 2025 do mesmo fenômeno. As empresas, pressionadas por narrativas de mercado sobre “transformação com IA” e por boards que querem ver ROI de investimentos em licenças de LLMs corporativos, criaram metas de adoção mensuráveis. Porque metas precisam ser mensuráveis, e o que é mais fácil de medir em IA do que tokens consumidos?
O problema é que tokens consumidos não mede nada sobre valor entregue.
Portanto, quando um gestor diz “precisamos aumentar o uso de IA no time”, a mensagem que chega para o funcionário é: “precisamos gastar mais tokens”. E funcionários racionais, operando sob pressão de avaliação, fazem exatamente o que o incentivo pede.
O papel das grandes empresas nesse ciclo
Amazon e Meta não são exceções — são os casos mais documentados publicamente porque têm maior visibilidade jornalística. Mas o padrão provavelmente se repete em qualquer empresa grande o suficiente para ter metas formais de adoção de IA.
A Amazon, em particular, passou por um período de intensa pressão interna para demonstrar uso de IA generativa depois de enormes investimentos em parceria com a Anthropic. Reportagens de 2024 indicaram que gestores estavam monitorando informalmente o uso de ferramentas de IA pelos times e que havia pressão cultural, não necessariamente regras escritas, para que o uso aparecesse nos relatórios.
Quando a pressão é cultural e informal, ela é ainda mais difícil de resistir. Você pode contestar uma política escrita. É mais complicado resistir a um padrão de comportamento que todos os seus colegas estão adotando e que o seu gestor menciona de passagem em reuniões de check-in.
O problema que o tokenmaxxing revela sobre gestão de tecnologia
Aqui é onde eu preciso ser direto, porque existe uma narrativa conveniente que as empresas podem adotar diante desse fenômeno, e ela é errada.
A narrativa conveniente é: “isso é culpa de funcionários preguiçosos que não querem adotar novas ferramentas.” Essa explicação permite que a gestão continue intacta e coloque o ônus da falha nos indivíduos.
A narrativa correta é: “isso é culpa de uma estrutura de incentivos mal desenhada que garante exatamente o comportamento que ela tentava evitar.”
Funcionários que praticam tokenmaxxing não estão sendo preguiçosos. Estão sendo racionais. Eles leram o ambiente, entenderam o que é recompensado e ajustaram o comportamento para maximizar sua avaliação dentro das regras do jogo.
A responsabilidade por esse desfecho é de quem desenhou as regras do jogo.
Adoção forçada versus adoção genuína
Existe uma diferença fundamental entre adoção genuína de uma ferramenta e adoção performática. Adoção genuína acontece quando a ferramenta resolve um problema real que o usuário tem. Adoção performática acontece quando usar a ferramenta resolve o problema de parecer aderente a uma diretriz corporativa.
GitHub Copilot, por exemplo, tem taxas de adoção orgânica altas em times de desenvolvimento porque resolve um problema real: digitar código repetitivo é chato e lento, e autocompletar contexto é genuinamente útil para uma parte significativa do trabalho diário de um desenvolvedor.
Um chatbot corporativo genérico imposto por política de cima para baixo não resolve problema nenhum se o funcionário não tem uma necessidade real que aquele chatbot atende. Nesse caso, ele vai usar o chatbot para gerar texto que não precisa, só para o dashboard mostrar uso.
A distinção entre esses dois cenários é simples: no primeiro caso, tirar a ferramenta causaria dor real. No segundo, ninguém notaria.
O custo real do tokenmaxxing
Além do óbvio custo financeiro de pagar por tokens que não geram valor, o tokenmaxxing tem consequências que são mais difíceis de medir mas igualmente concretas.
Custos de oportunidade de aprendizado
Quando uma organização mede uso e não resultado, ela perde a capacidade de aprender o que realmente funciona. Os dados de consumo de tokens inflados contaminam qualquer análise de ROI de IA. Se você tentar descobrir quais casos de uso estão gerando valor, vai estar olhando para um conjunto de dados que inclui tanto uso genuíno quanto teatro, e não vai conseguir separar um do outro facilmente.
Essa contaminação é particularmente cara num momento em que as empresas ainda estão descobrindo onde IA generativa realmente entrega valor e onde é só hype. Decisões baseadas nesses dados corrompidos vão estar erradas sistematicamente.
Custos de credibilidade interna
Quando as pessoas percebem que uma métrica é fraudada, elas param de levá-la a sério. Por extensão, param de levar a sério as iniciativas associadas a ela.
Portanto, o tokenmaxxing não apenas infla números. Ele destrói a credibilidade dos programas de adoção de IA internamente. A próxima vez que alguém da liderança apresentar números de uso de IA, o time vai estar pensando: “isso é tokenmaxxing ou uso real?” E sem metodologia para distinguir um do outro, a resposta honesta é “não sabemos.”
Custos de tempo do desenvolvedor
Inflar tokens consome tempo do desenvolvedor. Não muito, individualmente. Mas se um time de 50 desenvolvedores passa 20 minutos por dia gerando output de IA que vai direto para o lixo, isso é mais de 16 horas de trabalho perdidas por dia. Mais de 80 horas por semana. Mais de 4.000 horas por ano.
Esse não é um problema pequeno.
Como identificar tokenmaxxing na sua organização
A detecção não é simples porque o comportamento, por definição, foi otimizado para passar nos filtros superficiais. Mas existem padrões que revelam a prática.
O primeiro sinal é a desconexão entre volume de uso e resultado observável. Se o consumo de tokens do seu time dobrou em três meses mas a velocidade de entrega, a qualidade do código ou qualquer outra métrica de output não se moveu, algo está errado. O uso pode ser real mas ineficaz, ou pode ser inflado artificialmente. De qualquer forma, o número de tokens não está medindo o que você pensa que está medindo.
O segundo sinal é o uso concentrado em momentos de visibilidade. Se o consumo de IA aumenta nas semanas anteriores a reuniões de avaliação ou ciclos de performance review, o incentivo provavelmente está distorcendo o comportamento.
O terceiro sinal é a ausência de casos de uso específicos documentados. Quando você pergunta para alguém “qual problema você resolveu com IA esse mês?”, a resposta deveria ser concreta e imediata. Se você ouve hesitação ou generalizações vagas, o uso provavelmente não foi sobre resolver problemas.
O quarto sinal é o próprio design da métrica. Se você mede tokens consumidos sem medir nenhuma saída correlacionada, você criou as condições perfeitas para tokenmaxxing. A métrica sozinha não é a causa do comportamento, mas é a condição necessária para ele.
O que fazer: redesenhar incentivos, não punir indivíduos
A tentação, quando uma empresa descobre que está acontecendo tokenmaxxing, é tratar isso como um problema disciplinar. Identificar as pessoas que estão inflando uso, ter conversas difíceis, criar controles mais rígidos.
Isso é o movimento errado.
Punir indivíduos por responder racionalmente a incentivos mal desenhados não conserta os incentivos. Cria apenas comportamentos mais sofisticados de ocultamento. E geralmente pune os mais honestos, que admitem o que estão fazendo, enquanto os mais cautelosos continuam fazendo a mesma coisa de forma menos detectável.
A abordagem correta é redesenhar a métrica para medir o que realmente importa.
Métricas de IA que fazem sentido
Em vez de tokens consumidos, considere medir:
Tempo economizado em tarefas específicas. Defina categorias de tarefas onde IA é aplicável — revisão de código, geração de testes unitários, documentação, análise de logs — e meça se o tempo para completar essas tarefas diminuiu. Isso requer benchmarks antes e depois, mas gera dados que significam alguma coisa.
Taxa de aceitação de sugestões com modificação mínima. No caso de ferramentas como GitHub Copilot, a taxa com que desenvolvedores aceitam sugestões com poucas edições é um proxy razoável para utilidade real. Uma sugestão aceita sem modificações provavelmente resolveu um problema genuíno.
Cobertura de casos de uso documentados. Peça para os times registrarem casos de uso específicos onde IA foi utilizada e qual foi o resultado. Não em volume. Em especificidade. Um registro de “usei Claude para analisar esse stack trace e identificei a causa raiz em 3 minutos em vez de 20” vale mais do que 10.000 tokens consumidos sem contexto.
NPS interno da ferramenta. Pergunte periodicamente para o time: “você recomendaria essa ferramenta para um colega?” A resposta honesta a essa pergunta, quando o contexto é confidencial, revela muito sobre se o uso é genuíno ou performático.
Nenhuma dessas métricas é perfeita. Mas qualquer uma delas é mais honesta do que contar tokens.
A lição que se repete em gestão de tecnologia
O tokenmaxxing não é novo. É a versão mais recente de um padrão que reaparece toda vez que uma nova tecnologia recebe mandatos corporativos de adoção sem que os gestores entendam o que estão medindo.
Na era do e-mail corporativo, havia pessoas que mandavam e-mails desnecessários para parecer ocupadas. Na era dos dashboards de KPIs, havia métricas que eram otimizadas em detrimento de outras que não estavam no dashboard. Na era do agile, havia times que completavam sprints sem entregar nada de valor porque a unidade de medida era pontos de story, não impacto.
A IA generativa não mudou a natureza humana nem a natureza dos incentivos organizacionais. Ela apenas criou uma nova superfície onde o mesmo comportamento pode se manifestar.
O erro que as empresas cometem repetidamente é confundir adoção de ferramenta com mudança de prática. Uma ferramenta nova não muda como um time trabalha. Ela pode habilitar mudanças de prática, mas não as causa automaticamente. Mudar prática requer mudar o que é valorizado, como o trabalho é avaliado e quais problemas são priorizados.
Se você quer que seu time use IA de forma genuína, não crie uma meta de uso de IA. Crie problemas que IA pode resolver e deixe o time descobrir que a ferramenta ajuda. A adoção vai acontecer de baixo para cima, vai ser honesta, e vai gerar dados que significam alguma coisa quando você precisar tomar decisões sobre investimentos futuros.
Uma observação sobre o que isso diz sobre o momento da IA
Existe um argumento de que o tokenmaxxing é evidência de que a IA não está entregando valor real e que as empresas estão forçando uma solução em busca de problemas.
Esse argumento é parcialmente verdadeiro e parcialmente preguiçoso.
É verdade que parte da pressão corporativa por adoção de IA é gerada por narrativa de mercado e não por evidência de valor. Conselhos de administração que precisam mostrar para investidores que estão “fazendo algo com IA” criam mandatos que chegam aos times sem análise de onde a ferramenta realmente ajuda.
Também é verdade, no entanto, que IA generativa está gerando valor real em casos de uso específicos. Desenvolvedores que usam GitHub Copilot para código repetitivo são genuinamente mais rápidos nessa categoria de tarefa. Times que usam LLMs para análise de logs e diagnóstico de incidentes reduzem tempo médio de resolução em incidentes de produção. Equipes de conteúdo técnico que usam IA para primeiro rascunho de documentação entregam mais volume com menos esforço.
O problema não é a IA. O problema é o mandato genérico de “use IA” sem especificidade sobre onde e como. Tokenmaxxing é o resultado natural quando a especificidade está ausente e a métrica é superficial.
A distinção que importa: “use IA para reduzir em 30% o tempo de triagem de bugs” é uma diretriz que pode ser avaliada e que orienta comportamento produtivo. “Aumente o consumo de tokens do time em 50%” é uma diretriz que só pode ser avaliada em termos de tokens consumidos, então é exatamente o que você vai obter.
Conclusão: o problema é de quem desenha o jogo, não de quem joga
Tokenmaxxing vai continuar existindo enquanto empresas continuarem medindo adoção de IA por consumo de recursos em vez de por entrega de valor. Isso não é uma previsão especulativa. É a Lei de Goodhart aplicada ao contexto específico.
A boa notícia é que o diagnóstico aponta diretamente para a solução. Não é necessário controlar funcionários de forma mais intensa, criar políticas de uso aceitável mais detalhadas ou punir os casos detectados. É necessário mudar o que está sendo medido.
Medir valor entregue é mais difícil do que medir tokens consumidos. Requer definir o que é valor, estabelecer baselines, coletar dados de resultado, e correlacionar uso com mudança observável. Esse trabalho é mais lento e mais ambíguo do que olhar para um dashboard que mostra número crescente de tokens.
Mas é o único trabalho que vai gerar informação útil para decidir onde IA realmente ajuda e onde é só custo operacional disfarçado de modernidade.
Se o seu time está consumindo muitos tokens e você não consegue nomear três problemas concretos que essa IA resolveu no mês passado, você provavelmente já tem tokenmaxxing. A pergunta é se você quer saber.
💬 Para reflexão
Toda organização que mede o que é fácil de medir em vez do que é importante vai aprender a otimizar o fácil. Tokenmaxxing não é uma falha moral dos funcionários. É a saída racional de pessoas inteligentes operando dentro de um sistema de incentivos mal calibrado. Antes de perguntar “por que meu time está fazendo isso?”, pergunte “por que eu desenhei um sistema onde faz sentido fazer isso?”
