Lavora Anche la Domenica

È domenica. E stai lavorando.

Non perché il capo te l'ha chiesto. Non perché c'è una deadline. Stai lavorando perché hai avuto un'idea sotto la doccia e sai che con un paio di prompt puoi avere un prototipo funzionante prima di cena. Il costo percepito è zero: apri il laptop, lanci l'agente, guardi il codice che si materializza.

Quentin Rousseau, sviluppatore, ha raccontato di non riuscire a chiudere il laptop prima delle due di notte. Per mesi. Ha dovuto farsi prescrivere farmaci per dormire. Garry Tan, CEO di Y Combinator, ha ammesso pubblicamente di restare sveglio oltre 19 ore a programmare con agenti AI fino alle cinque del mattino.

Non è overwork nel senso classico. È qualcosa di nuovo, e non abbiamo ancora un nome preciso per descriverlo.

I due cuori di Max Schwarzmueller

Max Schwarzmueller insegna programmazione a oltre tre milioni di studenti. Non è un commentatore da tastiera — è uno che ci vive, ogni giorno, dentro il codice e dentro la didattica. In un video recente ha detto una cosa che risuona con molti: "I have two hearts pounding in my chest when it comes to AI."

Da una parte sa che l'AI è qui per restare. Dall'altra, racconta con trasparenza rara che il lavoro si è spostato sulle parti che non sono mai state divertenti: scrivere specifiche, revisionare output, fare steering, controllare. "My work has shifted to the parts that were never fun." Il flow — quella concentrazione profonda dove le ore passano senza accorgertene — è evaporato.

Siddhant Khare, research engineer, lo riassume con una frase che molti sviluppatori riconosceranno: "Creating is energizing. Reviewing is draining." Ha spedito più codice nell'ultimo trimestre che in qualsiasi trimestre della sua carriera. E si è sentito più svuotato che in qualsiasi trimestre della sua carriera.

C'è un paradosso qui dentro. Produci di più, ma senti di meno. Il codice esce, le feature si chiudono, i commit si accumulano. Ma quella scintilla — il momento in cui trovi il bug, capisci il pattern, fai funzionare qualcosa che prima non funzionava — quella si è affievolita.

Il divertimento di chi capisce

E poi c'è Kent Beck.

Beck ha 52 anni di esperienza nella programmazione. Ha inventato TDD, Extreme Programming, ha scritto libri che hanno formato generazioni di sviluppatori. A un certo punto, confessa, stava perdendo entusiasmo. Imparare continuamente nuovi linguaggi e framework era diventato faticoso.

Poi sono arrivati gli agenti AI. E Beck ha ritrovato la passione.

Sta costruendo un server Smalltalk e un'implementazione LSP — progetti che desiderava da anni, mai fattibili perché richiedevano settimane di lavoro tedioso su tecnologie che non padroneggiava in dettaglio. Ora li sta realizzando. "The whole landscape of what's cheap and what's expensive has all just shifted", dice.

Come si spiegano due reazioni così opposte? Schwarzmueller che perde il divertimento, Beck che lo ritrova?

Una possibile lettura: Beck sa esattamente cosa vuole costruire. Ha un modello mentale completo dell'architettura prima ancora di scrivere il primo prompt. L'agente AI per lui è uno strumento che esegue la sua visione — come un pennello più preciso per un pittore che sa già cosa dipingere. Non deve lottare per capire l'output, perché l'output lo ha già in testa.

Per chi è in una zona diversa — esperto abbastanza da sapere che il codice generato va verificato, ma non così padrone da verificarlo in un colpo d'occhio — il lavoro si trasforma in un ciclo estenuante di review, correzione, ri-prompt, ri-review. Le parti noiose, senza le parti belle.

La trappola del "one more prompt"

C'è un meccanismo psicologico preciso dietro il laptop aperto alle due di notte. Si chiama variable ratio reinforcement — lo stesso principio che rende le slot machine così efficaci.

Ogni volta che lanci un agente su un task, il risultato è imprevedibile. A volte è perfetto al primo colpo. A volte è un disastro. A volte — e questa è la parte insidiosa — è quasi giusto, manca solo un dettaglio, un altro prompt e ci siamo. Quel "quasi" tiene il cervello agganciato.

Garry Tan lo ha descritto con una trasparenza disarmante: "The machines can search the space and sometimes it has a Eureka moment. It is dopamine-wise as rewarding as finding it yourself manually sometimes!" Steve Yegge va oltre: "Agentic coding is addictive. You will hear it more and more often, because it bewitches people once they've got the hang of it."

La differenza con l'overwork tradizionale è strutturale. Programmare manualmente ha una frizione naturale: la fatica mentale del ragionamento, i tempi di compilazione, il debugging che richiede concentrazione profonda. Sono limiti, ma sono anche protezioni. Punti di stop naturali dove il cervello dice "basta per oggi".

L'agentic coding elimina quei punti di stop. Il costo percepito di un prompt è quasi zero. L'effetto spettatore — guardare l'agente che lavora — sembra rilassante anche quando in realtà tiene il cervello in stato di allerta. E il branching infinito delle possibilità elimina il momento naturale in cui normalmente chiuderesti il laptop.

Tao Bojlén, un altro sviluppatore che ha scritto sul tema, traccia una distinzione utile: la differenza tra yearning — il desiderio creativo di lungo termine, quel "voglio costruire questa cosa" — e craving — il bisogno immediato, discreto, mai soddisfatto. L'agentic coding allaga il cervello di dopamina a basso costo. E la dopamina a basso costo è la definizione stessa di craving.

Le cose impossibili

Ma sarebbe intellettualmente disonesto fermarsi qui. Perché l'AI ha aperto porte che prima erano chiuse.

Pieter Levels ha costruito un simulatore di volo MMO in circa tre ore con Cursor. Genera oltre 50.000 dollari al mese. Portfolio complessivo: 3.1 milioni di ricavo annuo, zero dipendenti.

Il 25% delle startup nell'ultimo batch di Y Combinator ha codebase al 95% generate da AI. I founder sono tecnici capaci di scrivere tutto da zero — semplicemente non ne hanno bisogno. Il batch cresce del 10% a settimana.

Andrej Karpathy crea applicazioni "usa e getta" — codice effimero, costruito per risolvere un singolo problema e poi scartato. "Free, ephemeral, malleable, discardable after single use." È un modo completamente nuovo di pensare al codice: non come asset da mantenere, ma come strumento monouso.

Un CTO ha raccontato di aver messo Claude Code a lavorare su un hobby project mentre era in vacanza con la famiglia. Un task da quattro ore completato in due minuti, con codice migliore di quello che avrebbe scritto lui. Il weekend project — quello che prima richiedeva settimane, relegato al "un giorno lo faccio" — ora è realistico. Davvero.

Freelancer che con agenti AI erogano l'output di un team da venti persone. Sviluppatori che passano da 150.000 a 720.000 dollari l'anno di fatturato. Il 77% dei freelancer usa tool AI, e chi li usa guadagna il 40% in più all'ora.

Le possibilità sono reali. La domanda è cosa succede al confine tra "posso" e "dovrei".

Lo stress che cambia forma

Harvard Business Review ha pubblicato a marzo 2026 un'analisi su quello che chiamano "brain fry". Il 14% dei lavoratori che usano AI ne è colpito. Chi lo sperimenta riporta il 33% in più di decision fatigue e il 39% in più di errori gravi.

Il dato più controintuitivo: la produttività sale con uno, due, tre tool AI simultanei. Poi crolla. Dopo tre strumenti, il multitasking diventa inefficiente e l'affaticamento mentale supera i benefici.

Non è meno fatica. È fatica diversa.

Lo studio Multitudes, citato da Scientific American, ha misurato un aumento del 27% nelle pull request mergiate tra gli sviluppatori che usano AI. Ma anche un aumento del 19.6% nei commit fuori orario. Più output, più ore. Non meno.

UC Berkeley ha trovato lo stesso pattern: dopo l'adozione di tool AI, i dipendenti di un'azienda tech hanno preso più task, lavorato a ritmo più veloce, e lavorato più ore. L'AI si espande nelle pause pranzo, nei meeting, nei tempi morti. Ogni spazio vuoto diventa uno spazio riempibile.

Addy Osmani ha dato un nome a una parte specifica di questo fenomeno: "comprehension debt". Il gap crescente tra quanto codice esiste nel sistema e quanto ne capisce effettivamente un essere umano. L'AI genera codice molto più veloce di quanto i dev riescano ad assorbirlo. Il debito si accumula, invisibile, come il debito tecnico nel codice. Ma peggio, perché il debito tecnico lo vedi quando qualcosa si rompe. Il debito di comprensione lo scopri quando qualcosa si rompe e non capisci perché.

L'ownership e la metafora della canzone

C'è una riflessione che circola tra gli sviluppatori e che va oltre la produttività. Ha a che fare con il senso di proprietà.

"You didn't fight for it. You didn't suffer." Quando l'AI elimina la difficoltà, il codice risultante sembra vuoto nonostante funzioni. Qualcuno lo paragona a giocare un videogioco con munizioni infinite e god mode: tecnicamente stai vincendo, emotivamente non stai giocando.

Karpathy lo descrive da un'altra angolazione: "It feels like I'm cheating. Which is a very weird feeling to have. It's because some code that used to be a point of pride and high IQ and knowledge is suddenly free and instant and it's very disorienting."

Eppure. Pensiamo alla musica. Oggi puoi creare una canzone con strumenti AI — generare melodie, arrangiamenti, testi. Se quella canzone ti emoziona quando la ascolti, se esprime quello che volevi esprimere, è tua? Qualcuno dirà di no: non l'hai suonata, non l'hai composta nota per nota. Ma se l'idea era tua, se la direzione era tua, se il gusto che ha plasmato ogni scelta era tuo — è difficile dire che non ti appartiene.

L'ownership forse non dipende dai keystroke. Dipende dalla consapevolezza. Kent Beck non si sente meno proprietario del suo server Smalltalk perché un agente ha scritto il codice. Sa esattamente cosa fa ogni parte del sistema, perché ha deciso lui cosa costruire e come. L'agente è il braccio, lui è il cervello.

Per chi non ha quella consapevolezza, il discorso è diverso. E onestamente, è lì che il disagio di Schwarzmueller ha radici profonde: non nell'AI in sé, ma nella sensazione di non avere il controllo completo su ciò che esce.

Il paradosso della percezione

Stack Overflow 2025 conferma un disagio diffuso: l'80% degli sviluppatori usa tool AI, ma la fiducia nell'accuratezza è crollata dal 40% al 29%. Il 46% non si fida attivamente. Solo il 3% dichiara alta fiducia. La frustrazione numero uno, citata dal 66% dei dev: "Soluzioni AI quasi giuste, ma non del tutto."

Quasi giuste. Di nuovo quel "quasi" che tiene agganciati. Un altro prompt e ci siamo. Forse.

È un dato che dovrebbe far riflettere chiunque apra il laptop la domenica convinto di "fare in fretta con l'AI". Forse stai facendo in fretta. Forse stai solo percependo di fare in fretta mentre il ciclo prompt-review-correzione-riprompt ti sta mangiando più tempo di quanto pensi.

Come ti senti a fine giornata

C'è una sfumatura che i numeri globali catturano bene. La maggior parte degli sviluppatori usa tool AI, ma il 76% rifiuta il vibe coding — la programmazione interamente delegata all'AI. Solo il 3.1% dichiara alta fiducia nelle soluzioni generate. La community dev sembra avere un rapporto cauto, forse più sano di quanto sembri, con questi strumenti.

Ma la tendenza è la stessa ovunque: l'AI ha rimosso i governatori naturali della velocità umana. I tempi di compilazione, la fatica fisica dello scrivere, il debugging manuale che richiedeva pause — erano limiti, ma erano anche protezioni. L'AI li ha eliminati. Il risultato non è meno lavoro. È lavoro senza confine, dove l'unico limite è la resistenza cognitiva.

La vera domanda non è "l'AI mi rende più produttivo?". È più sottile. È "l'AI mi fa lavorare di più pensando di lavorare meno?"

I dati suggeriscono che per molti la risposta è sì. Più commit fuori orario. Più ore totali. Più output, ma anche più drain cognitivo, più errori gravi tra chi è affaticato, più difficoltà a staccare.

Per altri — quelli che sanno cosa stanno costruendo, che hanno un modello mentale solido, che usano l'AI come esecutore della propria visione — la risposta è diversa. Producono di più e si divertono di più. Non perché l'AI è magica, ma perché la combinazione di esperienza profonda e strumenti potenti è effettivamente qualcosa di nuovo. Qualcosa che prima non esisteva.

Il confine tra le due esperienze è sottile. E probabilmente cambia giorno per giorno, progetto per progetto. Lo stesso sviluppatore può sentirsi Kent Beck al mattino e Schwarzmueller al pomeriggio.

È domenica sera. Il laptop è ancora aperto. La domanda non è quanto hai prodotto. È come ti senti adesso che lo chiudi.

Se lo chiudi.

Fonti: