IA: l'illusione della produttività - Il problema della qualità dell'attenzione

Da mesi il team Nephila sta conducendo una serie di esperimenti con l’agentic coding. Da questo lavoro sono nate alcune riflessioni che vale la pena condividere perché toccano un tema centrale del dibattito attuale sull'IA e la produttività di chi sviluppa software.

Questo è il primo articolo di una serie in quattro parti sull'impatto reale dell'IA nello sviluppo software che pubblicheremo nel mese di Settembre. Partendo dal problema della qualità dell’attenzione, Iacopo Spalletti, CTO e Solution Architect, avvalendosi di dati oggettivi insieme alla sua esperienza diretta, evidenzia il divario tra la sensazione che uno strumento stia aiutando e il beneficio reale che produce. 

***

All'inizio delle mie analisi e dei miei esperimenti per introdurre nel team uno sviluppo strutturato assistito dall'IA, ho condotto una serie di esperimenti sistematici con un agente di coding IA su un progetto di esempio realistico: non una demo giocattolo, ma qualcosa di più vicino a ciò che ci passa davvero per le mani. Volevo capire, in modo sistematico, cosa significhi davvero "agentic coding" una volta spinto oltre lo scenario ideale, prima di decidere come, o se, integrarlo nel flusso di lavoro di tutto il team.

Sono finito a litigare con lo strumento.

Sono successe due cose, in modo ricorrente. Primo: l’agente si fermava a chiedermi conferma su una decisione, a volte piccola, a volte significativa, senza una logica coerente che riuscissi a individuare sul perché questa scelta richiedesse il mio via libera mentre una scelta di peso paragonabile, cinque minuti prima, era stata presa in autonomia senza pensarci due volte. Il confine tra "chiedi all'umano" e "vai avanti" sembrava arbitrario, non basato su un principio.

Secondo: quando ho impostato un ciclo di revisione con un agente che implementava e uno che revisionava, lavorando in coppia, molto spesso, round dopo round, i due si rimpallavano il lavoro, (una correzione, una critica alla correzione, una correzione della critica), senza mai convergere. Erano due agenti che scrivevano specifiche e commenti di review sicuri di sé ma, in fondo, passivo-aggressivi, bloccati in un disaccordo che solo io potevo risolvere. Farlo significava restare abbastanza vicino al codice vero da accorgermi che il ciclo non si stava chiudendo.

Non potevo allontanarmi. Il workflow richiedeva un monitoraggio costante: dovevo essere pronto a interrompere e intervenire in qualsiasi momento, e indirizzare l'agente verso quella che secondo me era la scelta giusta. Avrei voluto delegare, ma quello che ho ottenuto è stato un carico di supervisione maggiore, che ricadeva esattamente sulla concentrazione che lo strumento avrebbe dovuto liberare.

Voglio essere onesto su questo punto prima di andare avanti: questa è stata la mia esperienza nei primi giorni di sperimentazione con questo tipo di workflow. Lo scenario può cambiare in base alla qualità del prompt, con l'uso o meno delle skill e dei workflow strutturati giusti, e con l'esperienza che si accumula nel tempo nel guidare un agente. Non offro questa storia come prova che l'agentic coding non funzioni. La offro come un caso concreto di qualcosa che, credo, il dibattito attuale sulla produttività dell'IA continua a non considerare: l'agentic coding non risolve i problemi per magia.Richiede esperienza e supervisione attiva, che non si possono dare per scontate, e gran parte di ciò che si dice oggi su IA e produttività dà per scontato esattamente questo.

Si dà il caso che non sia solo la mia frustrazione a parlare. Nel 2025, METR, un'organizzazione no profit che conduce alcuni dei lavori empirici più rigorosi sulle capacità dell'IA, ha messo una versione di questa esatta dinamica sotto misurazione controllata, trovando lo stesso divario tra sentirsi aiutati ed essere effettivamente aiutati che avevo appena vissuto in prima persona. Tra poco entrerò nel dettaglio dei numeri reali, perché vale la pena soffermarcisi, ma i risultati della ricerca confermano l’esperienza che ho appena descritto. 

Anche se gli sviluppatori di quello studio avessero avuto ragione, anche se l'IA li avesse davvero resi più veloci, resta una domanda preliminare che in quella stanza nessuno si stava ponendo.

Il problema della qualità dell'attenzione

Il messaggio dietro ogni strumento di coding IA è più o meno lo stesso: scarica l'esecuzione, così puoi dedicare più della tua attenzione al pensiero. È uno scambio allettante. Ed è anche, sostengo, rovesciato. Produrre qualcosa di realmente utile da un agente IA richiede più pensiero lucido di quanto ne richieda fare il lavoro da soli perché quel pensiero va esternalizzato con una precisione tale che l'agente, per agire, possa fare affidamento su istruzioni chiare. Un pensiero superficiale produce prompt superficiali, e i prompt superficiali producono output che costano di più in termini di correzioni di quanto sarebbe costato scriverli da zero.

Lo studio METR citato sopra è il punto di ingresso più chiaro per capire il perché. Sedici sviluppatori esperti, su codebase open-source mature su cui lavoravano da anni, hanno completato 246 task reali: bug fix, feature, refactoring. Prima di iniziare, avevano previsto un'accelerazione del 24% grazie all'IA. Dopo aver finito, credevano ancora di essere stati accelerati del 20% ma una volta misurati direttamente sono risultati il 19% più lenti. Gli economisti avevano previsto un'accelerazione del 39%. I ricercatori di machine learning, del 38%. Tutti sbagliavano, e sbagliavano nella stessa direzione.

Il numero che conta qui non è il 19%. È l'inversione. Questa è la firma di un'illusione, non solo di un'inefficienza: un divario sistematico e ripetibile tra quanto il lavoro sembrava produttivo e quanto lo fosse davvero.

L'analisi di METR individua una causa specifica per questo risultato: quelle codebase avevano standard di qualità impliciti molto alti (convenzioni di documentazione, norme di copertura dei test, regole di linting) che gli sviluppatori avevano interiorizzato in anni di lavoro ma non riuscivano a esprimere in istruzioni chiare per un'IA. La conoscenza che rende veloce una figura esperta è esattamente la conoscenza più difficile da trasferire in un prompt.

Vale la pena essere precisi su cosa sia cambiato da quello studio e cosa no. Gli agenti nel 2026 sono davvero abbastanza bravi a inferire le convenzioni dal codice circostante: leggono i test esistenti, si adattano allo stile prevalente, colgono pattern senza che gli vengano spiegati esplicitamente. Questa capacità dipende interamente da quanto la codebase sia già coerente: se ha convenzioni uniformi offre all'agente qualcosa di affidabile da cui imparare; se invece è cresciuta nel tempo accumulando negli anni derive, eccezioni e conoscenze tacite mai messe per iscritto non gli offrirà nulla di solido su cui inferire. Il problema dell'esternalizzazione non scompare con modelli migliori: si sposta esattamente sulle codebase dove è sempre stato più difficile risolverlo, quelle vecchie, preziose e incoerenti, che non si possono dare per scontate come un caso raro.

Non è nemmeno un risultato isolato. Gli studi sul prompting agentico trovano costantemente che una quota significativa di prompt manca di informazioni di cui l'agente aveva effettivamente bisogno: uno studio del 2026 su oltre 20.000 sessioni agentiche reali ha trovato che il 44,1% degli episodi conteneva istruzioni sottospecificate. Articolare il contesto con precisione richiede lo stesso sforzo mentale di capire il problema in primo luogo. Se quel pensiero non è stato fatto, nessuna tecnica di prompting può produrlo al posto di chi scrive il prompt.

Il costo di saltare quel pensiero si manifesta a valle, in modo sistematico. Un sondaggio di Harness tra leader e sviluppatori ingegneristici ha trovato che il 67% dedica più tempo del previsto al debug di codice generato dall'IA. CodeRabbit, analizzando 470 pull request reali, ha rilevato errori di logica e correttezza 1,75 volte più frequenti nel codice generato dall'IA rispetto al codice scritto da umani. Workday, nella sua ricerca 2026 sull'adozione enterprise dell'IA arriva a una cifra ancora più netta: quasi il 40% del valore di produttività generato dall'IA viene consumato da rilavorazioni e disallineamenti. Il tempo che l'IA fa risparmiare viene speso a sistemare output che non avrebbero dovuto richiedere correzioni.

Questa è esattamente la dinamica che riconosco dall'interno: il prompting superficiale sembra produttività mentre accade. Digiti qualche riga, appare qualcosa sullo schermo, passi al compito successivo. L'output è visibile immediatamente mentre il debito è invisibile fino al momento della revisione, e a quel punto indossa già il costume del "problema di qualcun altro": il pensiero è stato delegato allo strumento, e lo strumento ha restituito qualcosa dall'aspetto plausibile.

Una precisazione onesta, perché non voglio sovrainterpretare un singolo dato: lo studio originale di METR usava strumenti di inizio 2025, e METR stesso ha pubblicato un follow-up a febbraio 2026 con modelli più capaci di fine 2025. Vale la pena citarlo con precisione invece di restare sul vago, perché i numeri veri sono più interessanti di una storia del tipo "le cose sono migliorate". Per gli sviluppatori analizzati nello studio originale, l'accelerazione stimata era del -18%, ancora un rallentamento, mentre per i nuovi reclutati, era del -4%, un dato più vicino alla parità, ma ancora non positivo. METR stesso definisce questo risultato "una prova molto debole": nel frattempo tra il 30 e il 50% degli sviluppatori si rifiutava di svolgere task senza l'IA, e il gruppo di controllo dello studio si stava disgregando perché le persone non volevano più lavorare “alla vecchia maniera” né per scopi di ricerca, né per 50 dollari l'ora.


Quindi lo stato onesto delle prove, sui dati primari più recenti, è questo: nessuna accelerazione positiva confermata finora, intervalli di confidenza ampi che attraversano lo zero, e un disegno di studio che ha dovuto essere abbandonato perché usare l'IA è diventata una pratica normalizzata per isolare una baseline pulita. È un'affermazione più forte e più specifica di "i modelli probabilmente sono migliorati nel frattempo", e dice che il rallentamento non è stato smentito dalle migliori prove attualmente disponibili, anche se aneddoti e autovalutazioni sostengono sempre più il contrario.

Questo è il punto chiave. La capacità dei modelli potrebbe prima o poi colmare lo specifico divario del 19% misurato da METR. È molto meno probabile che colmi il divario tra sentirsi aiutati ed essere aiutati perché quel divario non è una proprietà del modello. È una proprietà di una persona che lavora accanto a qualcosa di fluente e sicuro di sé. Decenni di ricerca sull'automation bias (un termine coniato negli anni '90 per descrivere come le persone in ambienti altamente automatizzati sostituiscano la propria vigilanza con la fiducia nel sistema) mostrano che questo pattern è duraturo, non un sintomo di strumenti immaturi. L'effetto, inoltre, è generalmente peggiore sotto carico cognitivo e si manifesta anche negli strumenti di ultima generazione: uno studio del 2026 sui bias cognitivi nello sviluppo assistito da LLM ha trovato che il 48,8% delle azioni dei programmatori nei workflow di collaborazione con l'IA mostrava una qualche forma di bias cognitivo. Di queste azioni distorte, il 56,4% riguardavano specificamente le interazioni sviluppatore-LLM. Gli studi sono stati condotti usando gli strumenti di oggi, non i modelli ormai superati, studiati originariamente da METR.

Tutto questo non è nuovo nell’ambito software. La ricerca che confronta produttività autopercepita e produttività misurata oggettivamente ha da tempo scoperto che le due divergono, in modo sistematico e non casuale, anche nel lavoro ordinario non assistito dall'IA. L'IA non ha inventato il divario tra sentirsi produttivi ed esserlo, gli ha dato una nuova superficie insolitamente persuasiva su cui agire: avere a disposizione un supporto che produce output ben formattati e plausibili a comando. La condizione perfetta in cui è più probabile scambiare la fluidità per correttezza e cadere in errore.

C'è però un secondo punto di rottura a valle di tutto questo, con una causa diversa: non riguarda le informazioni con cui definiamo il prompt ma cosa succede quando valutiamo la qualità dell’output prodotto

***


Questa è la prima parte della serie AI: l’illusione della produttività. La seconda parte uscirà l'8 Settembre: parleremo di quanto revisionare codice generato dall'IA richieda più attenzione focalizzata di scriverlo in maniera autonoma e di come questo sta impattando sui flussi di scrittura del codice. 

***

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

Post correlati