Insegna al neon arancione con la scritta "AI" su una parete scura decorata come un circuito stampato.

IA: l'illusione della produttività - Il problema dello stato di flow

Nel primo articolo di questa serie, IA: l'illusione della produttività, abbiamo esplorato il divario tra sentirsi produttivi grazie all’IA ed esserlo davvero. Questa volta analizzeremo cosa si nasconde dietro quel divario: il problema dello stato di flow. Revisionare codice generato da IA richiede un’attenzione più focalizzatarispetto a quella che serve per scriverlo, e allo stesso tempo il ritmo di un'interazione in chat con l'IA rende quell'attenzione difficile da mantenere.

***

Gli sviluppatori passano anni a imparare a proteggere uno stato cognitivo specifico, chiamiamolo flow, chiamiamolo la zona, perché è lo stato in cui il ragionamento complesso è davvero possibile. Revisionare codice generato dall'IArichiede più di quello stato, non meno, perché tutto il ragionamento che normalmente avverrebbe attraverso l'atto di scrivere ora deve avvenire solo attraverso la valutazione. Non solo, il ritmo dell'interazione in chat con l'IA è quasi strutturalmente incompatibile con lo stato che la revisione richiede.

Prima che l'IA entrasse in scena, mantenere il flow non era solo una tecnica di produttività per gli sviluppatori, ma rappresentava quasi l'intera identità professionale. Ore che sparivano dentro un problema difficile, il click silenzioso di una soluzione che finalmente prendeva forma, la sensazione di essere completamente assorbiti in qualcosa che contava: questo era quello che significava, per gran parte della carriera lavorativa, essere bravi in questo mestiere. Imparare a proteggere quello stato (costruire le abitudini, l'ambiente, la disciplina per raggiungerlo in modo affidabile) faceva parte del diventare uno sviluppatore senior tanto quanto imparare un linguaggio o un framework. Chiedere oggi a qualcuno di lavorare in un ritmo fondamentalmente diverso, costruito attorno a prompt, revisioni e nuovi prompt continui, significa chiedergli di andare contro istinti costruiti in un’intera carriera, e può essere davvero doloroso, perché è un cambiamento che richiede di disimparare qualcosa che, fino a ieri, definiva se si era bravi o meno nel proprio lavoro. Non si tratta di resistenza nell’utilizzo di questi nuovi strumenti. 

Quanto detto finora va oltre la generica esigenza di silenzio per concentrarsi. Il framework Deep Work di Cal Newport tratta la concentrazione sostenuta e ininterrotta come un requisito funzionale per i compiti cognitivamente impegnativi, non come una preferenza. Nel software, in particolare, tenere in memoria di lavoro un modello mentale completo di una codebase è la precondizione per giudicare se una qualsiasi modifica sia effettivamente corretta, e quel modello mentale non è semplice da mantenere. È come avere in testa la piantina di un grande edificio semi-familiare: quale stanza si collega a quale, dove sono davvero i muri portanti, quale porta sembra a posto ma si apre su un dirupo. Perdi la concentrazione e quella piantina non sbiadisce solo un po' ai margini. Evapora. Recuperarla significa ricostruire l'intera struttura nella testa da zero, stanza per stanza, prima di poter giudicare in sicurezza se un cambiamento in un punto qualsiasi sia solido. Dare un’occhiata ai propri appunti non è sufficiente.

L'interruzione ha un costo reale e misurato. La ricerca di Gloria Mark alla UC Irvine colloca il tempo medio per recuperare pienamente la concentrazione profonda dopo una singola interruzione a 23 minuti e 15 secondi. Ogni ciclo prompt-risposta in una chat con l'IA è una potenziale istanza di quell'interruzione: l'attesa della risposta, lo spostamento verso la revisione dell'output prodotto, la ripresa del focus sul problema. Niente di questo è gratuito, anche se sembra immediato.

L'interazione in sé è costruita attorno a un ritmo superficiale: prompt, revisione, aggiustamento, nuovo prompt. Quel ciclo è ottimizzato per la reattività e la velocità di iterazione, non per la profondità. Questo mantiene chi lavora in uno stato di attenzione parziale continua, consapevole di ciò che l'agente ha prodotto, in attesa della prossima risposta, mai pienamente dentro il problema. Ed è praticamente l'opposto dello stato cognitivo che una revisione del codice accurata richiede davvero.

È allettante pensare che questo non valga più una volta passati a cicli agentici più lunghi e autonomi, quelli che lavorano per venti minuti o un'ora senza che sia necessario restare in chat. Ma nemmeno in quel caso è possibile inviare il prompt e disinteressarsi del tutto una volta avviato il lavoro. Meno interruzioni si verificano momento per momento, più il costo si concentra alle due estremità del ciclo: la specifica iniziale deve essere molto più completa, perché durante il lavoro non c'è più un dialogo continuo con l'agente che permetta di accorgersi subito di una premessa sbagliata, e alla fine succede che sia necessario revisionare in un'unica seduta un insieme di modifiche corrispondentemente più ampio e meno familiare. L'autonomia non elimina il costo del ritmo superficiale. Lo raggruppa soltanto: paghi meno spesso, e di più, a ogni estremità di un ciclo più lungo.

La revisione, fatta come si deve, è uno dei task più impegnativi per uno sviluppatore. Quando si scrive codice in prima persona, l’atto di scrivere è una forma di ragionamento: si costruisce la soluzione e la sua comprensione nello stesso momento. Quando si revisiona il codice di qualcun altro (o di qualcos'altro), tutto quel ragionamento deve avvenire nella testa di chi legge, senza l'impalcatura che la scrittura fornisce. Richiede più concentrazione dello scrivere direttamente il codice, non meno. Farlo in uno stato di attenzione parziale continua porta a perdere sistematicamente dei dettagli.

Il Developer Survey 2025 di Stack Overflow, quasi 50.000 partecipanti, ha catturato questa tensione con notevole precisione. Gli sviluppatori riferivano di sentirsi davvero potenziati dall'IA: capaci di costruire di più, sperimentare di più. Allo stesso tempo, il 45% ha indicato la propria frustrazione principale nell’uso di questi strumenti con le parole: "soluzioni IA quasi giuste, ma non del tutto". Non a caso, il 66% ha dichiarato di dedicare ora più tempo a correggere proprio quel tipo di codice quasi-giusto rispetto a quanto ne avrebbe speso scrivendolo da solo: due misure dello stesso problema. La fiducia raccontava una storia correlata da un'angolazione diversa: il 33% dichiarava di fidarsi dell'accuratezza dell'output IA, contro un 46% che ne diffidava attivamente. Quel divario, sentirsi potenziati fidandosi di meno, è come appare dall'interno una revisione condotta sotto la soglia cognitiva necessaria.

La zona non è mai stata solo questione di prestazioni, è la sensazione di capire davvero cosa si sta costruendo. Gli sviluppatori che hanno passato anni a coltivare quello stato conoscono la differenza tra lavorare dentro un problema e lavorare intorno a esso. Le chat con l'IA tendono a tenere chi le usa intorno al problema, anche quando si crede di esserci pienamente dentro. La parte scomoda è che può sembrare tutto sommato a posto. Lavorare intorno a un problema è, di per sé, una forma di comodità.

È qui che trova posto la prima frizione del mio esperimento. Le richieste di conferma imprevedibili, nessuna logica coerente sul perché questa decisione richiedesse il mio via libera e l'ultima no, si sono rivelate una versione particolarmente corrosiva del problema dell'interruzione. Oltre al costo di 23 minuti per ogni interruzione effettiva, avevo iniziato a restare in uno stato di attenzione parziale continua in previsione del prossimo blocco ingiustificato. Pagavo lo scotto anche nei tratti in cui, di fatto, nulla mi stava interrompendo.

Tutto questo si ricollega al precedente articolo - IA: l'illusione della produttività - Il problema della qualità dell'attenzione - in un modo che credo sia importante: lo stesso sviluppatore che non riusciva a esternalizzare del tutto la propria competenza in un prompt è ora quello che valuta l'output di quel prompt povero di specifiche, in uno stato cognitivo che il modello di interazione ha già logorato. Entrambi gli estremi dello scambio sono compromessi contemporaneamente.

C'è però un'ulteriore escalation, ed è quella a cui appartiene davvero la mia seconda frizione (il ciclo di revisione che non convergeva). Cosa succede quando si smette di far girare un solo agente e si inizia a farne girare più d'uno insieme?

***

Questa è la seconda parte della serie “IA: l'illusione della produttività”. La terza parte uscirà il 15 Settembre: vedremo cosa succede quando chi sviluppa smette di far girare un solo agente e inizia a farne girare più di uno insieme. Far lavorare più agenti in parallelo moltiplica la domanda cognitiva, e i problemi legati alla qualità dell'attenzione e allo stato di flow, analizzati nei primi due articoli, si aggravano di pari passo.

***

Abbiamo scritto questo articolo con il supporto dell'AI. Se vuoi saperne di più su come usiamo questi strumenti per la scrittura, ecco la spiegazione.

***

Linkografia


Immagine di copertina: 
Foto di Igor Omilaev su Unsplash

Post correlati