In sette giorni Codex ha elaborato per me 65 miliardi di token. Non significa che abbia prodotto 65 miliardi di token di valore, ma dice qualcosa sul modo in cui gli agenti stanno cambiando la durata e l’intensità del lavoro.
Qualche settimana fa ho installato Who Burned More, un piccolo strumento open source che legge i registri locali lasciati da Codex, Claude Code, Gemini CLI e dagli altri coding agent, calcola i token utilizzati e ne stima il costo sulla base dei prezzi pubblici dei diversi modelli. Il progetto è nato principalmente come una classifica, per confrontare il proprio consumo con quello di altri sviluppatori, ma nel mio caso ha finito per mostrarmi qualcosa che non stavo realmente cercando. (whoburnedmore.com)
Quando ho controllato i dati, il 12 agosto 2026, Codex aveva elaborato per me circa 65 miliardi di token negli ultimi sette giorni, con un costo equivalente stimato di quasi 45.000 dollari americani.
Naturalmente, e ci mancherebbe pure, non ho pagato quella cifra. Utilizzo Codex attraverso un abbonamento e il valore mostrato da Who Burned More rappresenta una stima di quanto lo stesso traffico sarebbe costato applicando le tariffe pubbliche dei modelli. Il calcolo distingue input, output, cache write e cache read, perché ciascuna categoria ha un prezzo differente; anche OpenAI precisa che il consumo effettivo dipende dal modello utilizzato e dalla proporzione tra token in ingresso, token già presenti nella cache e token prodotti in uscita.
La cifra economica non è quindi una fattura, ma rimane utile per capire la quantità di elaborazione che si è sviluppata attorno al mio lavoro.
Sessantacinque miliardi di token in una settimana significano più di nove miliardi al giorno. OpenAI utilizza come regola molto approssimativa per la lingua inglese un rapporto di circa tre quarti di parola per token; applicandolo meccanicamente, arriveremmo a quasi 49 miliardi di parole. È un paragone puramente indicativo, perché nei log di Codex rientrano codice, istruzioni di sistema, contesti caricati ripetutamente, file già presenti nella cache, output e altre informazioni che non possono essere convertite semplicemente in pagine lette o scritte. Serve però a dare una dimensione a un numero che, altrimenti, rimarrebbe completamente astratto.
Anche il confronto con gli altri utenti di Who Burned More è interessante, purché non venga scambiato per un benchmark scientifico. Il suo indice pubblico contiene attualmente circa 2,03 trilioni di token prodotti da 216 sviluppatori, con una media cumulativa di 9,39 miliardi per partecipante. La mia sola ultima settimana corrisponde quindi a quasi sette volte quella media, anche se ogni utente possiede una cronologia differente e non sappiamo per quanto tempo abbia utilizzato gli strumenti prima di entrare nella classifica.
Quel numero non dimostra che io abbia prodotto sette volte più valore di un altro sviluppatore. Non dimostra neppure che abbia lavorato sette volte meglio.
Mostra, però, quanto lavoro automatico sia stato continuamente avviato, seguito, corretto e rilanciato attorno a una sola persona.
Ed è proprio questo il punto.
Il momento nel quale avrei dovuto smettere
Da quando utilizzo regolarmente Codex e Claude Code, mi sono accorto che il cambiamento più evidente non riguarda soltanto ciò che riesco a costruire, ma il momento nel quale smetto di lavorare.
Prima dei coding agent esisteva una certa resistenza naturale all’inizio di una nuova attività. Se alle undici di sera mi veniva in mente una modifica, sapevo che avrei dovuto riaprire il progetto, ricostruire il contesto, scrivere il codice, eseguire i test e probabilmente dedicare al problema almeno un’altra ora. Nella maggior parte dei casi prendevo nota e rimandavo al giorno successivo.
Oggi basta descrivere la modifica a Codex e premere Invio. La parte più pesante sembra affidata alla macchina, quindi non ho la sensazione di cominciare una nuova sessione di lavoro. Mi dico che devo soltanto lasciarlo procedere e vedere come va a finire.
Il problema è che vedere come va a finire continua a essere lavoro.
Codex completa la modifica, ma un test fallisce. Gli chiedo di analizzarlo. Trova il problema, lo corregge e a quel punto voglio controllare anche un altro caso. Nel frattempo noto una parte del codice che potrebbe essere migliorata e avvio un’altra esecuzione, magari affidando contemporaneamente un secondo compito a un altro agente.
Ogni singolo passaggio sembra troppo piccolo per giustificare la chiusura del computer. Quando finalmente guardo l’orologio, però, è passata un’altra ora.
I 65 miliardi di token non misurano direttamente il tempo che ho trascorso davanti allo schermo, perché più agenti possono lavorare in parallelo e gran parte di quei token viene elaborata senza un mio intervento. Rendono però visibile la continuità del processo: per arrivare a quella quantità di attività ho continuato ad aprire task, verificarne i risultati, correggere la direzione e avviare il passaggio successivo durante giorni che non avevano più un confine particolarmente chiaro.
L’AI non si è limitata a farmi svolgere più velocemente il lavoro che avrei comunque svolto.
Ha reso possibile continuare a lavorare anche quando non avrei più avuto l’energia necessaria per farlo direttamente.
La produttività che riempie tutto il tempo disponibile
Quando si parla dei vantaggi dell’intelligenza artificiale, si tende a immaginare un’attività dalle dimensioni fisse. Prima richiedeva quattro ore, adesso ne richiede due, quindi abbiamo risparmiato due ore.
Nello sviluppo software, però, quelle due ore raramente rimangono vuote. Vengono utilizzate per aggiungere una funzionalità, provare un’alternativa, migliorare l’interfaccia, sistemare un problema rimasto aperto oppure iniziare qualcosa che fino al giorno prima sembrava troppo impegnativo.
L’AI non produce necessariamente tempo libero. Produce capacità aggiuntiva, e quella capacità viene quasi sempre reinvestita.
Nel 2025 METR pubblicò uno studio controllato nel quale sedici sviluppatori open source esperti lavorarono su 246 attività reali all’interno di repository che conoscevano bene. Prima dell’esperimento prevedevano che l’AI li avrebbe resi più veloci del 24% e, anche dopo aver completato il lavoro, continuarono a credere di avere risparmiato circa il 20% del tempo. Le misurazioni mostrarono invece che, nelle condizioni specifiche dello studio e con gli strumenti disponibili all’inizio del 2025, avevano impiegato mediamente il 19% in più.
Questo non dimostra che gli strumenti attuali rallentino gli sviluppatori. I modelli sono migliorati, lo studio riguardava codebase mature e il campione era limitato. Mostra però quanto possa essere grande la distanza tra la sensazione di procedere velocemente e il tempo realmente utilizzato.
Nel febbraio 2026 METR cercò di ripetere l’esperimento con strumenti più recenti, ma incontrò un problema ancora più interessante. Molti sviluppatori non volevano partecipare se correvano il rischio di dover svolgere una parte delle attività senza AI, mentre altri utilizzavano più agenti contemporaneamente oppure passavano a un altro compito durante l’esecuzione. A quel punto diventava difficile persino attribuire il tempo a una singola attività.
Il vecchio modello prevedeva una persona, un compito e un cronometro. Oggi posso affidare una modifica a Codex, una seconda a Claude Code e nel frattempo controllare il risultato di una terza esecuzione. Posso impiegare cinque minuti per preparare una richiesta, lasciare lavorare l’agente per mezz’ora e poi dedicare altri dieci minuti alla revisione.
Quanto ho lavorato: quindici minuti oppure quarantacinque?
E come misuriamo il tempo nel quale sto facendo apparentemente altro, ma continuo a controllare la finestra, aspetto una notifica oppure mantengo nella mente il problema che dovrò verificare appena l’agente avrà terminato?
La telemetria può misurare l’attività della macchina. Molto più difficilmente riesce a misurare lo spazio mentale che quella macchina continua a occupare.
Vedere come va a finire
A rendere difficile interrompere il lavoro non è soltanto l’aumento della capacità produttiva. Esiste anche la curiosità generata da un risultato che appare vicino, ma rimane incerto.
Quando lancio Codex non so esattamente che cosa otterrò. Potrebbe risolvere il problema, trovare un errore che non avevo considerato, modificare la parte sbagliata oppure arrivare abbastanza vicino alla soluzione da farmi pensare che basti ancora un piccolo aggiustamento.
Qualunque sia il risultato, esiste quasi sempre una ragione per avviare un’altra esecuzione.
Si potrebbe descrivere questa sensazione come una piccola scarica di dopamina, anche se sarebbe scorretto sostenere che qualcuno abbia già misurato direttamente la risposta cerebrale di uno sviluppatore mentre aspetta la conclusione di una sessione di Codex. Sappiamo però che i segnali dopaminergici partecipano all’anticipazione della ricompensa e rispondono anche alla probabilità e all’incertezza del risultato. È quindi plausibile che la sequenza composta da attesa, esito incerto, piccola soddisfazione e nuovo tentativo contribuisca a rendere il ciclo difficile da interrompere, ma rimane un’inferenza e non una conclusione specificamente dimostrata sui coding agent.
Il meccanismo, dal punto di vista dell’esperienza, è comunque riconoscibile. Se il risultato è ottimo, voglio vedere fino a dove posso arrivare. Se è quasi corretto, voglio completarlo. Se è sbagliato, voglio capire perché.
Il pulsante per continuare è sempre a pochi secondi di distanza.
Che cosa stiamo realmente misurando?
Who Burned More pone, con un tono volutamente giocoso, una domanda che descrive bene questa fase dello sviluppo assistito dall’AI: chi ha bruciato più token?
È un dato interessante e può essere utile per comprendere il consumo dei diversi modelli, ma non misura direttamente la qualità del lavoro. Sessantacinque miliardi di token possono rappresentare un’enorme quantità di attività utile, ma anche contesti caricati più volte, tentativi falliti, agenti inviati nella direzione sbagliata, modifiche successivamente eliminate oppure codice che qualcun altro dovrà ancora comprendere e mantenere.
Il contatore sale in tutti questi casi.
È lo stesso problema che abbiamo già incontrato con le righe di codice, i commit e i ticket chiusi. Sono dati facili da raccogliere e difficili da collegare al valore, ma proprio perché sono visibili finiscono per diventare ciò che osserviamo e confrontiamo.
Per capire se l’AI mi abbia realmente reso più produttivo, dovrei misurare non soltanto la quantità di codice prodotta o il tempo necessario per arrivare alla prima soluzione, ma anche il tempo impiegato per preparare le istruzioni, controllare gli agenti, revisionare il risultato, correggere gli errori e mantenere ciò che è stato costruito. Dovrei inoltre considerare quanta parte di quel lavoro sia entrata nella sera, nel fine settimana o nei momenti che prima non avrei dedicato allo sviluppo.
Sicuramente scoprirei di avere prodotto molto più software. Non necessariamente di avere risparmiato tempo.
Più produttivo, ma non più libero
Non ho dubbi sul fatto che Codex e gli altri coding agent abbiano aumentato ciò che sono in grado di realizzare. Posso esplorare più soluzioni, occuparmi di parti del progetto che avrebbero richiesto competenze aggiuntive e portare avanti contemporaneamente attività che prima avrei dovuto eseguire una alla volta.
I 65 miliardi di token dell’ultima settimana ne sono una dimostrazione, ma sono anche un avvertimento.
Una quantità di elaborazione del genere non sarebbe esistita senza la possibilità di lasciare lavorare gli agenti continuamente, avviarne più di uno e proseguire con un’altra iterazione anche quando la mia normale giornata avrebbe dovuto essere terminata. La tecnologia mi ha permesso di produrre di più, ma ha anche abbassato quasi a zero il costo percepito di continuare.
La domanda non è quindi soltanto se l’AI ci renda più produttivi. È chi riceva il tempo che dovrebbe farci risparmiare.
Se ogni ora liberata viene immediatamente occupata da un altro task, se ogni risultato ci spinge ad aspettare quello successivo e se la giornata termina soltanto quando non abbiamo più la forza di controllare un’altra esecuzione, l’AI avrà certamente aumentato il nostro output, ma non ci avrà restituito tempo.
Forse il benchmark che manca ai coding agent non dovrebbe misurare soltanto quanto lavoro riescono a completare.
Dovrebbe misurare anche se, mentre loro continuano a lavorare, noi riusciamo ancora a chiudere il computer.