Índice

Em maio de 2026, o Tom's Hardware noticiou que "funcionários da Amazon estão usando IA desnecessariamente para cumprir cotas internas". A empresa estabeleceu uma meta interna: "mais de 80% dos desenvolvedores devem usar ferramentas de IA toda semana", com o consumo de tokens exposto em um placar interno. Os funcionários reagiram bombeando tokens: "rodando tarefas que são copiar-e-colar pela IA mesmo assim", "dividindo uma pergunta em várias", "pedindo ao Claude para escrever poesia só para queimar tokens". Comportamentos semelhantes foram documentados na Meta e na Microsoft.

O Vale do Silício deu um nome à tendência: "Tokenmaxxing". Uma nova norma de trabalho na qual maximizar o consumo de tokens é recompensado. Quase toda Fortune 500 está rastreando o uso de IA, mas pouquíssimas estão medindo ROI (segundo o CTO da ModelOp). A métrica "quantidade usada = quantidade de trabalho feito" começa a desviar as decisões organizacionais em más direções.

Vou colocar minha opinião na frente: "consumo de tokens = produção de trabalho" é a repetição nos anos 2020 da avaliação de desenvolvedores por KLOC (mil linhas de código) dos anos 1990. Volume é fácil de medir, mas volume e valor são coisas diferentes. Um estudo com 22.000 desenvolvedores e 4.000 equipes mostra que o uso de IA elevou a conclusão de tarefas em +34%, mas os bugs subiram +54% e o tempo de revisão de PR cresceu 5x. Este artigo cobre por que a métrica ruim se espalhou, o que há de errado com ela, que alternativas existem (AWU da Salesforce, DORA, métricas de resultado da AWS) e cinco ações práticas que indivíduos e organizações podem tomar a partir de hoje — apoiadas em dados de campo e fontes primárias.

TOKENMAXXING · 2026

Meça só "quanto" e o chão racha

— Volume +34%, mas a qualidade quebra: bugs +54% / tempo de revisão 5x

Volume (tarefas concluídas)
+34%
Épicos concluídos +66%. O uso de IA realmente acelera o desenvolvimento.
Qualidade (bugs por dev)
+54%
Bugs em produção por desenvolvedor mais que cinquenta por cento acima. "Rápido, mas com bugs" agora é real.
Tempo de revisão
5×
Tempo mediano de revisão de PR 5x maior. O volume é empurrado para os revisores — humanos não conseguem absorver a taxa de saída da IA.

Fonte: Estudo "Tokenmaxxing" da Faros AI (22.000 devs × 4.000 equipes).
Persiga só o volume e o chão racha. A lição que já aprendemos com KLOC nos anos 1990 — agora repetida com uma nova unidade.

1. A meta da Amazon de "80% de uso semanal de IA" — e o bombeamento de tokens que se seguiu

Em maio de 2026, o Tom's Hardware publicou uma reportagem investigativa que colocou o "Tokenmaxxing" no mapa. A Amazon havia definido uma meta interna: "mais de 80% dos desenvolvedores devem usar ferramentas de IA toda semana". O consumo de tokens foi visualizado em um placar interno, e gerentes o citavam em avaliações de desempenho.

O que os funcionários fizeram? "Rodar uma tarefa que é copiar-e-colar pela IA assim mesmo." "Dividir uma única pergunta em várias." "Fazer o Claude escrever poesia só para queimar tokens." Consumo ocioso de tokens, sob qualquer outro nome. Funcionários da Amazon citados pelo Tom's Hardware disseram que a pressão da cota era intensa e estavam "forçando a IA em trabalhos onde não usar IA teria sido mais rápido". Os mesmos padrões aparecem na Meta e na Microsoft — isso não é só uma história da Amazon.

O Trending Topics (imprensa de tecnologia da UE) resumiu a mudança como "uma métrica técnica se tornando o credo de uma nova cultura de trabalho". "Performar uso de IA" vira um eixo de avaliação por si só. Isso está acontecendo simultaneamente em empresas da Fortune 500 em 2026.

2. Por que "consumo de tokens = produção de trabalho" se espalhou

Então, por que grandes empresas estão adotando uma métrica tão tosca para começar? Três razões.

Razão ①: O investimento em IA precisa de justificativa

Empresas da Fortune 500 investiram bilhões em IA nos últimos dois anos. Toda vez que o CFO ou o conselho pergunta "qual é o retorno desse investimento?", o CTO precisa de um número. O consumo de tokens é o número mais fácil de produzir. Logs dos gateways de API, históricos de chat interno, uso de ferramentas de codificação — tudo é agregado automaticamente. Ler "quantidade usada" como "quantidade de valor criado" tornou-se o caminho de menor resistência para a explicação.

Razão ②: Expor os resistentes à IA

Toda organização tem funcionários céticos quanto à IA: preocupações com privacidade, com qualidade ou simplesmente falta de disposição para aprender novas ferramentas. A gerência quer obrigar o uso de IA, mas comandos sozinhos não movem pessoas. Expor o consumo de tokens vira uma ferramenta para identificar "as pessoas que não estão usando IA". A meta de 80% da Amazon foi construída exatamente para isso.

Razão ③: Demanda por um único escalar comparável

Medidas qualitativas como "qualidade", "resultados" ou "limpeza do código" não se comparam com facilidade. "A pessoa A usou 1M de tokens este mês, a pessoa B usou 500K" — um único valor escalar é lido como se A obviamente tivesse produzido mais. Comparação fácil convida decisões preguiçosas. Isto é estruturalmente idêntico ao fracasso do KLOC (mil linhas de código) nos anos 1990.

3. Dados concretos sobre a divergência entre quantidade e qualidade

Se "quantidade usada = trabalho feito" se sustentasse, a métrica de tokens estaria bem. O que a realidade mostra? O estudo Faros AI 2026 — 22.000 desenvolvedores em 4.000 equipes — publicou números que descartam decisivamente essa ideia.

Faros AI 2026 / N=22.000

O que o uso de IA eleva — e o que ele quebra

↑ Elevado
  • Tarefas concluídas: +34%
  • Épicos concluídos: +66%
  • Linhas de código adicionadas: forte alta
  • Contagem de PRs: claramente em alta
↓ Quebrado
  • Contagem de bugs: +54%
  • Tempo de revisão de PR: 5x
  • Taxa de retrabalho: em alta
  • Incidentes em produção: em tendência de alta

"O volume de saída sobe, mas a qualidade e a manutenibilidade sofrem o impacto."
Essa é a realidade de campo. Métricas de consumo de tokens olham apenas para metade do quadro.

"A IA torna o desenvolvimento mais rápido" em si não é falso. Tarefas +34%, épicos +66% — são números reais que mostram valor real. O problema é o que o mesmo conjunto de dados mostra sobre o custo. Bugs +54%, tempo de revisão 5x — revisores humanos não conseguem acompanhar o código gerado por IA, e defeitos vazam para jusante. Alguns pesquisadores alertam que os ganhos de produtividade de curto prazo podem ser compensados pelo crescimento da dívida técnica de longo prazo.

4. Três distorções acontecendo no campo

Chega de teoria. O que está realmente acontecendo no campo? Três padrões observáveis.

Distorção ①: Bombeamento de tokens

A mais comum. Chamar a IA puramente para "ser visto usando-a". Os comportamentos da Amazon: "rodar tarefas de copiar-e-colar pela IA", "dividir uma pergunta em várias", "conversar com a IA sobre temas não relacionados". Puro aumento de custo, sem valor. A métrica agora está degradando ativamente o ROI de IA da empresa — exatamente o que ela deveria medir.

Distorção ②: Velocidade acima da substância

Se "escrever mais lhe rende melhores avaliações" é a regra, as pessoas respondem de acordo. Revisar mais leve e fazer merge mais rápido, pular testes, adiar refatorações — todas ações racionais para inflar a produção de curto prazo. O "bugs +54%" da Faros é o resultado previsível.

Distorção ③: Deriva em direção a tarefas "amigáveis à IA"

Uma distorção mais sutil. O trabalho se afasta de problemas difíceis e importantes (design, limpeza de dívida técnica, pesquisa profunda) em direção a trabalhos rotineiros nos quais a IA é boa (código CRUD, geração de documentação, esqueletos de testes). Apenas o trabalho mensurável avança. Esta é a Lei de Goodhart (quando uma medida se torna uma meta, ela deixa de ser uma boa medida) em forma de livro-texto.

A história se repete: nos anos 1990, muitas empresas tentaram avaliar desenvolvedores por KLOC (mil linhas de código). Os resultados: "código inflado sem propósito", "lógica simples escrita de forma prolixa", "refatorações úteis evitadas (porque reduzem a contagem de linhas)". Trinta anos depois, estamos repetindo o mesmo erro com uma nova unidade chamada "tokens".

5. Métricas melhores — AWU, DORA, baseadas em resultados

Se tokens não são a resposta, o que você deveria medir? Três alternativas da safra 2026.

Métricas alternativas × 3

Meça o impacto da IA além dos tokens

① AWU (Agentic Work Units)
Proposta de 2026 da Salesforce. Traduz insumos de IA (tokens, computação) em unidades de trabalho concluído. Escalariza "o que foi construído". Padronização ainda em andamento.
② DORA 4 Metrics
Origem Google. Frequência de deploy, lead time, taxa de falha em mudança, MTTR. Focado em resultados, com 15 anos de validação. Continua funcionando na era da IA.
③ Indicadores de resultado
Recomendado pela AWS. Velocidade de deploy, qualidade de código, eficiência operacional, produtividade da equipe, impacto no negócio em combinação. Sacrifica simplicidade pela precisão.

O que elas têm em comum: medem "o que saiu", não "o que foi usado".
Mais difíceis de capturar, mas qualquer uma delas levará a decisões melhores do que o consumo de tokens isolado.

Minha opinião pessoal: DORA é a mais prática. Quinze anos de uso operacional, muitos dados de benchmark e improvável de se deformar na era da IA. O AWU da Salesforce é ambicioso, mas ainda não é padrão da indústria. Se você quer algo que dê para medir amanhã, comece pelo DORA.

6. Cinco ações para indivíduos e organizações hoje

A teoria está resolvida. O que você pode realmente fazer amanhã de manhã? Dividido por papel.

Para desenvolvedores individuais

  • ① Não transforme o consumo de tokens na sua própria métrica: mesmo que seu gestor esteja observando, avalie-se pelo que você concluiu. Se uma tarefa é mais rápida sem IA, não force a IA nela
  • ② Reserve tempo de revisão: presuma que código gerado por IA leva "tempo de leitura ≥ tempo de escrita". Aloque tempo para ler seu próprio PR por inteiro antes de submetê-lo à revisão
  • ③ Combine com economia de tokens: prompt caching, Batch API, instruções enxutas — "alto resultado com baixo uso de tokens" é a verdadeira habilidade

Para a gestão

  • ④ Use o consumo de tokens apenas como sinal de aquisição: nunca como avaliação individual. Acompanhe em escala organizacional para confirmar que o investimento em IA está realmente sendo usado, nada além
  • ⑤ Migre para as métricas DORA: frequência de deploy, taxa de falha em mudança, MTTR em cadência trimestral. Compare antes/depois da adoção da IA para ver se os ganhos são reais ou apenas bombeamento de tokens
Mais importante: ao reportar a executivos, CFO ou conselho, separe "consumo de tokens é uma métrica de atividade, resultados de negócio são métricas de resultado". Tentar explicar tudo com um único número é o que produz decisões desleixadas. Trate "quantidade usada" e "valor produzido" como tópicos diferentes — essa disciplina é a chave para conduzir bem uma organização na era da IA.

Resumo

Recapitulando:

  • 2026: "Tokenmaxxing" (bombeamento de tokens para inflar métricas) observado na Amazon, Meta, Microsoft — agora um termo da indústria
  • Estudo Faros AI com 22.000 desenvolvedores: o uso de IA eleva a conclusão de tarefas em +34%, mas bugs +54%, tempo de revisão 5x. Quantidade e qualidade divergem
  • "Consumo de tokens = produção de trabalho" é a repetição nos anos 2020 da avaliação por KLOC dos anos 1990. A Lei de Goodhart torna a deformação inevitável
  • Três distorções de campo: bombeamento de tokens / velocidade acima da substância / deriva para tarefas amigáveis à IA
  • Alternativas: AWU da Salesforce / DORA 4 / indicadores de resultado da AWS. DORA é a mais prática hoje
  • Indivíduo: avalie-se pelo que está feito. Organização: migre a avaliação para DORA, reporte o consumo de tokens apenas como dado de atividade

Em 2026, com a IA dentro das organizações, a tentação de medir volume é mais forte do que nunca. Logs de API fornecem contagens de tokens de graça — exatamente por isso a armadilha de ler esses números como "produção de trabalho" é tão profunda. A lição que já aprendemos com KLOC há trinta anos não deve ser repetida em uma nova unidade chamada "tokens". Essa é a primeira inteligência organizacional exigida na era da IA.

FAQ

Q1. Isso acontece também em empresas menores?

Sim, independentemente do porte. Aliás, empresas menores enfrentam pressão ainda maior para "avaliar pelo que é mensurável", e os líderes pegam a métrica mais fácil. Até startups estão definindo regras internas como "meta de 100% de uso de IA". A mesma armadilha.

Q2. Como mover funcionários resistentes à IA?

"Experimente isto e me diga o que achou" supera "use" no longo prazo. Cotas de tokens geram números no curto prazo, mas transformam os resistentes em pessoas que usam só para aparecer. A adoção real exige segurança psicológica e investimento em treinamento — uma regra básica para introdução de qualquer nova tecnologia, não exclusiva da IA.

Q3. Isso vale fora da engenharia (vendas, marketing)?

Ainda mais. Os resultados de vendas e marketing são qualitativos e difíceis de medir, então líderes recorrem a métricas superficiais como "número de propostas redigidas por IA" ou "consultas disparadas ao ChatGPT". O que você deveria medir, em vez disso: taxa de fechamento, satisfação do cliente, lead time — métricas de resultado que já existiam antes da IA.

Q4. Como meço DORA para a minha equipe?

Ferramentas gratuitas funcionam. GitHub Insights, Jellyfish, LinearB, Faros AI. O site oficial do Google dora.dev tem benchmarks e explicações. Agregação manual está ótima no início — só comparar trimestre a trimestre já revela se a IA está produzindo valor real.

Q5. "Consumo de tokens = produção de trabalho" está completamente errado?

Não está completamente errado. Como indicador macro da atividade geral de IA na organização, é útil. "Não estar sendo usada" é um sinal real. O problema é usá-lo para avaliação individual, KPIs ou cotas. OK como observação macro, NÃO OK como avaliação micro individual — mantenha esses usos separados.