Tokens não são moeda. São linhas de código com fatura anexada.

A Nisha Talagala publicou na Forbes um primer sobre tokens em que defende que os tokens — a unidade de custo e medição do consumo de LLMs — estão a tornar-se uma moeda de negócio fundacional. Introduz o termo tokenmaxxing, sinaliza que já há empresas a avaliar publicamente os funcionários por uso de tokens e propõe um quadro tranquilo de orçamentos, tracking e trade-offs. Como primer, está bem. Como roadmap para uma organização de engenharia que tenha de entregar sob orçamento, é a versão mais educada de uma ideia muito perigosa.

A ideia perigosa: que o uso de tokens mede trabalho. Não mede. Mede fatura. Do lugar de alguém que já teve de defender uma rubrica de custo de IA frente a um CFO e a uma rotação SRE na mesma semana, o enquadramento importa mais do que os números — e a Forbes só acerta em metade.

O que a Forbes acerta

Três coisas no artigo estão corretas e deveriam já estar no roadmap de qualquer CTO:

1. O gasto em tokens é real e cresce. O artigo cita que uma simples revisão de email consome ~100 tokens, com um custo de cerca de 0,25 cêntimos de dólar por tarefa. Multiplica isso por cada funcionário, cada workflow, cada retry, cada agente encadeado — e a rubrica passa de "erro de arredondamento" a "negociar com o CFO" num trimestre. As empresas que arrancaram a dar tokens ilimitados aos funcionários estão, previsivelmente, a racionar.
2. Nem todos os tokens são iguais. A Forbes acerta: um token não é comparável entre fornecedores, modelos, tarefas e épocas. Um token de um modelo de reasoning de fronteira não é comercialmente equivalente a um token de um pequeno modelo open-weights, mesmo que a contabilidade os queira somar.
3. É preciso tooling. O tracking de tokens vai gerar a mesma onda de fornecedores que o custo de cloud há uma década: um mercado de FinOps para tokens. Esse mercado já se está a formar.

Essas três observações chegariam para justificar o artigo. O problema é a quarta ideia que lhe colaram em cima.

Onde a Forbes erra: o token como proxy de produtividade

O artigo descreve — com pouco espírito crítico — uma tendência em que as empresas tratam tokens por funcionário por unidade de tempo como métrica de produtividade. Chega a fazer a analogia com o orçamento de viagens de um comercial: o funcionário que sub-consome o orçamento de tokens equivale, nesse quadro, ao comercial que não marca visitas. Gastar menos passa a ser sinal negativo.

Isto é a Lei de Goodhart com fato novo. Quando uma medida se torna um objetivo, deixa de ser uma boa medida. No dia em que dizes aos engenheiros que o uso de tokens é avaliado — formalmente, pela gestão, com peso na performance review — não mediste nada sobre produtividade. Criaste um novo mercado de ruído.

A Forbes admite o vetor de abuso ("os tokens são triviais de abusar") mas trata-o como um problema de higiene gerível. Não é. A história das métricas de engenharia é exatamente a história deste modo de falha:

• Linhas de código por programador. Medidas durante duas décadas. Otimizadas escrevendo mais linhas. Prémio: bases de código Fortran 77 que nenhum humano conseguia manter. A coisa medida — valor criado — descorrelacionou-se e depois anti-correlacionou-se com a métrica. Já defendi este mesmo argumento sobre métricas de produtividade e a mecânica é idêntica.
• Tickets fechados por sprint. Otimizado partindo tickets. Ou fechando os triviais primeiro. Ou inflacionando o sprint. As equipas que melhor gameavam a métrica eram as piores a entregar.
• Cobertura de testes. Otimizada escrevendo testes que executam linhas sem afirmar comportamento. A cobertura subia, os defeitos subiam, os engenheiros eram promovidos.

"Tokens consumidos por funcionário por mês" cabe nesta linhagem. E é pior, porque cada token gameado custa dinheiro real a um fornecedor real. As métricas de vaidade clássicas gameavam-se de graça. O tokenmaxxing é gaming pago, com a fatura encaminhada para finanças.

A medida honesta é mais difícil, e não são tokens

O que realmente queres saber sobre um engenheiro a usar ferramentas de IA é, grosso modo:

• A alteração foi entregue?
• Foi entregue corretamente?
• Foi entregue mais depressa do que sem a ferramenta?
• O engenheiro aprendeu algo reutilizável, ou subcontratou o pensamento?
• O código resultante é revisível, mantível e owned?

Nenhum dos cinco se mede em tokens. Os quatro primeiros medem-se com métricas DORA honestas — frequência de deploy, lead time, change failure rate, MTTR. O quinto só se mede com code review e tempo. Não há atalho, e os tokens não são o atalho disfarçado.

A Forbes acena com a frase "infuse the AI force multiplier" — a ideia de que é a perícia humana que dá valor ao token. De acordo. Mas essa concessão desmonta todo o enquadramento token-budget-as-produtividade que está ao lado. Se o multiplicador é o humano, a unidade relevante é resultado por engenheiro, não tokens por engenheiro. O gasto em tokens é um custo de entrada, como cloud, eletricidade ou escritório — e ninguém é promovido por ter gasto mais em eletricidade.

O que os tokens são realmente: uma rubrica de cloud com piores defaults

Se tiras o erro métrica-de-produtividade, o que sobra é correto e vale a pena gerir bem. Os tokens entram na mesma curva de maturidade do gasto em cloud, e o playbook da década FinOps aplica-se quase sem alterações:

1. Atribui o gasto a resultados, não a pessoas. Um token consumido por um agente de CI que apanha uma regressão em produção não é comparável com um token consumido por um engenheiro a pedir a um LLM para reformular um Slack. Etiqueta os tokens por workflow, não por funcionário — como etiquetavas as EC2 por serviço, não pela pessoa que as lançou.
2. Põe quotas por rota, não por pessoa. O overrun interessante numa organização com IA raramente é um funcionário falador. É um agente runaway numa pipeline a chamar um modelo de fronteira em loop com retry-with-backoff. Os orçamentos por funcionário não o apanham. Os orçamentos por ferramenta e por fluxo sim, como os orçamentos por serviço apanharam a lambda que fazia 3.000 leituras a Aurora às 3 da manhã.
3. Arbitra preço entre modelos. A Forbes acerta: vendedores e preços flutuam; a resposta correta é uma camada de routing que envia cada tarefa ao modelo mais barato que cumpre o nível de qualidade para essa tarefa — não um contrato fixo com um único fornecedor de fronteira a preço de tabela. A economia dos modelos de fundação premia decisões build-vs-buy por carga, não padronizar no mais caro.
4. Observabilidade antes de incentivos. A maioria das organizações está prestes a tomar decisões de política sobre tokens antes de ter atribuição fiável por tarefa. A ordem está errada. Resolve primeiro a atribuição — por serviço, por fluxo, por retry, por resultado para o utilizador — e depois fala em orçamentos. Caso contrário, vais pôr quotas sobre ruído.

Isto é FinOps com outra unidade. Não é, e não devia ser, performance management.

O que o "tokenmaxxing" diz mesmo de uma organização

Se uma organização de engenharia se vê a premiar o consumo de tokens — ou pior, encontra os seus engenheiros a gamear o consumo para parecerem produtivos — o problema não é dos engenheiros. É da liderança que escolheu a métrica. O tokenmaxxing é um sintoma, e a doença de fundo é a mesma que vejo em todos os clientes que não construíram uma cultura de medição real: a gestão quer um número único, as finanças querem um número único, e a fatura do LLM dá convenientemente um número único que sobe.

Uma organização de engenharia a sério resiste a essa compressão. Corre, no mínimo, dois streams em paralelo:

• Stream de custo. Quanto gastámos em IA, partido por workflow, por equipa, por modelo, por modo de retry? Onde está o desperdício? O router está a fazer o seu trabalho? Há agentes em loop?
• Stream de resultado. O que foi entregue? O que não foi? Qual é o change failure rate? As PRs assistidas por IA têm um perfil de defeitos diferente das não-assistidas? A IA apanha mais incidentes do que provoca?

Se só corres o stream de custo, vais otimizar o consumo de tokens — e a Forbes está a descrever corretamente o tipo de empresa em que te vais transformar. Se só corres o stream de resultado, não vais apanhar o agente runaway que pôs fogo à fatura AWS. Precisas dos dois, em dashboards distintos revistos por pessoas distintas.

O que poria à frente de um CTO este trimestre

1. Atribuição por fluxo antes de orçamentos por funcionário. Enquanto não conseguires nomear os cinco workflows que mais tokens consomem no teu stack, não tens um problema de tokens que possas resolver.
2. Um kill-switch por agente, o mesmo que defendo como inegociável para qualquer sistema agêntico em produção. Um loop infinito num agente é hoje um incidente financeiro tanto como um incidente SRE.
3. Uma camada de routing de modelos, mesmo que rudimentar. Se todas as equipas chamam direto ao mesmo modelo de fronteira sem fallback a níveis mais baratos para tarefas triviais, a tua fatura está a pagar preguiça de plataforma, não produtividade dos engenheiros.
4. Uma política de medição que exclua explicitamente os tokens da avaliação individual. Por escrito. E em voz alta. No primeiro dia em que um gestor elogiar um engenheiro por ter "consumido mais tokens este trimestre", a métrica está morta e a cultura vai atrás.
5. Uma rubrica orçamental para desperdício. Uma parte do gasto em tokens vai ser exploratória, beco sem saída e irredutivelmente experimental. Está bem. Dá um nome a essa rubrica, orçamenta-a e para de tentar otimizá-la a zero. É também onde acontece a maior parte da aprendizagem.

A linha que traço

A Forbes acerta: os tokens são hoje uma rubrica real que as empresas têm de planear, seguir e governar. A Forbes erra — ou no mínimo é perigosamente casual — quando estende essa rubrica até a transformar em métrica de produtividade individual. O primeiro é FinOps. O segundo é o erro linhas-de-código reeditado com uma fatura de fornecedor colada.

As empresas que navegarem bem os próximos dois anos serão as que tratarem os tokens com a mesma disciplina aborrecida que (finalmente) aprenderam a aplicar à cloud: atribuir gasto a resultados, encaminhar trabalho para o modelo mais barato que basta, observar antes de incentivar, e nunca — nunca — promover um engenheiro por consumir mais do input.

Os tokens são o custo. O engenheiro é o multiplicador. Se as tuas métricas confundem os dois, não tens estratégia de IA. Tens uma fatura de IA.

---

Fontes:

• Nisha Talagala, Are Tokens The New Currency? A Primer For Business, Forbes, maio de 2026. forbes.com
• The Pragmatic Engineer, The Pulse: Tokenmaxxing as a weird new trend. blog.pragmaticengineer.com
• Wall Street Journal, Why Some Companies Say AI Tokenmaxxing Is Key To Survival. wsj.com

A pôr uma equipa de engenharia potenciada por IA sob orçamento real e sem saber como medi-la sem partir a equipa? Fala com um CTO — ajudamos a separar a fatura do trabalho.