Che cos’è il “tokenmaxxing”? La metrica dell’IA che si è autodistrutta

In 30 giorni, i dipendenti di Meta hanno immesso circa 60 trilioni di token IA in una classifica interna che li ordinava in base al consumo; una spesa che, secondo le stime, ha superato i 100 milioni di dollari per produrre un lavoro che era in gran parte di facciata. Novanta giorni dopo, la classifica era scomparsa e l’azienda stava razionando rigorosamente l’uso dell’IA.

Questo percorso è noto come “tokenmaxxing”: si verifica quando la massimizzazione dell’utilizzo dei token di IA viene promossa a punteggio di prestazione e indicatore di produttività. Da allora le aziende hanno acquisito maggiore consapevolezza e alcune hanno reagito in modo eccessivo, dando vita a un fenomeno soprannominato “tokenminning”: l’utilizzo del minor numero possibile di token di IA per ridurre i costi di elaborazione. Entrambi gli approcci falliscono perché considerano il numero di token come un indicatore affidabile della crescita guidata dall’IA.

In questo articolo parleremo di quanto costa effettivamente il tokenmaxxing, di come gli ingegneri lo abbiano aggirato e della configurazione di misurazione in grado di resistere a chi è bravo a manipolare i numeri.

Che cos’è il “tokenmaxxing”?

Il "tokenmaxxing" è la pratica che consiste nel massimizzare il consumo di token dell’IA e nel considerare un utilizzo più elevato come prova di una maggiore produttività o di una più ampia adozione dell’IA. I token sono le unità che un modello di IA elabora come input e produce come output.

L’utilizzo dei token è diventato un indicatore di performance interessante perché è visibile, quantificabile e già sottoposto a monitoraggio da molte piattaforme di IA. Ciò lo rende più facile da utilizzare per la reportistica rispetto a risultati quali il tempo risparmiato, le decisioni migliorate o i ricavi generati. Tuttavia, i token misurano l’attività computazionale, non il lavoro utile. Prompt ripetitivi, cicli degli agenti falliti e output inutili fanno tutti aumentare il numero senza produrre nulla.

Gli agenti di IA peggiorano la situazione. Un agente analizza il contesto, richiama strumenti, rivede il proprio lavoro e assegna attività ad altri agenti. Ogni passaggio consuma token. Sebbene una maggiore attività possa significare un lavoro più utile, può anche comportare flussi di lavoro inefficienti e costi crescenti.

In parole povere, il difetto principale del tokenmaxxing è che i team massimizzano il numero di visibilità, mentre la produttività, la qualità e il ritorno sull’investimento rimangono invariati.

Perché il tokenmaxxing è diventato popolare?

Il “tokenmaxxing” è diventato popolare perché i vertici aziendali avevano bisogno di un numero per dimostrare che l’adozione dell’IA all’interno delle aziende stava effettivamente avvenendo. E l’utilizzo dei token era l’unica metrica visibile nella console di fatturazione.

All’inizio del 2026, Jensen Huang, CEO di Nvidia, ha dato il tono alla discussione nel podcast All-In con un esperimento mentale sulla fattura dei token di un ingegnere altamente retribuito.

«Se quell’ingegnere da 500.000 dollari non consumasse almeno 250.000 dollari in token, ne sarei profondamente allarmato», ha affermato. E se la risposta fosse stata 5.000 dollari? Sarebbe andato su tutte le furie.

L’utilizzo dell’IA era diventato un indicatore di visibilità di chi fosse al passo con i tempi. Ciò avveniva in un momento in cui, in ogni riunione di pianificazione, venivano sollevate domande su quali ruoli sarebbero stati assorbiti dall’IA. Gli ingegneri che spendevano token sembravano adattarsi al nuovo paradigma, mentre quelli che non lo facevano rischiavano di apparire come un problema.

Ecco l’ironia: la prima classifica dei token non era affatto pensata come una competizione. Shopify ne ha creata una per capire perché i suoi migliori clienti spendessero così tanto, non per metterli in competizione tra loro. Farhan Thawar, vicepresidente e responsabile dell’ingegneria, ha poi descritto come si è evoluto lo strumento.

L’azienda l’ha ribattezzata “dashboard di utilizzo”, ha aggiunto meccanismi di interruzione automatica e avvisi di spesa, e ha utilizzato i dati per individuare agenti fuori controllo e bug nell’infrastruttura. Farhan ha scritto:

Il “tokenmaxxing” è un argomento scottante. Di più non significa meglio. Abbiamo creato la prima classifica dei token di IA. Poi abbiamo evoluto il nostro approccio. È diventata una dashboard di utilizzo. Stessi dati, ma con una prospettiva diversa. Abbiamo aggiunto circuit breaker e picchi di spesa. Abbiamo individuato agenti fuori controllo. Abbiamo trovato bug nella nostra stessa infrastruttura. Il vero segnale: non chi ha speso di più, ma chi ha generato il maggiore impatto con i propri token. Sono questi gli ingegneri con cui voglio parlare.

La maggior parte delle aziende che ha copiato la classifica di Shopify l’ha utilizzata per classificare i dipendenti invece di analizzare la spesa per l’IA. La tabella sottostante mostra come si è svolto il tutto in ciascuna di esse.

Il trend emerso da questa tabella è coerente. Le organizzazioni che hanno utilizzato i dati relativi ai token per indagare sulle spese elevate hanno mantenuto un segnale efficace. Altre, che li hanno utilizzati per classificare le persone, hanno perso quel segnale nel giro di un trimestre.

In che modo gli ingegneri hanno gonfiato il proprio utilizzo dei token?

Gli ingegneri hanno gonfiato il proprio utilizzo di token generando attività di IA costose che non avevano mai avuto intenzione di implementare. The Pragmatic Engineer ha riportato questo comportamento presso Meta, Microsoft e Salesforce, individuando quattro tattiche comuni. Nessuna di esse comportava cattive intenzioni. Le persone vedevano semplicemente un numero visibile, erano preoccupate per i licenziamenti e presumevano che un uso massiccio dell’IA le avrebbe protette:

Molti ingegneri hanno verificato quanto spendessero i loro colleghi. Quindi hanno consumato quanto bastava per posizionarsi leggermente al di sopra della media. Più che puntare al primo posto, non volevano essere segnalati per non aver utilizzato abbastanza l’IA.

In Amazon, i dipendenti assegnavano attività banali e inventate agli agenti di IA per aumentare i propri punteggi Kirorank. Ciò ha aumentato i costi del cloud senza produrre alcun risultato aziendale. Quando Amazon ha eliminato la classifica, il vicepresidente senior Dave Treadwell ha spiegato al personale che era stata creata con buone intenzioni. Ha poi chiesto chiaramente: “Per favore, non usate l’IA solo per il gusto di usarla.”

Nell’ambito di questo cambiamento, Amazon ora monitora se il codice generato dall’IA funziona e apporta valore. Il consumo di token non è la sua priorità principale.

Quanto è costato il "tokenmaxxing" alle aziende?

Il "tokenmaxxing" è probabilmente costato a Meta più di 100 milioni di dollari in un solo mese e ha prosciugato il budget annuale di Uber per l’IA in quattro mesi. La stima di Meta deriva da un semplice calcolo aritmetico. In base ai prezzi dell’API di Claude Opus (al momento della pubblicazione della notizia), 60,2 trilioni di token costerebbero circa 900 milioni di dollari. Un’azienda delle dimensioni di Meta negozia forti sconti, ma anche in tal caso il conto potrebbe raggiungere le nove cifre.

Uber offre il quadro più chiaro dei costi, poiché non ha mai pubblicato una classifica. L’azienda ha fornito a circa 5.000 ingegneri strumenti di programmazione agentica senza un modello di spesa. Nel giro di un mese, la percentuale di ingegneri classificati come utenti agentici è salita dal 32% all’84%. L’intero budget annuale si è esaurito in quattro mesi .

Il CTO, Praveen Neppalli Naga, ha ammesso che l’azienda era “tornata al punto di partenza” per quanto riguarda le proprie ipotesi. L’intervallo delle spese mensili variava da 500 a 2.000 dollari per ingegnere, e la soluzione è stata drastica: un tetto massimo mensile di 1.500 dollari per strumento di programmazione, per ingegnere.

Quando gli ingegneri che svolgono un lavoro simile spendono somme così diverse, questa variazione dimostra che nessuno aveva definito quale fosse un “buon utilizzo”. Quindi ogni ingegnere ha inventato la propria definizione. Il COO di Uber, Andrew Macdonald, ha ammesso questo punto, dichiarando a Fortune che era “molto difficile tracciare una linea di demarcazione” tra il codice assistito dall’IA e le funzionalità/funzioni utili effettivamente rilasciate.

L’AI Impact Report di LeadDev ha rilevato che solo il 19% dei responsabili tecnici dà una valutazione positiva al tokenmaxxing. Il 57% di loro afferma che non riesca a misurare il valore reale.

Ecco perché il denaro si muove così velocemente: un agente che pianifica una modifica al codice legge il repository, richiama gli strumenti, esegue i test e riprova finché non riesce nell’intento. Un singolo ciclo può consumare decine di migliaia di token, e le letture dalla cache dei prompt fanno aumentare ulteriormente tale conteggio.

I team finanziari hanno stanziato fondi per l’IA come se si trattasse di una licenza per postazione. In realtà, però, essa si comporta come il cloud computing. Lo stesso divario contabile emerge quando i team assemblano uno stack di IA che coinvolge diversi fornitori senza attribuire a nessuno la titolarità del conto. Si tratta dello stesso tipo di errore che caratterizza la proliferazione incontrollata degli strumenti, ma a un livello superiore.

Che cos’è il tokenminning?

Il tokenminning è la pratica di ridurre al minimo il consumo di token per l’IA, ponendosi come obiettivo un utilizzo ridotto. Come abbiamo discusso nell’introduzione, si tratta di una correzione eccessiva che porta a risultati altrettanto deludenti. Il nome è l’abbreviazione di “token minimizing” ed è emerso come correzione al tokenmaxxing. Il New York Times ha riportato questo cambiamento in diverse aziende.

Meta ha comunicato ai dipendenti che avrebbe limitato l’uso dell’IA a seguito di un “aumento esponenziale” dei costi. Uber ha fissato un limite massimo alla spesa mensile, Walmart ha imposto limiti agli strumenti, mentre sia Amazon che Meta hanno rimosso le loro classifiche. Nel giro di poche settimane, le stesse aziende che avevano celebrato i propri utenti più assidui dell’IA stavano insegnando a tutti a razionare l’uso.

Questa correzione ripete l’errore che avrebbe dovuto correggere. La legge di Goodhart lo spiega al meglio: quando una misura diventa un traguardo, smette di essere una buona misura. Quindi, se si imposta l’utilizzo dei token IA come obiettivo, le persone troveranno il modo di ottimizzare quella metrica, anche a costo di minare l’intento originale. La legge di Goodhart mette in guardia dal tokenmaxxing e dal tokenminning.

Se premi un team per bruciare token, brucerà token di cui non ha bisogno. Se premi un team per risparmiare token, salterà l’esecuzione dell’IA che avrebbe individuato un bug. Oppure suddividerà una sessione approfondita in tre sessioni meno costose, ciascuna delle quali fornirà una risposta meno approfondita. Entrambi i team raggiungono i propri traguardi di utilizzo dei token, mentre la qualità del lavoro effettivo peggiora.

Il controllo dei costi di per sé non è l’errore. Come nell’esempio di Uber, il tetto massimo mensile di 1.500 dollari è una decisione di bilancio presa dopo che l’azienda aveva esaurito il budget annuale in quattro mesi. Ma l’impostazione di un limite di spesa risolve solo un problema finanziario. Non risponde alla domanda se i token abbiano portato qualcosa di utile.

La soluzione consiste nel distinguere due tipi di dati: i segnali da monitorare e i risultati a cui puntare. L’utilizzo dei token, il tasso di adozione e la quota di codice scritto dall’IA sono segnali che mostrano cosa sta accadendo all’interno del sistema. Sono utili quando si analizza un problema, ma non sono obiettivi validi. Questo perché ciascuno di essi può variare notevolmente senza che il cliente noti alcuna differenza.

Un’organizzazione dovrebbe invece puntare ai risultati. Questi seguono la stessa logica di qualsiasi insieme ben strutturato di KPI per lo sviluppo software: collegare un segnale precoce al risultato che dovrebbe prevedere. La dashboard di conversione di Shopify è il modello da seguire: stessi dati, senza alcun allegato relativo a una classifica.

Neil Dhar, vicepresidente senior di IBM Consulting, ha descritto come si diffonda la confusione in un saggio sui costi dell’IA.

#Tokenmaxxing è stato recentemente al centro dell’attenzione. La spinta delle organizzazioni a utilizzare quanta più IA possibile, il più rapidamente possibile, trasformandone l’utilizzo in un indicatore di valore. Ora è giunto il momento di pagare il conto. Poiché i costi dell’IA superano i rendimenti, l’istinto è quello di tagliare. Ma tagliare le spese da solo non risolverà il problema di fondo del ROI.

Secondo IBM, la soluzione consiste nel considerare l’utilizzo come un segnale e abbinarlo a un risultato che non possa essere falsato.

Un maggiore utilizzo dei token significa maggiore produttività?

No, un elevato utilizzo dei token non significa alta produttività. I più grandi set di dati disponibili mostrano che i due fattori evolvono in modo indipendente. Una ricerca condotta dalla piattaforma di intelligence per sviluppatori DX ha rilevato che l’adozione dell’IA è vicina alla saturazione, mentre gli incrementi di produttività misurati sono rimasti invariati.

Laura Tacho, CTO di DX, ha condiviso i dati. Tra gli sviluppatori, il 92,6% utilizza ora un assistente di programmazione basato sull’IA almeno una volta al mese, mentre circa il 75% lo utilizza settimanalmente. L’IA scrive il 26,9% del codice di produzione. Tuttavia, il risparmio di tempo dichiarato dagli stessi sviluppatori è rimasto a circa quattro ore alla settimana per oltre un anno. E il guadagno iniziale di produttività del 10% non è mai aumentato.

L'utilizzo continuava a crescere mentre i risultati rimanevano invariati. Qualsiasi metrica che effettui il monitoraggio solo dell'utilizzo ha effettuato la reportistica su un successo che non si è mai verificato.

Il rapporto DORA di Google Cloud spiega perché gli stessi strumenti producono risultati così diversi. È emerso che l’adozione dell’IA ha migliorato la velocità di consegna, ma ha compromesso la stabilità della stessa. Il rapporto descrive l’IA come un amplificatore: essa esalta i punti di forza delle organizzazioni ben gestite e le debolezze di quelle in difficoltà.

I dati di DX mostrano questo effetto amplificatore all’opera. In un gruppo di 67.000 sviluppatori, alcune organizzazioni hanno visto raddoppiare gli incidenti che coinvolgono i clienti, mentre altre li hanno dimezzati, utilizzando gli stessi strumenti nello stesso periodo. Tacho attribuisce la responsabilità a chi indicano i dati:

Si tratta in realtà di un problema gestionale. Il clamore mediatico ha fatto credere che bastasse provare l’IA per ottenere automaticamente dei risultati. Ma finora, la maggior parte degli strumenti è stata utilizzata per singole attività di programmazione. Per vedere un impatto reale, dobbiamo utilizzare l’IA a livello organizzativo, non solo per singole attività.

C'è un secondo problema alla base del primo: le persone valutano erroneamente il proprio aumento di produttività grazie all'IA. Il laboratorio di ricerca senza scopo di lucro METR ha condotto uno studio randomizzato controllato. 16 sviluppatori open source esperti hanno completato 246 problemi reali nei repository che gestivano da una media di cinque anni. Prima di iniziare, gli sviluppatori avevano previsto che l’IA li avrebbe resi più veloci del 24%. Al termine, hanno stimato che li avesse resi più veloci di circa il 20%. Il cronometro ha invece rilevato che erano più lenti del 19%.

In un aggiornamento successivo, il laboratorio ha spiegato che il suo esperimento successivo ha incontrato effetti di selezione che non è stato in grado di correggere. Ha inoltre affermato che ora gli sviluppatori sono probabilmente davvero più veloci grazie all’IA, soprattutto grazie agli strumenti agentici. Cosa rimane: la produttività autodichiarata non sostituisce quella misurata, e il divario tra le due può andare in entrambe le direzioni.

Cosa dovresti misurare al posto dell’utilizzo dei token?

Anziché misurare l’utilizzo dei token, valuta i risultati a livello di team e poi a livello organizzativo. Considera l’utilizzo dei token come un indicatore di costo su cui nessuno viene valutato. Ciò che conta sono i risultati ottenuti.

Una regola pratica da seguire: abbina ogni segnale che pubblichi a un risultato che non possa gonfiare. Un team può bruciare token senza rilasciare nulla. Tuttavia, non può falsare un tasso di fallimento in calo.

Questa struttura deriva da framework di misurazione di cui i responsabili tecnici si fidano già. DORA copre la velocità di consegna e la stabilità, e la sua constatazione che l’IA amplifica entrambe è il motivo per cui questa combinazione è importante.

Il DX Core 4 misura quattro dimensioni: velocità, efficacia, qualità e impatto aziendale. Abi Noda e Laura Tacho lo hanno sviluppato insieme a Nicole Forsgren e Margaret-Anne Storey, le ricercatrici che stanno dietro a DORA, SPACE e DevEx. Le quattro dimensioni sono volutamente in contrapposizione tra loro.

Un team che migliora un aspetto a scapito di un altro mette subito in luce il compromesso. Nessuno dei due framework include una metrica relativa ai token e nessuno dei due ne ha aggiunta una.

Tre regole fanno sì che l’abbinamento funzioni nella pratica:

Come si effettua l’impostazione di una politica di utilizzo dell’IA che i dipendenti non possano aggirare?

Per definire una politica di utilizzo dell’IA che i dipendenti non possano manipolare, rimuovi ogni numero visibile dalla valutazione individuale e prendi cinque decisioni:

1. Decidi a cosa serve quel numero prima di raccoglierlo

Ogni metrica prevista dalla politica deve avere uno scopo ben definito prima che venga pubblicata la prima dashboard. La classifica di Shopify ha funzionato nella sua fase iniziale. La dirigenza l’ha utilizzata per avviare conversazioni con i clienti che spendevano di più riguardo a ciò che stavano realizzando. Il numero ha dato il via a un’indagine. Non appena lo stesso numero ne chiude una, traendo conclusioni su una persona anziché porre domande sul lavoro, si trasforma in un punteggio. E i punteggi vengono gestiti.

Annota tre elementi per ogni metric:

La linea di inazione è quella che richiede più lavoro, perché i dipendenti mettono alla prova la politica proprio in base ad essa. Se la risposta onesta alla domanda «cosa succede quando la spesa aumenta» mette in gioco la posizione di qualcuno, allora hai creato una classifica con passaggi aggiuntivi.

2. Stabilisci il budget a livello di team

Un budget comune per il team sostituisce il limite individuale, e la differenza è comportamentale, non contabile. Il divario mensile da 500 a 2.000 dollari tra gli ingegneri di Uber che svolgono un lavoro simile mostra cosa succede in assenza di un punto di riferimento condiviso. Ognuno si inventa la propria definizione di “ragionevole”. I budget comuni funzionano allo stesso modo di qualsiasi altro tentativo di convogliare le spese sparse per l’IA in un unico luogo controllabile.

L’envelope ti offre tre vantaggi che un limite pro capite non può garantire:

Definisci la dimensione della prima fascia di budget sulla base dei dati osservati. Prendi la media degli ultimi tre mesi del team e aggiungi un margine per un progetto costoso. Una fascia di budget fissata a caso viene superata già nella seconda settimana, dimostrando a tutti che la politica è solo di facciata.

3. Rendere visibile il percorso più costoso

Mostra agli ingegneri il costo di ogni esecuzione invece di limitare quanto possono spendere. Le esecuzioni agentiche che si ripetono a ciclo continuo a causa di test falliti sono quelle in cui i budget si esauriscono, rendendo indispensabile l’imposizione di un limite massimo rigido. Un’altra opzione consiste nel mostrare il costo per esecuzione all’ingegnere che l’ha triggerata, senza effettuare reportistica sui livelli superiori.

Un ingegnere che vede un ciclo di riprova consumare 40 dollari correggerà il ciclo. D’altra parte, un ingegnere che teme la reportistica smetterà del tutto di utilizzare l’agente, anche nei casi in cui l’esecuzione costosa fosse stata la scelta giusta.

I circuit breaker di Shopify funzionano in questo modo: il sistema rileva l’anomalia e la persona più vicina al lavoro decide cosa fare. La visibilità modifica il comportamento più rapidamente di un limite massimo e mantiene disponibile l’esecuzione costosa ma corretta quando il lavoro giustifica la spesa.

4. Separare l’obiettivo di adozione dell’IA dalla valutazione delle prestazioni

Metti per iscritto la separazione, perché le rassicurazioni verbali non sopravvivono a un ciclo di licenziamenti. L’ingegnere di Microsoft che ha raccontato a The Pragmatic Engineer di aver gonfiato le proprie metriche di utilizzo non era alla ricerca di un premio. Stava semplicemente evitando di essere etichettato in un anno caratterizzato da licenziamenti legati all’IA.

Se le persone credono che i dati di utilizzo arrivino a una riunione di calibrazione, gestiranno i dati, indipendentemente da ciò che qualcuno possa dire ad alta voce.

Il testo della politica richiede esattamente due righe:

Quindi tieni conto di entrambi. Il primo ingegnere che vedrà emergere i dati di utilizzo durante una revisione lo dirà a tutti, dimostrando che le metriche sono superflue.

5. Rivedere l'abbinamento ogni trimestre

Ogni trimestre, chiediti se ciascuna diagnostica spieghi ancora il risultato a cui è associata. I prezzi dei modelli, il comportamento della cache e l’architettura degli agenti cambiano tutti più rapidamente di un ciclo di pianificazione annuale.

Il modo in cui i team applicano l’IA alla pianificazione e alla reportistica è in continua evoluzione. Un conteggio di token che a gennaio aveva un significato, a giugno ne assume uno diverso, dopo due riduzioni di prezzo e un aggiornamento dell’agente.

La valutazione fornisce risultati onesti per ogni metrica: o continua a prevedere il risultato della coppia, o necessita di una ricalibrazione in base ai nuovi prezzi, oppure ha smesso di spiegare qualsiasi cosa e viene ritirata senza tante cerimonie. Sono i team a opporre maggiore resistenza al ritiro. Tuttavia, si tratta di un aspetto importante perché una metrica che sopravvive al proprio significato è esattamente il tipo di numero su cui si è fondata l’era delle classifiche.

Errori comuni commessi dai team nella misurazione dell’adozione dell’IA

Gli quattro errori più comuni sono: considerare l’adozione come il traguardo finale, fidarsi della reportistica relativa ai risparmi di tempo dichiarati dagli utenti stessi, pubblicare classifiche individuali e misurare la velocità senza valutare la stabilità. È possibile individuare ciascuno di essi prima che diventi costoso.

1. Considerare l’adozione come il traguardo

La dashboard di implementazione indica il 90%, la dirigenza dichiara completata l’iniziativa sull’IA e nessuno si chiede cosa sia cambiato a valle. I dati di DX hanno messo in luce questa trappola su larga scala: un’adozione del 92,6% con una produttività ferma al 10%. L’adozione conferma solo che gli strumenti sono stati distribuiti agli utenti. Non dice nulla su cosa abbiano cambiato tali strumenti.

La soluzione: eliminare il grafico di adozione una volta terminata la fase di lancio e sostituirlo con un abbinamento tra segnale e risultato.

2. Fidarsi dei risparmi di tempo dichiarati dagli utenti stessi in fase di reportistica

Secondo un sondaggio, il team risparmia cinque ore alla settimana, ma la durata ciclo non è cambiata negli ultimi due trimestri. La versione di prova di METR mostra perché questi due numeri non coincidono: gli sviluppatori che lavoravano in modo sensibilmente più lento con l’IA hanno comunque stimato un aumento della velocità del 20% in seguito. Ciò che le persone credono e ciò che registra il cronometro sono due misurazioni diverse.

La soluzione: mantieni il sondaggio per l’esperienza degli sviluppatori, dove la percezione è importante. Utilizza i dati di sistema per qualsiasi affermazione relativa al tempo.

3. Pubblicare una classifica individuale solo per divertimento

Qualcuno lo crea su un wiki interno nel giro di un pomeriggio, gli assegna titoli spiritosi e il team se lo gode davvero per circa tre settimane. Poi subentra l’incentivo. Sia la “Claudeonomics” di Meta che il “Kirorank” di Amazon sono nati come divertimenti dal basso. Entrambe le aziende li hanno ritirati una volta che il gioco ha superato l’entusiasmo iniziale.

La soluzione: aggregare i dati a livello di team, oppure non inviarli affatto.

4. Misurare la velocità senza misurare la stabilità

La produttività aumenta, tutti festeggiano, mentre il volume degli incidenti sale nella dashboard di un altro team. Il rapporto DORA ha individuato proprio questa dicotomia: la velocità migliora mentre la stabilità peggiora. Mantenere i due numeri su dashboard separate rende il problema invisibile.

La soluzione: inserire il tasso di fallimento delle modifiche nella stessa schermata in cui sono riportate le metriche di velocità, anziché in una revisione separata sull’affidabilità che nessuno consulta.

Come effettuare il monitoraggio dell’impatto dell’IA in ClickUp

Per il monitoraggio dell’impatto dell’IA in ClickUp, misura i risultati a fronte del lavoro stesso: le attività, i Sprints e i risultati finali che l’IA avrebbe dovuto velocizzare. La maggior parte delle dashboard dei token si trova nella console del provider, lontana dal lavoro che descrivono. Spostare le metriche dei risultati nell’area di lavoro colma questa lacuna.

L’accoppiamento tra segnale e risultato descritto in precedenza si riflette direttamente sulla piattaforma:

Tieni d'occhio il numero di token senza attribuire un punteggio alle persone

L’intera storia si riduce a una sola regola: usa i dati dei token per porre domande, mai per valutare le persone. Shopify si è chiesta: «Cosa stanno sviluppando i nostri maggiori spenditori?» e ha scoperto agenti fuori controllo e bug nelle infrastrutture. Meta e Amazon si sono chieste: «Chi utilizza maggiormente l’IA?» e si sono ritrovate con attività fasulle, milioni sprecati e classifiche inutili.

Quindi, in questo trimestre, da fare in tre modi. Sposta il monitoraggio dei token a livello di team ed elimina qualsiasi elemento che riporti il nome di una singola persona. Specifica nella politica aziendale che i dati di utilizzo non devono mai influire sulla valutazione delle prestazioni. Infine, inserisci un indicatore di qualità (il tasso di fallimento delle modifiche è il più semplice) nella stessa schermata in cui riporti tutte le metriche di velocità.

Se desideri che quella schermata sia integrata nel flusso di lavoro effettivo anziché in uno strumento di reportistica separato, inizia a utilizzare ClickUp gratis e crea la dashboard prima ancora che ti serva.

Domande frequenti sul Tokenmaxxing (FAQ)

Cos’è la regola del 30% per il tokenmaxxing?

Non esiste una «regola del 30%» ufficiale specifica per il tokenmaxxing. L’espressione è solitamente un’abbreviazione di due constatazioni distinte che le persone tendono a confondere: che l’IA tende ad aumentare la produttività ingegneristica misurata di circa il 10%, non del 30%, e che gli sviluppatori prevedono abitualmente guadagni intorno al 20–30% che poi non si concretizzano. Considerate qualsiasi percentuale fissa come un elemento diagnostico da approfondire, mai come un traguardo da raggiungere.

Un milione di token corrisponde all’incirca a 750.000 parole di testo in inglese, poiché un token equivale in media a circa tre quarti di parola. Il costo dipende interamente dal modello e dalla ripartizione tra input e output. Alle tariffe dei modelli all’avanguardia del 2026, l’intervallo va da pochi dollari a poche decine di dollari per milione. Le sessioni agentiche consumano rapidamente milioni di token perché ogni ciclo rilegge il contesto e le letture dalla cache dei prompt si aggiungono al conteggio.

Il termine “Tokenmaxxing” combina “token” con il suffisso internet “-maxxing”, che significa massimizzare una caratteristica. Si è diffuso negli ambienti degli ingegneri all’inizio del 2026 dopo che le classifiche interne sui token di Meta e Amazon sono trapelate alla stampa. Business Insider lo definì «il nuovo dibattito sull’IA nella Silicon Valley » nell’aprile 2026. Classifiche pubbliche come Viberank e tokenmaxxing.sh adottarono poi questa etichetta, classificando i singoli sviluppatori in tutto il mondo in base alla spesa per le API.

In gran parte, sì. Fortune ha dichiarato la fine del tokenmaxxing nel maggio 2026 dopo che Meta, Amazon, Microsoft e Uber hanno ridimensionato o eliminato le loro classifiche dei token. L’AI Impact Report di LeadDev ha rilevato che solo il 19% degli intervistati ha dato una valutazione positiva al tokenmaxxing, ritenendolo efficace nel misurare il valore dell’IA, mentre il 57% afferma che fallisca completamente. Le classifiche pubbliche amatoriali persistono, ma come gioco, non come pratica gestionale.

Non esiste un benchmark consolidato. Durante il lancio di Uber, l’intervallo delle fatture mensili era compreso tra 500 e 2.000 dollari per ingegnere, prima che l’azienda fissasse un tetto massimo di spesa di 1.500 dollari per strumento. Il CEO di Nvidia, Jensen Huang, ha sostenuto che un ingegnere da 500.000 dollari dovrebbe consumare 250.000 dollari in token all’anno, ma molto probabilmente si tratta di una provocazione, non di uno standard. I risultati mostrano un’ampia variabilità tra attività di lavoro comparabili, il che significa che nessuno ha ancora definito quale sia un utilizzo corretto.

Il “vibe coding” è un modo di lavorare: delegare l’implementazione a un agente di IA e orientarsi in base ai risultati. Il “tokenmaxxing” è un modo di misurare: considerare i token consumati come prova della produttività. È possibile praticare il “vibe coding” in modo efficiente o dispendioso; il “tokenmaxxing” premia la versione dispendiosa perché conta solo il consumo. Le aziende che hanno posto un limite ai token per fermare il “tokenmaxxing” spesso hanno penalizzato, nel processo, il lavoro legittimo degli agenti.