Burnout da Agenti AI: Più Veloci, Più Esauriti

"I can fire up four agents in parallel to work on different problems, but by 11 a.m., I am wiped out for the day."

Simon Willison ha 25 anni di esperienza. Ha co-creato Django. Non è uno che si stanca facilmente. Eppure alle undici del mattino, dopo aver orchestrato quattro agenti in parallelo, è cotto. Finito. Niente di utile uscirà da quella giornata dopo le undici.

Dall'altra parte, Andrej Karpathy non scrive una riga di codice a mano da dicembre 2025. Lavora sedici ore al giorno dando istruzioni ad agenti AI. Si descrive "in the state of psychosis" — e non lo dice come metafora. Lo dice come chi si e guardato allo specchio e ha riconosciuto qualcosa di familiare.

Due tra le menti più rispettate del settore. Uno è esausto. L'altro è in trance. Entrambi stanno lavorando più di prima.

I numeri dietro la sensazione

La sensazione di "qualcosa non torna" ha trovato conferma nei dati a marzo 2026. Lo studio BCG Henderson Institute, pubblicato su Harvard Business Review, ha analizzato 1.488 lavoratori full-time negli Stati Uniti. I risultati sono un pugno nello stomaco.

Il 14% degli utenti AI riporta quello che i ricercatori hanno chiamato brain fry — sovraccarico cognitivo persistente. Chi ne è colpito mostra numeri che dovrebbero far riflettere qualsiasi team lead:

Effetto	Variazione
Decision fatigue	+33%
Errori gravi	+39%
Intenzione di lasciare il lavoro	+39%
Sovraccarico informativo	+19%
Sforzo mentale	+14%

Non errori minori. Errori gravi. Da persone che dovrebbero essere più produttive grazie all'AI.

E il dato che ribalta la narrativa: non è l'uso dell'AI a causare il brain fry. È la supervisione dell'AI. Quando l'AI sostituisce task ripetitivi — quelli noiosi, meccanici — il burnout cala del 15%. Quando l'AI genera output che l'umano deve revisionare, validare, correggere, il burnout esplode.

Perché supervisionare stanca più che scrivere

Siddhant Khare, maintainer di OpenFGA, ha scritto un post che è arrivato primo su Hacker News. Una frase riassume tutto: "I shipped more code last quarter than any quarter in my career. I also felt more drained than any quarter in my career."

Il meccanismo è controintuitivo ma semplice. Scrivere codice è un atto creativo. Hai il contesto in testa, conosci ogni riga, sai perché hai fatto quella scelta. Revisionare codice scritto da qualcun altro — o da qualcosa altro — è un atto di sorveglianza. Ogni riga è sospetta. Ogni funzione potrebbe nascondere un bug sottile, una hallucination ben mascherata.

"Creating is energizing. Reviewing is draining", lo dice Khare. E lo sente chiunque abbia passato un pomeriggio a inseguire un bug in codice AI che sembrava perfetto ma non lo era.

C'e poi il problema del context switching. Prima dell'AI, un dev poteva passare una giornata intera su un problema di design. Concentrazione profonda, flusso, quella cosa che Csikszentmihalyi chiama flow. Ora? Con gli agenti, puoi toccare sei problemi diversi in un giorno. Ognuno richiede un'ora. Ma il costo cognitivo di saltare tra sei contesti diversi è brutale. L'AI riduce il costo di produzione e aumenta il costo di coordinamento. E quel costo ricade interamente sull'umano.

L'effetto slot machine

C'e un motivo preciso per cui Yegge si forza a chiudere il laptop entro le due di notte. Per cui Rousseau ha avuto bisogno di farmaci per dormire. Per cui Garry Tan, CEO di Y Combinator, resta sveglio diciannove ore e lo racconta su X come fosse un badge d'onore.

Il motivo si chiama variable ratio reinforcement — lo stesso principio che rende le slot machine così efficaci.

Ogni prompt è una leva. A volte il risultato è perfetto. A volte è un disastro. A volte — e qui si aggancia il cervello — è quasi giusto. Un altro prompt e ci siamo. Forse. Il 45% degli sviluppatori nel survey Stack Overflow 2025 cita le soluzioni "quasi giuste ma non del tutto" come frustrazione principale dell'AI coding. Quel "quasi" è il gancio.

Yegge lo descrive senza filtri: "Lots of dopamine and adrenaline, and what's more, over time, your outcomes are even improving." E poi: "I have to run a practiced escape plan every night to get my computer closed by 2am." Un piano di fuga. Dal proprio laptop.

Il blog fast.ai ha applicato al vibe coding un concetto nato nella ricerca sulle dipendenze da gioco d'azzardo: dark flow. O "junk flow", termine usato da Csikszentmihalyi. La differenza con il flow autentico è cruciale. Nel flow vero, la sfida corrisponde alle competenze, il feedback è chiaro, cresci. Nel junk flow, il feedback è ambiguo (il codice sembra funzionare ma scoprirai i problemi settimane dopo), la sensazione di controllo è falsa, e non cresci — ti dreni.

Le slot machine hanno un concetto chiamato Losses Disguised as Wins: premiano 15 centesimi su una scommessa di 20 con suoni di vittoria. Il vibe coding fa la stessa cosa. Masse di codice che sembrano produttive. Commit che sembrano progresso. Ma sotto la superficie, la fiducia nel codice è in caduta libera.

Il paradosso della produttività

Il report Multitudes 2026 ha misurato oltre 500 sviluppatori. I pull request mergiati sono cresciuti del 27%. Ma i commit fuori orario sono cresciuti del 19.6%.

Lauren Peate, CEO di Multitudes, non gira intorno al problema: "Se il lavoro fuori orario aumenta, non fa bene alla persona. Porta al burnout."

E il paradosso che abbiamo già visto con l'AI che cambia gli orari di lavoro. L'AI non libera tempo. Riempie il tempo liberato con altro lavoro.

Lo studio UC Berkeley pubblicato su HBR ha osservato circa 200 dipendenti tech per otto mesi. Tre forme di intensificazione documentate:

Task expansion — ti assumi responsabilità altrui. Il PM scrive codice. Il ricercatore fa engineering. Se puoi, fai.
Confini lavoro-vita dissolti — l'AI si usa durante il pranzo, le pause, i meeting. Ogni spazio vuoto diventa uno spazio riempibile.
Multitasking aumentato — thread multipli simultanei, switching continuo tra agenti e task.

Un ingegnere intervistato riassume: "Pensavi che essendo più produttivo con l'AI avresti lavorato meno. Ma non lavori meno. Lavori uguale o anche di più."

Le voci dal fronte

Non sono solo Willison e Karpathy. Il pattern è diffuso, e chi ne parla apertamente sta facendo un servizio a tutta la community.

Armin Ronacher, creatore di Flask, a gennaio ha pubblicato un post intitolato "Agent Psychosis": "Many of us got hit by the agent coding addiction. It feels good, we barely sleep, we build amazing things." Ha passato due mesi a promptare compulsivamente, senza dormire. Poi si è fermato a guardare il panorama: "I see someone who might need to step away from the machine for a bit. And I wonder how often that someone is me."

Quentin Rousseau, CTO di Rootly, ha avuto mesi di insonnia dopo il passaggio ad agentic coding. Ha dovuto farsi prescrivere farmaci. Nel suo post paragona gli strumenti alle slot machine — il ciclo prompt-risultato-riprompt segue lo stesso schema di rinforzo variabile che tiene i giocatori attaccati alle macchinette.

E poi c'è Garry Tan che twitta "So addicted to Claude Code, I stayed up 19 hours yesterday" come se fosse una cosa di cui andare fieri. Nostalgia dei tempi della gioventù. Aspirazionale. Il modello dell'industria software ha sempre avuto problemi con la glorificazione del crunch — l'AI li sta amplificando.

"Posso fare 10x" vs "Devo fare 10x"

Qui sta il punto di rottura.

Quando scopri che con gli agenti puoi spedire il triplo del codice in meta del tempo, la prima reazione è euforia. Puoi fare cose impossibili. Weekend project che prima richiedevano settimane, ora li finisci in un pomeriggio. Feature che avevi nel backlog da mesi, ora le chiudi tra un meeting e l'altro.

Il problema è quando quell'euforia diventa aspettativa. Quando il team si abitua a quel ritmo. Quando il manager vede i numeri e alza l'asticella. Quando tu stesso non riesci più a giustificare una giornata dove hai "solo" scritto codice pensato, progettato, ragionato — perché l'agente avrebbe potuto spedire venti commit in quel tempo.

Khare lo sintetizza: "When each task takes less time, you don't do fewer tasks. You do more tasks."

La produttività non ti libera. Ti ridefinisce il baseline. E una volta che il baseline sale, tornare indietro sembra un fallimento anche quando è la cosa giusta da fare.

Karpathy lavora sedici ore al giorno e lo ammette senza imbarazzo. Ma Karpathy ha scelto quel ritmo. La domanda è: quanti sviluppatori si ritroveranno quel ritmo imposto?

High-functioning burnout

Ecco perché questo burnout è diverso da quelli che conosciamo. E il tipo più pericoloso: quello che non riconosci.

I numeri sono buoni. Le PR escono. I ticket si chiudono. Il throughput individuale è ai massimi storici. Dall'esterno — e spesso anche dall'interno — sembra che tutto funzioni. I KPI brillano.

Ma sotto la superficie: decision fatigue cronica, sonno compromesso, motivazione che si erode, quella scintilla creativa che si affievolisce. Non hai più il tempo di pensare in profondita perché c'e sempre un altro task che l'agente potrebbe iniziare. Non hai più il piacere di risolvere un problema difficile perché l'agente lo risolve per te — e tu devi solo verificare che l'abbia fatto bene.

Anthropic stessa ha trovato che i dev assistiti da AI ottengono punteggi 17% più bassi nei quiz di conoscenza. Il muscolo del problem solving si atrofizza. Non perché l'AI sia cattiva, ma perché la delega sistematica della parte difficile elimina l'esercizio che ti tiene affilato.

Il survey DevOps 2026 conferma: il 65% dei professionisti sperimenta burnout nonostante l'adozione di AI. Nonostante — o forse a causa di.

Cosa fare, in pratica

Non serve un manifesto. Servono regole operative.

La regola dei tre tentativi. Khare la usa quotidianamente: se l'AI non arriva al 70% della soluzione in tre prompt, scrivi tu. Smetti di inseguire il "quasi giusto". Quel ciclo di ri-prompt è il cuore del junk flow.

Mattine senza agenti. Khare dedica la prima ora della giornata a lavorare senza AI — "I deliberately spend the first hour of my day without AI." Sembra controintuitivo: rinunci a produttività nelle ore migliori. Ma se quelle ore ti mantengono la capacità di supervisionare il codice AI nel pomeriggio, il trade-off è positivo.

Il piano di fuga serale. Se Yegge ha bisogno di una routine deliberata per chiudere il laptop alle due di notte, forse ne hai bisogno anche tu. La frizione zero dell'agentic coding elimina i punti di stop naturali. Devi ricrearli artificialmente.

Limitare i tool simultanei. I dati BCG sono chiari: la produttività sale fino a tre strumenti AI contemporanei. Oltre tre, crolla. Se stai orchestrando cinque agenti in parallelo, non stai lavorando cinque volte più veloce. Stai bruciando cinque volte più in fretta.

Fare fare, non fare guardare. La scoperta chiave dello studio BCG: quando l'AI sostituisce task ripetitivi, il burnout cala. Quando l'AI genera output da revisionare, il burnout esplode. La differenza è sottile ma cruciale. Usa l'AI per automatizzare il noioso — test, refactoring meccanico, boilerplate. Non per generare architetture che poi devi validare riga per riga. Un buon framework di harness engineering aiuta a trovare quel confine.

Il supporto organizzativo conta. Lo studio BCG mostra che il supporto manageriale sulle questioni AI riduce la fatica mentale del 15%. Non è solo un problema individuale. Se il tuo team non ha una conversazione aperta su ritmi, aspettative e limiti, la sta avendo nel modo peggiore: con le dimissioni. Quel +39% di intenzione di lasciare il lavoro non è un numero astratto.

Il vero costo della velocità

Ronacher ha scritto una cosa che vale la pena rileggere: "Two things are both true to me right now: AI agents are amazing and a huge productivity boost. They are also massive slop machines if you turn off your brain and let go completely."

Non è un aut-aut. Non è "l'AI fa male" contro "l'AI e il futuro". E più complicato di così. Gli agenti AI sono lo strumento più potente che gli sviluppatori abbiano mai avuto. E come ogni strumento potente, possono tagliare in entrambe le direzioni.

Il burnout da agenti AI non è inevitabile. Ma ignorarlo è pericoloso. Willison lo dice con la lucidita di chi ha capito il problema: "There's a personal skill we have to learn in finding our new limits — what's a responsible way for us not to burn out."

Trovare i nuovi limiti. Non quelli del codice — quelli li trovano gli agenti. I tuoi.

Fonti: