Il mio feed di LinkedIn ne è pieno da settimane. Anche la mia timeline X. Persone che pubblicano schermate di spesa di token come se fossero relazioni sui progressi. Fondatori di startup che si vantano di aver speso 16.000 dollari in Claude Code il mese scorso e di puntare a 60.000 dollari il prossimo. Classifiche. Classifiche. Titoli come "Token Legend" e "AI God".
E poi, la scorsa settimana, ha raggiunto la massa critica. Forbes ha riferito del movimento "tokenmaxxing" che sta travolgendo la Silicon Valley, dove le aziende competono per vedere chi brucia più token AI. Jensen Huang ha partecipato al podcast All-In e ha detto: "Quell'ingegnere da 500.000 dollari, alla fine dell'anno, gli chiederò: "Quanto hai speso in token?". Se quella persona mi risponde '5.000 dollari', io mi sclerotizzo. Se quell'ingegnere da 500.000 dollari non ha consumato almeno 250.000 dollari di token, mi allarmerò profondamente".
Poi Fortune ha riportato che un dipendente di Meta ha costruito una classifica interna chiamata "Claudeonomics", che tiene traccia del consumo di token da parte degli oltre 85.000 dipendenti dell'azienda. I migliori utenti ricevevano dei titoli. In un periodo di 30 giorni, l'utilizzo totale ha raggiunto i 60.000 miliardi di token. Il singolo utente migliore ha avuto una media di 281 miliardi. Mark Zuckerberg non è nemmeno entrato nella top 250. Il CTO di Meta Andrew Bosworth, nel frattempo, ha dichiarato pubblicamente che il suo miglior ingegnere spendeva l'equivalente del suo stipendio in token, ma era "da 5 a 10 volte più produttivo". "È come se fossero soldi facili", ha detto Bosworth. "Senza limiti".
Lavoro nel software da abbastanza tempo per capire cosa sta succedendo. Si tratta di "linee di codice" con un prezzo molto più alto.
Ci siamo già passati
Nel 2003, Martin Fowler ha scritto un breve articolo sul perché la produttività del software non può essere misurata che probabilmente dovrebbe essere una lettura obbligatoria per ogni dirigente tecnico. La sua argomentazione sulle linee di codice era precisa:
"Una delle mie maggiori irritazioni sono gli studi sulla produttività basati sulle linee di codice. Ogni buon sviluppatore sa che può codificare le stesse cose con enormi variazioni di linee di codice".
Il problema è evidente quando lo si dice ad alta voce. La LOC misura l'attività, non la produzione. Due sviluppatori possono costruire la stessa funzione: uno scrive 1.200 righe, l'altro ne scrive 80. Il più conciso probabilmente ha costruito una funzione migliore. Quello più conciso probabilmente costruisce un sistema migliore. In un regime di LOC, il verboso sembra più produttivo.
I team valutati in base al LOC hanno risposto in modo razionale. Hanno scritto più righe. Hanno fatto copia-incolla invece di astrarre. Hanno evitato il refactoring, perché l'eliminazione del codice avrebbe danneggiato i loro numeri. La metrica ha modellato il comportamento, ma non verso un software migliore. Più codice. Sistemi peggiori.
Poi, nel 2023, McKinsey pubblicò un articolo in cui sosteneva di aver decifrato la misurazione oggettiva della produttività degli sviluppatori. La risposta approfondita di Gergely Orosz e Kent Beck ha evidenziato lo stesso difetto: quasi tutte le metriche di McKinsey misuravano lo sforzo e la produzione, non i risultati. Kent Beck ha raccontato di aver visto i sondaggi interni di Facebook sul sentiment degli sviluppatori trasformarsi da un feedback utile a una negoziazione dei manager con gli ingegneri per ottenere punteggi più alti. Ecco cosa succede quando si incentiva una metrica proxy. Il numero migliora. La cosa di cui ci si preoccupa veramente non migliora.
Si potrebbe pensare che abbiamo imparato. Non è così.
Stesso errore, unità diversa
La logica seducente del tokenmaxxing funziona così. Consumo di gettoni = utilizzo dell'AI. Più utilizzo dell'AI = i team utilizzano l'AI. Pertanto, un'elevata spesa di token = un'elevata adozione dell'IA = buona.
Si tratta di una logica errata come quella di misurare le linee di codice, ma con un cruscotto di fatturazione invece di un grafico di commit. E per essere corretti nei confronti dell'articolo di Forbes, il CEO di Sendbird, John Kim, ha detto esattamente questo: "Abbiamo già visto questo film". Si riferiva alla cultura LOC degli anni '90 e 2000. Il vero indicatore, ha osservato, è la quantità di codice generato dall'AI che entra effettivamente in produzione. La spesa per i gettoni "è più che altro un argomento di conversazione". Sono d'accordo. Diventa un problema quando l'argomento di conversazione viene promosso a KPI principale.
Il sondaggio sugli sviluppatori 2024 di GitHub ha rilevato che il 97% degli sviluppatori aziendali ha utilizzato strumenti di codifica AI sul lavoro in qualche momento. Un'adozione organizzativa significativa, tuttavia, richiede politiche chiare, flussi di lavoro e risultati misurabili legati ai risultati aziendali effettivi. Non solo utilizzo. Non solo consumo.
Boris Cherny, l'ingegnere che sta dietro a Claude Code, ha condiviso pubblicamente che non ha aperto alcun IDE durante un mese di lavoro, con Opus 4.5 che ha scritto circa 200 PR. È impressionante. Ma ciò che lo rende impressionante non sono i token che quei 200 PR hanno consumato. È che si trattava di 200 contributi reali uniti con un software funzionante all'altro capo.
Il valore è nel risultato. I gettoni sono l'energia che ha portato al risultato, niente di più.
Quando la metrica diventa l'obiettivo
Esiste un principio chiamato Legge di Goodhart: quando una misura diventa un obiettivo, cessa di essere una buona misura. La storia dello sviluppo del software è praticamente un museo della Legge di Goodhart in azione.
Il monitoraggio dei token come KPI per l'adozione dell'AI crea la stessa dinamica. I team di ingegneri misurati sul consumo di token consumeranno più token. È così che funzionano gli incentivi. Vuole sembrare più produttivo? Esegua qualche ciclo agenziale in più. Lasci che il modello ragioni a lungo prima di generare l'output. Avvolgere ogni attività in un livello di orchestrazione che richiama quattro strumenti dove ne basterebbe uno. La spesa in gettoni aumenta. Il valore fornito non aumenta.
In realtà, la storia di Claudeonomics lo ha dimostrato quasi subito. Fortune ha notato che "alcuni dipendenti hanno messo gli agenti AI al lavoro per ore per massimizzare l'utilizzo dei token". Eccola qui. La Legge di Goodhart in esecuzione in tempo reale, all'interno di un'azienda che dovrebbe essere alla frontiera della produttività guidata dall'AI. La classifica era attiva da qualche settimana prima di essere chiusa, e i dipendenti la stavano già sfruttando eseguendo agenti in loop. La metrica era vecchia di tre settimane e aveva già smesso di misurare ciò che doveva misurare.
Ogni sviluppatore che legge questo articolo può probabilmente pensare a cinque modi per gonfiare le metriche di utilizzo dei token senza alcun beneficio per nessuno. Non li elencherò. Ma se a me ne vengono in mente cinque, possono farlo anche gli ingegneri che vengono misurati in questo caso.
Andrej Karpathy ha descritto il momento attuale dell'ingegneria del software come un "terremoto di magnitudo 9" per la professione. Ha ragione. Ma i terremoti non si misurano in base all'elettricità consumata. Si misurano in base a ciò che si è mosso.
La versione della documentazione di questo problema
Questo non è un problema solo per i team di ingegneri. Vedo la stessa dinamica nella gestione della conoscenza, che è molto più vicina a noi di Rasepi.
"Abbiamo pubblicato 400 documenti in questo trimestre" è un numero che suona bene in una presentazione. Non ha nulla a che vedere con l'accuratezza di quei documenti, con il fatto che qualcuno li abbia letti o che le informazioni in essi contenute siano ancora vere sei mesi dopo. È possibile ottenere quel numero con l'AI e senza alcun pensiero. Rumore assistito da token pubblicato su scala.
La metrica onesta è più difficile da raccogliere, ma molto più utile: quale percentuale della sua base di conoscenza riflette effettivamente il funzionamento dei suoi sistemi oggi? Quante persone hanno raggiunto una risposta corretta utilizzando la sua documentazione? Quanti ci hanno provato, hanno fallito e hanno finito per chiedere a qualcuno su Slack?
Queste domande non hanno ancora dei bei dashboard. Richiedono una riflessione concreta su ciò che vuole che la documentazione faccia per la sua organizzazione. (Non a caso, questo è esattamente il problema su cui si basa Rasepi. Le date di scadenza forzate esistono proprio perché i team debbano valutare se i contenuti sono ancora validi, piuttosto che lasciarli decadere silenziosamente dietro una metrica di numero di pagine elevato).
Cosa monitorare invece
La risposta onesta alla domanda "il nostro investimento nell'AI sta dando i suoi frutti?" non può essere letta da un cruscotto di fatturazione.
Si può approssimare con domande migliori: i tempi di ciclo stanno migliorando? Il rapporto tra le funzionalità consegnate e i bug segnalati è in tendenza nella giusta direzione? Gli ingegneri riferiscono di dedicare più tempo al lavoro di valutazione e meno alla digitazione? La sua documentazione rimane attuale invece di accumularsi come un sedimento?
Questi dati sono più difficili da ricavare da un'API. Richiedono di pensare a quali risultati vuole effettivamente dai suoi team, il che, è vero, è il lavoro più difficile. Ma sono le domande che contano, perché riguardano i risultati piuttosto che gli input.
La spesa in gettoni indica la quantità di calcolo acquistata. Se quel calcolo è diventato qualcosa di utile è una questione completamente separata. Le aziende che non mantengono questa distinzione costruiranno dashboard molto costosi che non mostreranno quasi nulla.
Abbiamo passato anni a ottimizzare la metrica sbagliata per la produttività degli sviluppatori. Abbiamo forse un trimestre prima che lo stesso errore venga inserito in tutti i rapporti sull'adozione dell'AI nelle aziende. La finestra per evitarlo è aperta, ma non rimarrà tale.