AI coding consapevole – Competenze, carico cognitivo e fragilità epistemica

Carico cognitivo, lavoro noioso e benessere dei team

Il paradosso della produttività AI e il ruolo cognitivo del “lavoro noioso”

La narrativa – emotivamente coinvolgente – che gli assistenti AI liberino gli sviluppatori dal lavoro ripetitivo per concentrarsi su attività a maggiore valore aggiunto dà per scontato che un impegno cognitivo costantemente elevato sia positivo. Le ricerche sul carico cognitivo suggeriscono il contrario: task a bassa intensità — scrivere boilerplate, formattare documentazione, eseguire refactoring meccanico — svolgono una funzione di recupero mentale analoga al riposo, permettendo ai processi di consolidazione e riflessione di operare in background. Eliminarli non significa “liberare tempo”, bensì rimuovere le occasioni di recupero da una giornata già densa.

Questo è il paradosso della produttività AI [1]: quando viene privato di queste pause cognitive, il lavoratore entra in un overload continuo [2] che riduce la qualità del pensiero sui task davvero complessi.

Martyn Redstone osserva che quei task “noiosi” erano spesso l’unica forma di respiro mentale [3] nel flusso di lavoro di un developer: la loro scomparsa trasforma la giornata in una sequenza ininterrotta di decisioni ad alto impatto, con il rischio che la loro qualità degradi nel tempo — in modo difficile da misurare nel breve periodo, perché lo sviluppatore continua a produrre output, ma con giudizio critico ridotto.

Senso di controllo e perdita di agency

La sensazione di padronanza e controllo sul proprio lavoro è un fattore chiave di soddisfazione e resilienza, documentato consistentemente nelle ricerche sul benessere lavorativo. Quando la maggior parte del codice viene generata da un sistema esterno e il proprio ruolo si riduce a quello di validatore, questa sensazione di agency può ridursi.

Citrix, in un’analisi sulla struttura cognitiva del lavoro assistito da AI [4], sostiene che molte strategie AI si concentrano sul livello sbagliato dello stack cognitivo: automatizzano l’esecuzione senza supportare abbastanza comprensione, contesto e decision-making, lasciando ai lavoratori il compito di gestire la parte più complessa.

Decadimento delle competenze e impatto sullo sviluppo ingegneristico

Atrofia delle competenze e impatto sugli sviluppatori in formazione

In psicologia cognitiva, l’automation bias [5] — la tendenza a fidarsi eccessivamente dei sistemi automatizzati — è documentato da decenni in contesti come aviazione, medicina e guida assistita. Il meccanismo applicato allo sviluppo software è analogo: la delega continuativa di task cognitivi all’AI riduce l’esercizio delle competenze corrispondenti. Le competenze cognitive, come quelle fisiche, si mantengono attraverso l’esercizio (use it or lose it): chi non scrive algoritmi da zero, non affronta debugging senza assistenza, non progetta architetture dall’inizio, perde gradualmente la fluidità in queste operazioni e la capacità di riattivarle rapidamente in contesti nuovi.

Il rischio è particolarmente acuto per gli sviluppatori alle prime armi, il cui apprendimento ingegneristico avviene in gran parte sul campo: scrivere codice che fallisce, capire perché fallisce, riscriverlo con comprensione più profonda. Quando si usa un assistente AI per generare la soluzione a un problema non ancora compreso, si salta questa fase — si ottiene codice spesso funzionante, ma senza il processo cognitivo che avrebbe costruito la comprensione per ragionare autonomamente su problemi analoghi in futuro.

L’impatto sui developer già formati: da costruttori a validatori

Il rischio per i “senior” non è la perdita di competenze di base — i modelli mentali costruiti in anni di esperienza sono robusti — ma il cambiamento qualitativo del ruolo: da costruttori attivi di sistemi complessi a validatori del codice generato da AI. Validare è cognitivamente diverso da costruire: richiede di identificare errori in un artefatto esistente invece che generare artefatti corretti. Nel lungo periodo, un professionista che valida sempre senza mai costruire rischia di vedere ridotta la propria capacità di partire da zero in un contesto nuovo.

Dipendenze organizzative e riduzione dell’autonomia

A livello organizzativo, il rischio più significativo è la dipendenza da strumenti proprietari di terze parti per la funzione core del software engineering. Una dipendenza del genere ha implicazioni sui costi (cambiamento dei prezzi, vendor lock-in), sulla sicurezza (dati inviati a servizi cloud) e sulla continuità operativa (interruzioni del servizio, cambiamenti delle API, fine del ciclo di vita del prodotto).

Vi è anche un rischio più sottile: la concentrazione del know-how sul “come usare gli strumenti AI” piuttosto che sul “come costruire software”.

Fragilità epistemica e il futuro del pensiero ingegneristico

Delega del ragionamento e problem-solving vs prompt crafting

L’argomento più profondo riguarda cosa accade quando non solo la scrittura del codice, ma l’analisi del problema, l’identificazione delle soluzioni e la valutazione dei trade-off vengono sistematicamente delegati all’AI. L’istituto Frost & Sullivan articola questa preoccupazione con precisione: stiamo sviluppando sistemi sempre più capaci di fornire risposte, ma che impatto ha questo sulla nostra capacità di porre le domande giuste? [6] Formulare una domanda precisa e produttiva richiede una comprensione del dominio sufficiente a sapere non solo cosa si sa, ma anche cosa non si sa.

C’è inoltre una differenza significativa tra “capire un problema e costruire una soluzione” e “descrivere un problema in modo che un sistema AI generi una soluzione soddisfacente”: entrambi richiedono competenze reali e non banali, ma sono processi diversi, che producono comprensione diversa. Se la formazione si orienta principalmente a formulare prompt efficaci piuttosto che a ragionare autonomamente su sistemi complessi, l’organizzazione punta su competenze potenzialmente insufficienti nei casi in cui l’AI non è disponibile, non è adeguata al problema, o produce output errati che richiedono correzione.

Rimane fondamentale anche in questa nuova era “la continua attenzione all’eccellenza tecnica e alla buona progettazione” — ben noto principio del Manifesto Agile [7].

La scomparsa della domanda ambigua e l’evidenza neuropsicologica

Esperti di educazione dell’UNESCO hanno identificato un fenomeno rilevante: i sistemi AI favoriscono domande ben formulate e rispondibili, e gli utenti tendono ad adattare le proprie domande alle capacità del sistema. Il risultato è la progressiva scomparsa delle “domande ambigue” [8] — quelle mal definite, esplorative, prive di risposta chiara, ma spesso punto di partenza di brainstorming, creatività e innovazione.

Nell’ingegneria del software, domande importanti sono spesso di questo tipo: “Qual è davvero il problema che stiamo cercando di risolvere?”, “Quali sono le assunzioni implicite in questa architettura?”, “Come dovrebbe evolversi questo sistema tra cinque anni?”. Queste domande non si prestano a essere delegate a un assistente AI e rischiano di venire sacrificate in un workflow ottimizzato per velocità e output.

Il riferimento empirico più diretto è lo studio del MIT Media Lab “Your Brain on ChatGPT” [9] di Kosmyna e colleghi, pubblicato come preprint nell’estate 2025. Lo studio ha assegnato 54 partecipanti a tre gruppi — “LLM”, “motore di ricerca”, “solo cervello” — per svolgere task di scrittura in più sessioni nell’arco di quattro mesi, misurando l’attività cerebrale tramite EEG. La connettività neurale si è rivelata inversamente proporzionale al livello di supporto esterno: il gruppo “solo cervello” ha mostrato le reti neurali più ampie e attive, il gruppo “LLM” la connettività complessiva più debole. Nella sessione in cui i partecipanti del gruppo “LLM” venivano privati dello strumento, questi mostravano sotto-attivazione delle reti alfa e beta e difficoltà nel citare il proprio testo scritto pochi minuti prima; il senso di ownership degli elaborati era sensibilmente più basso rispetto agli altri gruppi.

Gli autori segnalano limiti importanti: campione ridotto (54 partecipanti), geograficamente concentrato, contesto limitato alla scrittura accademica, preprint non ancora peer-reviewed. Lo studio va letto come evidenza preliminare che pone la questione in modo rigoroso, non come prova definitiva. Detto questo, il meccanismo documentato — connettività neurale ridotta con supporto esterno crescente, difficoltà di recupero una volta rimosso lo strumento — è concettualmente coerente con la letteratura consolidata sulla plasticità neurale e sull’automation bias. Se l’uso continuo dell’AI modifica gradualmente i pattern cognitivi, le implicazioni per la formazione ingegneristica a lungo termine restano una domanda aperta e legittima.

Conclusioni

Sintesi dei rischi principali

L’analisi condotta in questi due articoli identifica un insieme di rischi che si sovrappongono e si rinforzano:

• Qualità e manutenibilità: il codice generato da AI, senza sufficiente attenzione, rischia di accumularsi in architetture fragili e incoerenti, con debito tecnico difficilmente visibile nel breve periodo.
• Sicurezza: la velocità di generazione del codice supera la capacità di security review, producendo un “CVE surge” documentato empiricamente.
• Workflow: il “vibe coding” comprime le fasi di design e riflessione, ottimizzando localmente a discapito della qualità globale.
• Produttività: i vantaggi di produttività sono reali, ma spesso concentrati in task limitati e sovrastimati per via dei costi downstream di debugging, review e incidenti.
• Benessere cognitivo: l’eliminazione del lavoro “noioso” rimuove il recupero cognitivo, aumentando la fatica decisionale dei team.
• Competenze: la continua delega cognitiva produce atrofia delle competenze ingegneristiche.
• Capacità epistemica: la sostituzione del ragionamento autonomo con il prompt crafting rischia di produrre professionisti meno capaci di comprendere, modellare e ragionare su sistemi complessi.

Una posizione equilibrata

Nessuno dei rischi esaminati è un argomento sufficiente per l’abbandono degli strumenti AI: sarebbe una conclusione tanto semplicistica quanto l’adozione acritica. L’AI è uno strumento potente che, usato nei contesti appropriati con governance adeguata, può produrre valore reale.

Ma — ed è un “ma” importante — non è uno strumento neutro. Come ogni tecnologia che modifica profondamente i processi cognitivi e organizzativi, introduce trade-off che devono essere identificati, valutati e gestiti consapevolmente.

Come esempio, voglio essere del tutto trasparente su come questi stessi articoli siano stati prodotti. Nella fase di analisi, raccolta e verifica delle fonti, e nella prima stesura, ho utilizzato diversi strumenti AI come ausilio: Claude, Perplexity, ChatGPT e Gemini.

È stato un aiuto reale e concreto: ha accelerato la raccolta di riferimenti, mi ha permesso di esplorare connessioni tra fonti, mi ha fornito una prima struttura su cui lavorare. Sarebbe disonesto non riconoscerlo.

Ugualmente disonesto, però, sarebbe non precisare che ho riletto e rivisto ogni sezione, riscrivendo buona parte del testo, ricontrollando le fonti e sostituendole con altre più adeguate, rielaborando i punti in cui il testo andava alla deriva dalla propria fonte, integrando revisioni e miglioramenti suggeriti dai colleghi a cui ho mostrato l’anteprima. A tal proposito, ci tengo a ringraziare sinceramente Manuel Bonini e Simone Recupero per il preziosissimo aiuto e le interessanti discussioni.

L’AI ha contribuito all’efficienza del processo, ma la responsabilità intellettuale del contenuto rimane con chi lo firma. Questo è esattamente il tipo di uso consapevole degli strumenti AI che intendo difendere con questi articoli.

Implicazioni pratiche

Per chi lavora nel software engineering, alcune direzioni pratiche emergono dall’analisi:

Sulle pratiche di sviluppo: reintrodurre attrito controllato nei processi accelerati dall’AI non è un retaggio conservatore, ma una risposta razionale a rischi documentati. Amazon lo ha fatto reattivamente dopo un incidente; è possibile farlo proattivamente. Questo significa mantenere fasi di design esplicite, non comprimibili, e distinguere i contesti in cui il vibe coding puro è appropriato (prototipazione, spike) da quelli in cui non lo è (sistemi di produzione, codice con implicazioni di sicurezza).
Molti framework sono nati nell’ottica di integrare le buone pratiche di sviluppo software con l’AI-coding e sembrano una strada molto promettente per gestire sistemi complessi. Mi riferisco in particolare ai framework di Spec-Driven Development [10], come BMad Method, Spec Kit, o OpenSpec [11].

Sulla formazione: le organizzazioni che investono nell’AI senza investire simultaneamente nel mantenimento delle competenze ingegneristiche di base stanno ottimizzando a breve termine. Non ho una risposta sicura, ma credo che i programmi di formazione dovrebbero continuare a includere deliberatamente attività “difficili” — debug senza assistenza, design architetturale da zero, attività approfondite di code review — come esercizi di mantenimento delle competenze, non come fossili di una modalità di lavoro superata.

Sulle metriche: sostituire le metriche di throughput (PR velocity, lines of code, feature shipped) con metriche di outcome (stabilità dei sistemi, costo di manutenzione, tempo medio di risoluzione degli incidenti, qualità delle review) è necessario per valutare il reale contributo degli strumenti AI.

La domanda aperta

Il software engineering è, nella sua essenza, l’attività di progettare e costruire sistemi che risolvono problemi complessi in modo affidabile e manutenibile. Questa attività richiede — e ha sempre richiesto — una combinazione di conoscenza tecnica, capacità di ragionamento sistemico, giudizio su trade-off e comprensione profonda dei contesti umani in cui i sistemi operano.

La domanda che il settore deve affrontare è questa: vogliamo costruire un ecosistema di strumenti e pratiche che mantiene, sviluppa e trasmette queste capacità alle generazioni future di sviluppatori, o stiamo ottimizzando per metriche di breve periodo che producono apparenza di progresso mentre erodono silenziosamente le fondamenta su cui quel progresso si basa?

Fonti e riferimenti

1. eLearncollege — “Paradox of AI productivity shows boring work need“
2. Fortune — “AI workers’ productivity, brain recovery, cognitive offload overload” (apr.2026)
3. LinkedIn / Redstone — “Why the boring tasks you are automating were […] keeping your workforce sane” (dic.2025)
4. Citrix — “Understanding the cognitive stack: why your AI strategy is focused on the wrong layer” (feb.2026)
5. Forbes — “Automation Bias: What It Is And How To Overcome It” (mar.2024)
6. Frost & Sullivan Institute — “When AI generates the answers, are we losing our ability to ask the questions?” (mar.2026)
7. Agile Manifesto – “I princìpi“
8. UNESCO — “The disappearance of the unclear question“ (giu.2025)
9. Kosmyna N. et al., MIT Media Lab — “Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task“ (preprint, giu.2025) — Preprint Arxiv
10. Medium — “Spec Driven Development“ (mar.2026)
11. Augment Code — “6 Best SDD Tools for AI-coding“ in 2026 (mar.2026)