I token non sono una moneta. Sono righe di codice con la fattura allegata.

Nisha Talagala ha pubblicato su Forbes un primer sui token in cui sostiene che i token — l'unità di costo e di misura del consumo degli LLM — stanno diventando una moneta di business fondazionale. Introduce il termine tokenmaxxing, segnala che ci sono già aziende che valutano pubblicamente i dipendenti per uso di token e propone un quadro tranquillo di budget, tracciamento e trade-off. Come primer, va bene. Come roadmap per qualsiasi organizzazione di ingegneria che debba consegnare sotto budget, è la versione più educata di un'idea molto pericolosa.

L'idea pericolosa: che l'uso di token misuri il lavoro. Non lo misura. Misura la fattura. Dal sedile di chi ha dovuto difendere una voce di costo IA davanti a un CFO e a una rotazione SRE nella stessa settimana, il framing conta più dei numeri — e Forbes ci azzecca solo a metà.

Cosa Forbes prende giusto

Tre cose nell'articolo sono corrette e dovrebbero già essere nella roadmap di ogni CTO:

1. La spesa in token è reale e cresce. L'articolo cita che una singola revisione di email consuma ~100 token, con un costo di circa 0,25 centesimi USD a task. Moltiplica per ogni dipendente, ogni workflow, ogni retry, ogni agente concatenato — e la voce passa da "errore di arrotondamento" a "negoziazione con il CFO" in un trimestre. Le aziende che hanno iniziato dando token illimitati ai dipendenti stanno, prevedibilmente, razionando.
2. Non tutti i token sono uguali. Forbes ha ragione: un token non è comparabile fra vendor, modelli, task e tempi. Un token a un modello di reasoning di frontiera non è commercialmente equivalente a un token a un piccolo modello open-weights, anche se la contabilità vuole sommarli.
3. Serve tooling. Il tracciamento dei token genererà la stessa ondata di vendor del costo cloud un decennio fa: un mercato FinOps per i token. Quel mercato si sta già formando.

Queste tre osservazioni basterebbero a giustificare l'articolo. Il problema è la quarta idea che gli viene incollata sopra.

Dove Forbes sbaglia: il token come proxy di produttività

L'articolo descrive — con troppo poco senso critico — una tendenza in cui le aziende trattano token per dipendente per unità di tempo come metrica di produttività. Tira persino l'analogia con il budget viaggi di un commerciale: il dipendente che sotto-consuma il budget di token equivale, in quel quadro, al commerciale che non prenota visite. Spendere meno diventa segnale negativo.

Questa è la legge di Goodhart con un costume nuovo. Quando una misura diventa un obiettivo, smette di essere una buona misura. Il giorno in cui dici agli ingegneri che il loro uso di token è valutato — formalmente, dal management, con peso nella performance review — non hai misurato nulla sulla produttività. Hai creato un nuovo mercato del rumore.

Forbes ammette il vettore di abuso ("i token sono triviali da abusare") ma lo tratta come un problema di igiene gestibile. Non lo è. La storia delle metriche di ingegneria è esattamente la storia di questo modo di fallimento:

• Righe di codice per sviluppatore. Misurate per due decenni. Ottimizzate scrivendo più righe. Premio: codebase Fortran 77 che nessun umano riusciva a mantenere. La cosa misurata — valore creato — si è scorrelata e poi anti-correlata dalla metrica. Ho sostenuto lo stesso punto sulle metriche di produttività e la meccanica è identica.
• Ticket chiusi per sprint. Ottimizzato spezzando i ticket. O chiudendo prima quelli banali. O gonfiando lo sprint. I team che gamavano meglio la metrica erano i peggiori a consegnare.
• Copertura dei test. Ottimizzata scrivendo test che eseguono righe senza asserire comportamento. La copertura saliva, i difetti salivano, gli ingegneri venivano promossi.

"Token consumati per dipendente al mese" sta in questa stirpe. Ed è peggio, perché ogni token gamato costa soldi veri a un vendor vero. Le metriche di vanità classiche si gamavano gratis. Il tokenmaxxing è gaming pagato, con la fattura inoltrata alla finanza.

La misura onesta è più difficile, e non sono i token

Quello che vuoi davvero sapere di un ingegnere che usa strumenti IA è grosso modo:

• Il cambiamento è stato consegnato?
• È stato consegnato correttamente?
• È stato consegnato più velocemente di quanto sarebbe stato senza lo strumento?
• L'ingegnere ha imparato qualcosa di riusabile, o ha esternalizzato il pensiero?
• Il codice risultante è revisionabile, manutenibile e owned?

Nessuno dei cinque si misura in token. I primi quattro si misurano con metriche DORA oneste — frequenza di deploy, lead time, change failure rate, MTTR. Il quinto solo con code review e tempo. Non c'è scorciatoia, e i token non sono la scorciatoia travestita.

Forbes annuisce con la frase "infuse the AI force multiplier" — l'idea che è la competenza umana a dare valore al token. D'accordo. Ma quella concessione smonta tutto il quadro token-budget-as-produttività che le sta accanto. Se il moltiplicatore è l'umano, l'unità rilevante è risultato per ingegnere, non token per ingegnere. La spesa in token è un costo di input, come cloud, elettricità o ufficio — e nessuno viene promosso per aver speso più elettricità.

Cosa sono davvero i token: una voce di costo cloud, con default peggiori

Se togli l'errore metrica-di-produttività, quello che rimane è corretto e vale la pena gestirlo bene. I token entrano sulla stessa curva di maturità della spesa cloud, e il playbook del decennio FinOps si applica quasi senza modifiche:

1. Assegna la spesa ai risultati, non alle persone. Un token consumato da un agente di CI che cattura una regressione in produzione non è commensurabile con un token consumato da un ingegnere che chiede a un LLM di riformulare uno Slack. Etichetta i token per workflow, non per dipendente — come etichettavi le EC2 per servizio, non per la persona che le aveva avviate.
2. Metti quote per rotta, non per persona. Lo sforamento interessante in un'organizzazione con IA raramente è un dipendente loquace. È un agente runaway in una pipeline che chiama un modello di frontiera in loop con retry-with-backoff. I budget per dipendente non lo prendono. I budget per strumento e per flusso sì, come i budget per servizio hanno preso la lambda che faceva 3.000 letture Aurora alle 3 del mattino.
3. Arbitra il prezzo fra modelli. Forbes ha ragione: vendor e prezzi fluttuano; la risposta giusta è uno strato di routing che manda ogni task al modello più economico che soddisfa la soglia di qualità per quel task — non un contratto fisso con un unico vendor di frontiera a prezzo di listino. L'economia dei modelli di fondazione premia decisioni build-vs-buy per carico, non lo standardizzare sul più caro.
4. Osservabilità prima degli incentivi. La maggior parte delle organizzazioni sta per prendere decisioni di policy sui token prima di avere attribuzione affidabile per task. L'ordine è sbagliato. Sistema prima l'attribuzione — per servizio, per flusso, per retry, per risultato verso l'utente — poi parla di budget. Altrimenti metterai quote sul rumore.

Questo è FinOps con un'unità diversa. Non è, e non dovrebbe essere, performance management.

Cosa dice davvero il "tokenmaxxing" di un'organizzazione

Se un'organizzazione di ingegneria si trova a premiare il consumo di token — o peggio, trova i suoi ingegneri a gamare il consumo per sembrare produttivi — il problema non è degli ingegneri. È della leadership che ha scelto la metrica. Il tokenmaxxing è un sintomo, e la malattia di fondo è la stessa che vedo in ogni cliente che non ha costruito una vera cultura di misurazione: il management vuole un numero unico, la finanza vuole un numero unico, e la fattura LLM offre comodamente un numero unico che sale.

Un'organizzazione di ingegneria seria resiste a quella compressione. Fa girare almeno due stream in parallelo:

• Stream costo. Cosa abbiamo speso in IA, ripartito per workflow, per team, per modello, per modalità di retry? Dov'è lo spreco? Il router sta facendo il suo lavoro? Ci sono agenti in loop?
• Stream risultato. Cosa è stato consegnato? Cosa no? Qual è il change failure rate? Le PR assistite da IA hanno un profilo di difetti diverso da quelle non assistite? L'IA cattura più incidenti di quanti ne causi?

Se fai girare solo lo stream costo, finirai per ottimizzare il consumo di token — e Forbes sta descrivendo correttamente il tipo di azienda che diventerai. Se fai girare solo lo stream risultato, non prenderai l'agente runaway che ha incendiato la tua fattura AWS. Servono entrambi, su dashboard distinte riviste da persone distinte.

Cosa metterei davanti a un CTO questo trimestre

1. Attribuzione per flusso prima dei budget per dipendente. Finché non puoi nominare i cinque workflow che consumano più token nel tuo stack, non hai un problema di token che puoi risolvere.
2. Un kill-switch per agente, lo stesso che sostengo come non negoziabile per qualsiasi sistema agentico in produzione. Un loop infinito in un agente è ormai un incidente finanziario tanto quanto uno SRE.
3. Uno strato di routing dei modelli, anche rudimentale. Se tutti i team chiamano direttamente lo stesso modello di frontiera senza fallback a livelli più economici per task triviali, la tua fattura sta pagando pigrizia di piattaforma, non produttività degli ingegneri.
4. Una policy di misurazione che escluda esplicitamente i token dalla performance individuale. Per iscritto. E ad alta voce. Il primo giorno in cui un manager elogia un ingegnere per aver "consumato più token questo trimestre", la metrica è morta e la cultura va dietro.
5. Una voce di budget per lo spreco. Una parte della spesa in token sarà esplorativa, vicolo cieco e irriducibilmente sperimentale. Va bene. Dai un nome a quella voce, mettila a budget, e smettila di provare a ottimizzarla a zero. È anche dove succede gran parte dell'apprendimento.

La linea che traccio

Forbes ha ragione: i token sono ormai una voce reale che le aziende devono pianificare, tracciare e governare. Forbes sbaglia — o quantomeno è pericolosamente casual — quando estende quella voce fino a renderla metrica di produttività individuale. Il primo è FinOps. Il secondo è l'errore righe-di-codice ristampato con una fattura del vendor attaccata.

Le aziende che navigheranno bene i prossimi due anni saranno quelle che tratteranno i token con la stessa disciplina noiosa che (alla fine) hanno imparato ad applicare al cloud: assegnare la spesa ai risultati, instradare il lavoro al modello più economico che basta, osservare prima di incentivare, e mai — mai — promuovere un ingegnere per aver consumato più input.

I token sono il costo. L'ingegnere è il moltiplicatore. Se le tue metriche confondono i due, non hai una strategia IA. Hai una fattura IA.

---

Fonti:

• Nisha Talagala, Are Tokens The New Currency? A Primer For Business, Forbes, maggio 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

Stai mettendo un team di ingegneria potenziato dall'IA sotto un budget reale e non sai come misurarlo senza rompere il team? Parla con un CTO — ti aiutiamo a separare la fattura dal lavoro.