Amazon Mandou Engenheiros Pararem De Tokenmaxxing: Por Que Consumo De IA É Uma Métrica Ruim

Existe um tipo de reunião que eu aprendi a olhar com desconfiança: aquela em que alguém abre um painel de adoção de IA e a conversa inteira gira em torno de uma curva subindo. Tokens por semana, número de sugestões aceitas, linhas geradas por pessoa. O gráfico é bonito, a seta aponta para cima, e todo mundo na sala sente que algo está dando certo. Eu também sinto, por uns dez segundos. Depois vem a pergunta que ninguém faz em voz alta: certo para quê?

Essa pergunta me acompanhou durante a leitura da notícia desta semana. A Amazon, segundo a cobertura que li, circulou internamente um memo dizendo que contar tokens e linhas de código geradas é uma forma profundamente falha de medir adoção de IA. A razão é quase banal quando se escreve por extenso: se você premia o consumo, as pessoas consomem. O gesto de uma empresa desse tamanho dizer isso por escrito é mais interessante do que a conclusão em si, porque quase todo time de engenharia que conheço, ou já olhou para um painel desses, ou já foi cobrado por um.

Antes de qualquer opinião, a transparência de sempre. Não li o memo. Não li a reportagem original da CNBC. O que sei vem de resumos: o AI Weekly, que descreve a matéria da CNBC de 27 de outubro de 2026, e uma live da Fox News de 28 de outubro. Tudo o que atribuo à Amazon neste texto passa por essas camadas, e vou dizer onde isso importa. Quando eu estiver opinando, é opinião minha; quando imaginar um time, vou rotular como cenário hipotético.

O caminho é este. Primeiro, o que o memo diz e o que a cobertura não permite saber. Depois, por que tokens e linhas medem insumo e não resultado. Em seguida, o episódio do ranking manipulado e o que a Lei de Goodhart tem a ver com ele, uma proposta de o que medir no lugar, o exemplo de números da Anthropic que ajuda a separar métrica de volume de métrica de resultado, e um cenário hipotético de um time com meta de adoção.

O Que O Memo Diz E O Que Não Sabemos

Pelo que o AI Weekly resume, o memo foi circulado dentro da Amazon em setembro e se tornou público em 27 de outubro de 2026, no mesmo dia da reportagem da CNBC. O núcleo do texto, como chega até mim, é a crítica a duas métricas específicas: o volume de tokens consumidos e o volume de linhas de código geradas por IA. Ambas são descritas como "deeply flawed", profundamente falhas, para medir adoção, e o motivo apontado é que elas incentivam engenheiros a maximizar o consumo de tokens. A Fox News, na live de 28 de outubro, resume na mesma linha: o memo pede que engenheiros parem de "tokenmaxxing" e usem IA com mais critério.

A orientação que acompanha a crítica, ainda segundo o AI Weekly, tem duas partes. Uma é usar IA de forma seletiva, o que já é uma mudança de tom em relação ao "use mais" que domina a conversa do setor. A outra é medir sucesso por resultados de longo prazo para o cliente e para o negócio. O perfil ideal descrito é o que o texto chama de "Renaissance Developer", alguém que combina IA com bom julgamento. Não sei o que o memo diz em detalhe sobre esse perfil, e não vou inventar uma definição; o que consigo afirmar é que a ênfase está no julgamento de quem usa, não no volume que usa.

Há ainda dois fatos de contexto que o resumo traz. O primeiro é que a Amazon desligou em maio um ranking interno de uso de tokens, depois de constatar que funcionários estavam manipulando a classificação. O segundo é que a empresa afirma não ter imposto um teto de gasto de tokens por engenheiro. Esse segundo ponto merece cuidado: é a posição declarada da empresa, e o que a cobertura resume não me permite verificar se ela vale para todas as equipes, nem como o consumo era acompanhado no dia a dia.

O que eu não sei é bastante coisa. Não sei se o memo é uma diretriz formal ou um texto de orientação, não sei a quem ele se dirige exatamente, não sei se vem acompanhado de métricas alternativas oficiais, e não sei como a mudança será aplicada nas equipes. Também não sei se a decisão de tornar o memo público foi da própria Amazon ou se o texto vazou para a imprensa; o resumo que li o trata como publicado, e é assim que repito. Leituras complementares como a do FourWeekMBA e a do DEV Community tratam do mesmo assunto, mas só as vi como resultado de busca, então não atribuo a elas nenhum número ou detalhe.

Por Que Tokens E Linhas Medem Insumo

Em qualquer processo produtivo, vale separar insumo de produto. Insumo é o que você coloca para dentro: horas, dinheiro, matéria-prima, e aqui tokens consumidos. Produto é o que sai do outro lado: uma funcionalidade que o cliente usa, um incidente que não aconteceu, um prazo que foi cumprido. Métricas de insumo são fáceis de coletar, porque o sistema já registra, e isso explica o apelo. Um provedor de modelo entrega um dashboard de tokens por usuário sem esforço nenhum. Medir se o código gerado reduziu o tempo até o cliente receber valor dá bem mais trabalho.

O problema é que o insumo só diz algo sobre o resultado quando a relação entre os dois é estável e conhecida. Numa fábrica com processo calibrado, mais matéria-prima processada costuma significar mais peças. Em desenvolvimento de software essa relação é frouxa, e com IA fica mais frouxa ainda. Um engenheiro pode gastar muitos tokens porque está explorando um problema difícil, e outro pode gastar muitos porque ficou rodando um agente em círculos. Do lado de fora do painel, os dois números são iguais. Quem consome pouco pode estar fazendo um trabalho cirúrgico, ou pode estar evitando a ferramenta. O número sozinho não distingue nenhum desses casos.

Com linhas de código geradas o raciocínio é o mesmo, com um agravante conhecido de quem trabalha com software há tempo: linhas de código nunca foram boa medida de produtividade, e a IA só tornou isso mais evidente, porque gerar linhas ficou praticamente de graça. Se produzir código custa quase nada, o volume deixa de sinalizar esforço, e o que sobra é a pergunta de quem vai ler, revisar, testar e manter tudo aquilo. Em muitos casos, a melhor contribuição de uma pessoa é um diff que apaga código. Uma métrica de linhas geradas trata esse diff como se fosse ausência de trabalho.

Há também um efeito sobre a qualidade do uso. Quando a medida é consumo, o incentivo é usar a IA para tudo, inclusive para o que ela faz mal ou para o que levaria menos tempo à mão. O memo, como chega até mim, pede o contrário: seletividade. Isso me parece correto por um motivo prático. A decisão mais valiosa no uso de um agente muitas vezes é a de não usá-lo, ou de usá-lo com um escopo pequeno e bem definido. Uma métrica de adoção que só sobe quando o uso aumenta pune justamente o julgamento que se quer estimular.

Já escrevi sobre uma versão desse problema ao falar de como acompanhar tokens em produção e controlar custo de IA. Lá, o consumo era uma grandeza de custo, algo a observar e otimizar, e nesse papel ele é perfeitamente legítimo. O erro que o memo da Amazon aponta é de categoria: pegar uma grandeza de custo e tratá-la como indicador de valor. Token é uma conta que se paga, não uma medalha que se ganha. Quem coloca o consumo no lugar do resultado acaba, sem querer, pedindo que a equipe gaste mais.

O Leaderboard Manipulado E A Lei De Goodhart

O detalhe da notícia que mais me chamou a atenção não é o memo, é o ranking desligado em maio. Pelo que o AI Weekly resume, a Amazon manteve uma classificação interna de uso de tokens e a desligou depois de perceber que funcionários estavam manipulando o resultado. A cobertura que li não detalha como a manipulação acontecia, e não vou especular sobre isso. O que importa é o desfecho: a empresa observou o comportamento, concluiu que o placar estava distorcendo o que media, e retirou o placar.

Esse é o roteiro clássico do que se costuma chamar de Lei de Goodhart: quando uma medida vira meta, ela deixa de ser uma boa medida. O mecanismo é fácil de explicar. Uma métrica funciona como indicador enquanto as pessoas não sabem que estão sendo avaliadas por ela, ou não têm motivo para mexer nela. Assim que o número passa a determinar reconhecimento, promoção ou simples constrangimento em público, o comportamento se ajusta ao número, e a relação original entre o número e a coisa que ele representava se rompe. O token consumido deixa de ser um sintoma de trabalho intenso e passa a ser o próprio objetivo.

Vale notar que não é preciso má-fé para isso acontecer. Mesmo uma equipe de pessoas honestas responde a incentivos, e o ranking é um incentivo explícito. Quem aparece no fim da lista tende a achar que precisa usar mais, e quem aparece no topo não quer cair. Ninguém precisa decidir fraudar nada; basta que um grupo de gente razoável tente ficar bem na foto. Que a manipulação tenha aparecido, segundo o resumo, em uma empresa com a escala e a cultura de medição da Amazon sugere que o fenômeno não é exótico, é o resultado esperado quando se mede insumo e se expõe o placar.

Para quem lidera times, a lição prática é que o problema não está só em escolher a métrica errada, está em escolher a forma de usá-la. Uma métrica de insumo tem lugar legítimo como sinal de diagnóstico: se ninguém no time toca a ferramenta, vale perguntar por quê, e a resposta pode ser falta de treinamento, de acesso ou de confiança. O que não funciona é transformar esse sinal em placar e depois se surpreender com o placar sendo jogado. Eu discuti uma ideia parecida em um texto sobre métricas além do DORA e o paradoxo da produtividade com IA, onde o ponto central também era que uma métrica isolada conta uma história confortável e incompleta.

O Que Medir No Lugar

Dizer que tokens e linhas são ruins é a parte fácil. A parte difícil é propor algo que preste, e aqui sou deliberadamente cuidadoso: não vou inventar números nem benchmarks, porque a notícia não traz nenhum e não existe um conjunto único correto. O que consigo oferecer é um critério e algumas famílias de sinais, todos do lado do resultado.

O critério é simples: prefira medidas que seriam piores se o código gerado fosse ruim. Linhas geradas não pioram quando o código é ruim, aliás até aumentam. Já o retrabalho piora, os reverts pioram, o tempo de correção de defeitos em produção piora. Por isso a primeira família que eu olharia é a de estabilidade e retrabalho: com que frequência uma mudança precisa ser desfeita ou corrigida logo depois de entrar. Falei disso em um post sobre DORA, retrabalho e produtividade com IA, e continuo achando que o retrabalho é um dos poucos sinais que a IA não consegue inflar sem custo visível.

A segunda família é de fluxo: quanto tempo leva entre a ideia e a mudança em produção, medido de ponta a ponta, não só a etapa de escrever código. Se a IA acelera a escrita e a revisão vira gargalo, o fluxo total não melhora, e uma métrica de fluxo mostra isso, enquanto uma de linhas geradas comemora. A terceira é de qualidade percebida: incidentes, bugs reportados por clientes, satisfação de quem usa o produto. A quarta, mais difícil de capturar, é a compreensão que o time mantém do próprio sistema, tema que explorei ao discutir dívida cognitiva e compreensão de código gerado por IA.

Pergunta	Métrica de insumo (cuidado)	Métrica de resultado (prefira)
A IA está sendo usada?	Tokens consumidos, sugestões aceitas	Em quais tarefas ela entra no fluxo e se o resultado dessas tarefas melhorou
A IA acelera a entrega?	Linhas ou PRs gerados	Tempo de ponta a ponta até produção
O que entra é bom?	Volume de código produzido	Reverts, retrabalho, defeitos que escapam
O time entende o que entrega?	Cobertura de uso da ferramenta	Tempo de diagnóstico de incidentes, facilidade de onboarding

Nenhuma dessas medidas é perfeita, e todas também sofrem da Lei de Goodhart se virarem placar. Um time pressionado a reduzir reverts pode passar a revisar menos mudanças arriscadas, ou a evitar tocar em código difícil. A defesa não é achar a métrica incorruptível, é usar um conjunto pequeno de sinais que se contrabalançam, olhar tendência em vez de ranking individual e tratar o número como ponto de partida para uma conversa, não como veredito.

Volume Versus Resultado No Relato Da Anthropic

Um exemplo ajuda a separar os dois tipos de métrica, e ele vem de outra empresa. Segundo o OrcaRouter, em um resumo das novidades da Anthropic em outubro de 2026, a equipe do Claude Code afirma que o Claude escreve cerca de 90% do código do próprio Claude Code. A mesma fonte relata que os pull requests mergeados mais que dobraram entre junho e setembro e que os reverts caíram mais de 40%. Preciso ser claro: são números da própria equipe, relatados por um terceiro, sem auditoria independente, e eu não verifiquei nenhum deles. Uso-os aqui como ilustração do tipo de métrica, não como prova de nada.

Olhe para a estrutura do relato, não para os valores. A parcela do código escrita pelo Claude é uma métrica de volume, parente próxima das linhas geradas que o memo da Amazon critica. Dizer que uma ferramenta escreve a maior parte do código diz que ela está sendo muito usada, mas não diz se o resultado é bom. Já a queda de reverts é uma métrica de resultado: ela só melhora se menos mudanças voltam atrás, e portanto carrega alguma informação sobre qualidade. A diferença entre as duas é exatamente a que o memo, segundo o resumo, tenta fazer o leitor enxergar.

Mesmo a métrica de resultado do relato tem limites que vale registrar. Reverts caindo pode significar mudanças melhores, mas também pode significar revisão mais tolerante, ou menos disposição de desfazer algo problemático, ou uma mudança no perfil do que está sendo entregue. Por isso eu desconfio de uma métrica sozinha, mesmo a boa. O PR mergeado dobrando é, ele mesmo, um número de volume, e só ganha sentido ao lado de um sinal de estabilidade. O relato junta os dois, o que é um bom hábito, ainda que a fonte seja a própria equipe falando de si.

O ponto que eu tiraria disso para quem lidera um time é prático. Quando um fornecedor ou um colega apresentar um número de impacto da IA, vale perguntar de que lado da fronteira ele está. "Geramos X por cento do código" é insumo. "Os incidentes caíram" ou "o tempo até produção diminuiu" é resultado.

Um Time Com Meta De Adoção: Cenário Hipotético

Para deixar concreto, imagine um time hipotético de dez pessoas cuja liderança recebeu uma meta de adoção de IA. A meta, no formato mais comum, é um percentual de engenheiros usando a ferramenta toda semana e um volume mínimo de tokens por pessoa. A diretoria acompanha um painel com a posição de cada time. Nada disso é absurdo, e eu consigo entender como uma meta assim nasce: é a única coisa que o sistema consegue medir sem esforço.

Nas primeiras semanas, o painel sobe. Um engenheiro, vendo que está abaixo da média, começa a rodar o agente em tarefas pequenas que faria à mão mais rápido. Outro percebe que pedir ao agente que explique arquivos longos consome muitos tokens e passa a fazer isso por reflexo. Uma terceira pessoa, mais cética, aceita sugestões que não usa só para manter o número. Ninguém está fraudando coisa alguma; todos estão respondendo ao painel. Em dois meses, o time bate a meta com folga e a liderança comemora um relatório que não diz nada sobre se as entregas melhoraram.

Agora imagine o mesmo time com um acordo diferente. A liderança diz que a adoção será observada como diagnóstico, não cobrada como meta, e escolhe três sinais de resultado para acompanhar em conjunto: tempo de ponta a ponta até produção, frequência de retrabalho e reverts, e incidentes ligados a mudanças recentes. Pede que cada pessoa registre, de vez em quando, onde a IA ajudou e onde atrapalhou. Esse registro é qualitativo, imperfeito e trabalhoso, mas cria um incentivo diferente: o que é recompensado é a decisão certa sobre quando usar a ferramenta. Esse segundo cenário não garante melhores resultados, e eu não afirmo que garanta. Mas ele remove o incentivo que o memo da Amazon, pelo que chega a mim, quer remover.

Há um custo humano nesse desenho que quase nunca aparece no painel. Times cobrados por consumo tendem a sentir que o trabalho é demonstrar uso, e não resolver problemas, o que é cansativo de um jeito diferente do cansaço de entregar muito. Tratei de um aspecto próximo no texto sobre burnout e gestão de agentes de IA para tech leads, onde a carga de supervisionar saída de IA já era um peso por si só. Somar a isso uma cobrança de volume parece-me a receita para um time exausto produzindo números que ninguém usa.

Conclusão

O que me parece mais valioso na notícia da Amazon não é a Amazon, é o princípio: não confunda o que você gastou com o que você conseguiu. Tokens consumidos são uma conta; linhas geradas são um volume; nenhum dos dois é resultado. Pelo que li, o memo diz isso com todas as letras e acompanha a crítica de uma orientação razoável, usar IA com seletividade e medir o sucesso por efeito de longo prazo no cliente e no negócio. Eu assino embaixo da lógica, ainda que não tenha lido o texto original.

Também preciso repetir os limites do que sei. Trabalho com resumos: o AI Weekly sobre a reportagem da CNBC e a live da Fox News. Não sei como o memo será aplicado dentro da empresa, não sei se há métricas alternativas oficiais, e a afirmação de que não há teto de tokens por engenheiro é a posição declarada da Amazon, não algo que eu possa conferir. Os números da Anthropic são da própria equipe e vêm por um terceiro. Se você for citar qualquer coisa deste texto numa conversa com sua diretoria, vale ir às fontes primárias antes.

Minha posição, no fim, é menos categórica do que o título sugere. Métricas de uso não são inúteis: servem para descobrir quem não está conseguindo usar a ferramenta e por quê. O que me parece um erro é promovê-las a objetivo. A saída não é um número melhor e incorruptível, porque ele não existe, e sim um conjunto pequeno de sinais de resultado, lidos com humildade e acompanhados de conversa. Não tenho certeza de que a maioria dos times vai resistir à tentação do painel bonito. Eu mesmo, por uns dez segundos, não resisto.

Fontes:

Amazon Mandou Engenheiros Pararem De Tokenmaxxing: Por Que Consumo De IA É Uma Métrica Ruim

Amazon Mandou Engenheiros Pararem De Tokenmaxxing: Por Que Consumo De IA É Uma Métrica Ruim

O Que O Memo Diz E O Que Não Sabemos

Por Que Tokens E Linhas Medem Insumo

O Leaderboard Manipulado E A Lei De Goodhart

O Que Medir No Lugar

Volume Versus Resultado No Relato Da Anthropic

Um Time Com Meta De Adoção: Cenário Hipotético

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose