O meu feed do LinkedIn está cheio disso há semanas. A minha linha de tempo do X também. Pessoas a publicar capturas de ecrã de gastos com tokens como se fossem relatórios de progresso. Fundadores de startups a gabarem-se de terem gasto 16 mil dólares em Claude Code no mês passado e de terem como objetivo os próximos 60 mil dólares. Tabelas de classificação. Rankings. Títulos como "Lenda do Token" e "Deus da IA".
E então, na semana passada, atingiu a massa crítica. A Forbes noticiou o movimento "tokenmaxxing" que está a varrer o Vale do Silício, onde as empresas competem para ver quem queima mais tokens de IA. Jensen Huang foi ao podcast All-In e disse: "Aquele engenheiro de 500 mil dólares, no final do ano, vou perguntar-lhe: 'Quanto gastaste em tokens? Se essa pessoa disser '$5.000', eu vou-me passar. Se esse engenheiro de 500.000 dólares não consumiu pelo menos 250.000 dólares em fichas, vou ficar profundamente alarmado."
Depois, a [Fortune noticiou] (https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/) que um funcionário da Meta tinha criado uma tabela de classificação interna chamada "Claudeonomics", que monitorizava o consumo de tokens pelos mais de 85.000 funcionários da empresa. Os melhores utilizadores recebiam títulos. Num período de 30 dias, o consumo total atingiu 60 biliões de tokens. O melhor utilizador individual teve uma média de 281 mil milhões. Mark Zuckerberg nem sequer entrou no top 250. Enquanto isso, o CTO da Meta, Andrew Bosworth, dizia publicamente que seu melhor engenheiro estava gastando seu salário equivalente em tokens, mas funcionando "5x a 10x mais produtivo". "É como se fosse dinheiro fácil", disse Bosworth. "Sem limite."
Já trabalho com software há tempo suficiente para perceber o que está a acontecer aqui. Isto são "linhas de código" com um preço muito mais elevado.
Já estivemos aqui antes
Em 2003, Martin Fowler escreveu [um pequeno artigo sobre por que a produtividade de software não pode ser medida] (https://martinfowler.com/bliki/CannotMeasureProductivity.html) que provavelmente deveria ser leitura obrigatória para todos os executivos técnicos. O seu argumento sobre as linhas de código era preciso:
"Uma das minhas maiores irritações são os estudos de produtividade baseados em linhas de código. Qualquer bom programador sabe que pode codificar as mesmas coisas com grandes variações nas linhas de código."
O problema é óbvio quando o dizemos em voz alta. O LOC mede a atividade, não a produção. Dois programadores podem construir a mesma funcionalidade: um escreve 1.200 linhas, o outro escreve 80. O mais conciso provavelmente construiu um sistema melhor. Sob um regime de LOC, o verboso parece mais produtivo.
As equipas avaliadas com base no LOC responderam de forma racional. Escreveram mais linhas. Copiaram e colaram em vez de abstrair. Evitaram refactoring porque a eliminação de código prejudicaria os seus números. A métrica moldou o comportamento, mas não em direção a um software melhor. Mais código. Sistemas piores.
Então, em 2023, a McKinsey publicou um artigo afirmando ter descoberto a medição objetiva da produtividade dos programadores. A resposta completa de Gergely Orosz e Kent Beck apontou a mesma falha: quase todas as métricas da McKinsey estavam medindo esforço e produção, não resultados. Kent Beck contou como os inquéritos internos do Facebook sobre o sentimento dos programadores deixaram de ser um feedback útil e passaram a ser negociados pelos gestores com os engenheiros para obterem pontuações mais elevadas. É isso que acontece quando se incentiva uma métrica proxy. O número melhora. A coisa que realmente importava não melhora.
Seria de esperar que tivéssemos aprendido. Mas não aprendemos.
O mesmo erro, unidade diferente
A lógica sedutora do tokenmaxxing é assim. Consumo de fichas = uso de IA. Mais uso de IA = as equipas estão a usar IA. Portanto, alto gasto de token = alta adoção de IA = bom.
É precisamente tão falho quanto medir linhas de código, apenas com um painel de faturamento em vez de um gráfico de confirmação. E para ser justo com o artigo da Forbes, o CEO da Sendbird, John Kim, basicamente disse exatamente isso: "Já vimos este filme antes". Ele estava a referir-se à cultura LOC dos anos 90 e 2000. O verdadeiro indicador, observou ele, é a quantidade de código gerado por IA que realmente entra em produção. Os gastos com tokens "são mais para iniciar uma conversa". Eu concordo com isso. Torna-se um problema quando o início da conversa é promovido ao KPI principal.
[Pesquisa de desenvolvedor 2024 do GitHub] (https://github.blog/news-insights/research/survey-ai-wave-grows/) descobriu que 97% dos desenvolvedores corporativos usaram ferramentas de codificação de IA no trabalho em algum momento. A adoção organizacional significativa, no entanto, exigiu políticas claras, fluxos de trabalho e resultados mensuráveis vinculados aos resultados reais do negócio. Não apenas uso. Não apenas consumo.
Boris Cherny, o engenheiro por trás do Claude Code, [compartilhou publicamente] (https://x.com/bcherny/status/2004626064187031831) que ele não abriu um IDE durante um mês de trabalho, com o Opus 4.5 escrevendo cerca de 200 PRs. Isso é impressionante. Mas o que o torna impressionante não são os tokens que esses 200 PRs consumiram. O que torna isso impressionante não são os tokens que esses 200 PRs consumiram, mas sim o facto de serem 200 contribuições reais com software a funcionar do outro lado.
O valor está no resultado. Os tokens são a energia que o levou até lá, nada mais.
Quando a métrica se torna o objetivo
Existe um princípio chamado Lei de Goodhart: quando uma medida se torna um alvo, ela deixa de ser uma boa medida. A história do desenvolvimento de software é basicamente um museu da Lei de Goodhart em ação.
O rastreamento de tokens como um KPI de adoção de IA estabelece exatamente a mesma dinâmica. As equipas de engenharia medidas pelo consumo de tokens irão consumir mais tokens. É assim que os incentivos funcionam. Quer parecer mais produtivo? Execute mais alguns loops agênticos. Deixe o modelo raciocinar longamente antes de gerar resultados. Envolva cada tarefa em uma camada de orquestração que chama quatro ferramentas onde uma seria suficiente. O gasto de fichas aumenta. O valor entregue não aumenta.
Na verdade, a história da Claudeonomics provou-o quase imediatamente. A Fortune observou que "alguns funcionários colocaram agentes de IA a trabalhar durante horas para maximizar a utilização de tokens". Aí está. A Lei de Goodhart a ser executada em tempo real, dentro de uma empresa que é suposto estar na fronteira da produtividade impulsionada pela IA. A tabela de classificação estava no ar há talvez algumas semanas antes de ser encerrada, e os funcionários já a estavam a manipular, executando agentes em loops. A métrica tinha três semanas e já tinha deixado de medir o que era suposto medir.
Qualquer programador que esteja a ler isto pode provavelmente pensar em cinco formas de inflacionar as métricas de utilização de tokens sem qualquer benefício para ninguém. Eu não vou listá-las. Mas se eu consigo pensar em cinco, os engenheiros que estão a ser medidos também conseguem.
Andrej Karpathy descreveu [o momento atual da engenharia de software] (https://x.com/karpathy/status/2004607146781278521) como um "terramoto de magnitude 9" para a profissão. Ele tem razão. Mas os terramotos não se medem pela eletricidade consumida. Eles são medidos pelo que se moveu.
A versão documental deste problema
Este não é apenas um problema para as equipas de engenharia. Vejo a mesma dinâmica na gestão do conhecimento, que está muito mais perto de nós na Rasepi.
"Publicámos 400 documentos este trimestre" é um número que soa bem numa apresentação de diapositivos. Não tem nada a dizer sobre se esses documentos são exactos, se alguém os leu ou se a informação neles contida ainda é verdadeira seis meses depois. É possível atingir esse número com IA e sem qualquer tipo de raciocínio. Ruído assistido por tokens publicado em grande escala.
A métrica honesta é mais difícil de recolher, mas muito mais útil: que percentagem da sua base de conhecimentos reflecte realmente a forma como os seus sistemas funcionam atualmente? Quantas pessoas chegaram a uma resposta correta utilizando a sua documentação? Quantas tentaram, falharam e acabaram por perguntar a alguém no Slack?
Essas perguntas ainda não têm painéis de controle bonitos. Elas exigem uma reflexão real sobre o que você deseja que a documentação faça pela sua organização. (Este é, não por coincidência, exatamente o problema em torno do qual o Rasepi foi construído. As datas de expiração forçadas existem precisamente para que as equipas tenham de avaliar se o conteúdo ainda é válido, em vez de o deixarem decair silenciosamente por detrás de uma métrica de elevado número de páginas).
O que acompanhar em vez disso
A resposta honesta a "o nosso investimento em IA está a compensar?" não pode ser lida a partir de um painel de faturação.
É possível aproximá-la com perguntas melhores: os tempos de ciclo estão a melhorar? O rácio entre as funcionalidades enviadas e os bugs reportados está a evoluir na direção certa? Os engenheiros estão a reportar que passam mais tempo a fazer trabalho de avaliação e menos a escrever? A sua documentação está a manter-se actualizada em vez de se acumular como sedimentos?
Estes são dados mais difíceis de extrair de uma API. Requerem uma reflexão sobre os resultados que se pretende obter das equipas, o que, reconhecidamente, é o trabalho mais difícil. Mas são as perguntas que interessam, porque têm a ver com resultados e não com entradas.
O gasto com tokens diz-lhe a quantidade de computação que comprou. Se esse computador se transformou em algo útil é uma questão totalmente diferente. As empresas que não fazem essa distinção vão construir painéis de controlo muito caros que não lhes mostram quase nada.
Passámos anos a otimizar a métrica errada para a produtividade dos programadores. Temos talvez um trimestre antes que o mesmo erro seja incorporado em todos os relatórios de adoção de IA na empresa. A janela para evitar isso está aberta, mas não vai continuar assim.