Deskilling: Stiamo Disimparando a Programmare?

C'è uno sviluppatore che ha raccontato una cosa che mi ha colpito. Dopo mesi di uso intensivo di Copilot e Cursor, ha iniziato un side project senza AI. Il risultato? Si sentiva "stupido": cose che prima erano istintive — scrivere una query, debuggare un errore, strutturare un componente — erano diventate faticose, quasi manuali.

Non è un caso isolato. E i dati cominciano a dire qualcosa di inquietante.

I numeri che fanno riflettere

Lo studio Anthropic: -17% di comprensione

A gennaio 2026, i ricercatori di Anthropic (Judy Hanwen Shen e Alex Tamkin) hanno condotto un esperimento randomizzato: due gruppi di sviluppatori dovevano imparare una libreria Python nuova. Un gruppo la usava con assistenza AI, l'altro a mano.

Il risultato: chi aveva usato l'AI ha ottenuto un punteggio 17% più basso nei quiz di comprensione.

La velocità era migliore. La comprensione no. Chi delegava completamente all'AI finiva il task più in fretta ma non capiva cosa aveva scritto.

Lo studio METR: il 19% più lenti

Nel luglio 2025, METR (Model Evaluation & Threat Research) ha condotto il trial più rigoroso fino a quel momento: 16 sviluppatori open-source esperti, 246 task su codebase reali (media 22K+ stelle, 1M+ righe di codice), usando Cursor Pro con Claude 3.5/3.7 Sonnet.

Il risultato ha sorpreso tutti: i dev con AI erano il 19% più lenti, non più veloci.

Ma il dato più inquietante è un altro: gli stessi sviluppatori credevano di essere il 20% più veloci. La percezione era completamente invertita rispetto alla realtà.

Il rifiuto di lavorare senza AI

Nell'aggiornamento di febbraio 2026, METR ha riportato un dato ancora più preoccupante: il 30-50% degli sviluppatori nello studio si rifiutava di completare task senza AI. Non perché non potessero — perché non volevano.

È il segnale classico della dipendenza: non è che non sai farlo, è che non sopporti l'idea di farlo senza lo strumento.

Il debito cognitivo

Il concetto è semplice e brutale: le competenze che non usi, le perdi.

I percorsi neurali si rafforzano con l'uso e si deteriorano senza di esso. Quando deleghi ripetutamente un compito all'AI — debugging, scrittura di query SQL, architettura di componenti — i percorsi neurali associati a quelle competenze subiscono un'eliminazione sistematica.

È quello che alcuni ricercatori chiamano debito cognitivo: un costo nascosto che si accumula silenziosamente, come il debito tecnico nel codice. Non lo vedi finché non arriva il momento in cui ti serve quella competenza e scopri che non c'è più.

La testimonianza "AI killed my coding brain"

Un developer ha documentato il processo su DEV Community: dopo mesi di affidarsi all'AI per ogni task, ha notato un declino cognitivo misurabile. Non riusciva a tenere in testa la struttura di un programma come prima. Il debugging era diventato "chiedi all'AI" invece di "ragiona sul problema".

Ha iniziato un processo deliberato di ricostruzione delle competenze manuali — scrivere codice senza assistenza per almeno un'ora al giorno.

Il 40% che deploya senza capire

Secondo i dati raccolti da varie survey, oltre il 40% degli sviluppatori junior ammette di deployare codice generato dall'AI che non comprende completamente. Non è pigrizia — è il risultato naturale di un workflow dove l'AI scrive e tu approvi.

L'effetto barbell: chi vince e chi perde

Il mercato del lavoro per sviluppatori si sta spaccando in due:

Da un lato, i senior che usano AI come moltiplicatore. Conoscono i fondamentali, sanno debuggare, sanno quando l'AI ha torto. Per loro, l'AI è un boost reale — non un sostituto del pensiero, ma un acceleratore.

Dall'altro, le persone che sanno promptare ma non debuggare. Costruiscono cose che funzionano finché tutto va bene. Al primo errore non banale, sono bloccati.

Il centro sta sparendo. E i dati lo confermano: l'occupazione tra gli sviluppatori software di 22-25 anni è calata quasi del 20% tra 2022 e 2025. Le offerte di lavoro per sviluppatori negli USA si sono ridotte di oltre il 70%.

Non è solo l'AI — è anche il mercato post-pandemia. Ma il timing è sospetto.

I piloti che non sanno più volare

Il parallelo più istruttivo non viene dal coding. Viene dall'aviazione.

I piloti di voli a lungo raggio che si affidano pesantemente all'autopilot mostrano un degrado misurabile nella consapevolezza situazionale e nella capacità di volo manuale. La ricerca documenta un ciclo vizioso: i piloti si rendono conto che le loro competenze stanno diminuendo → si affidano di più all'automazione → il declino accelera.

Il fenomeno è così documentato che la FAA ora impone più tempo di volo manuale per contrastare l'effetto.

L'analogia con il coding è diretta:

Aviazione	Sviluppo Software
Autopilot gestisce il volo	AI scrive il codice
Pilota monitora gli strumenti	Dev approva le PR
Emergenza → pilota deve riprendere il controllo	Bug in produzione → dev deve debuggare
Competenze manuali atrofizzate	Competenze di debugging/architettura atrofizzate
FAA impone volo manuale	Nessuno impone coding manuale

L'ultima riga è la differenza critica. Nell'aviazione, il problema è stato riconosciuto e affrontato con regolamentazione. Nel software, siamo ancora nella fase "va tutto benissimo".

Lo stesso pattern si sta ripetendo nel Site Reliability Engineering: l'AI che gestisce gli incidenti automaticamente significa che gli ingegneri perdono la memoria muscolare per la risposta manuale agli incidenti. Quando l'AI non riesce a risolvere (e succede), nessuno sa più cosa fare.

Le voci dal campo

DHH: "L'AI non sostituisce i junior"

David Heinemeier Hansson, creatore di Ruby on Rails, è diretto: per il loro nuovo prodotto Fizzy, a 37signals gli umani hanno scritto il 95% del codice. Gli esperimenti con AI sono stati provati ma non spediti in produzione.

DHH avverte contro il "vibe coding" — promptare il proprio percorso attraverso i progetti senza capire cosa si sta costruendo.

Addy Osmani: la distinzione che conta

Il lead del team Chrome di Google traccia una linea netta:

Vibe coding: prompti senza capire, accetti senza verificare, speri che funzioni
AI-assisted engineering: usi l'AI come strumento mantenendo comprensione e supervisione

La differenza non è nell'usare o non usare l'AI. È nel livello di engagement cognitivo mentre la usi.

Lo studio Anthropic conferma

E qui torniamo ai dati: lo studio Anthropic ha identificato 6 pattern di interazione con l'AI. Di questi, 3 preservano l'apprendimento:

Chiedere spiegazioni: "Perché hai usato questo pattern?"
Questioning: "Questo è davvero il modo migliore?"
Iterazione critica: modificare il codice suggerito, non accettarlo così com'è

I developer che usavano l'AI come collaboratore — facendole domande, mettendo in discussione i suggerimenti, iterando criticamente — imparavano tanto quanto chi codava da solo.

La variabile chiave non è l'uso dell'AI. È il coinvolgimento cognitivo.

Il contro-argomento: l'AI libera il pensiero

Non tutto è nero. C'è un argomento legittimo dall'altra parte.

L'AI gestisce il boilerplate. Nessuno diventa un programmatore migliore scrivendo il centesimo form di login. Se l'AI si prende il lavoro ripetitivo e tu ti concentri sull'architettura, i pattern, i trade-off — potresti effettivamente imparare di più.

L'AI come tutore infinitamente paziente. Per chi sta imparando, poter chiedere "perché questo codice non funziona?" a qualcosa che non ti giudica e non si stanca può essere trasformativo.

I dati di produttività esistono. 9 sviluppatori su 10 riportano di risparmiare almeno 1 ora a settimana. 1 su 5 risparmia 8+ ore — un'intera giornata lavorativa.

Ma la domanda resta: stai risparmiando tempo o stai risparmiando apprendimento?

Il paradosso della produttività

Eccolo, il vero nodo:

Lo studio METR dice che sei più lento con l'AI (su codebase grandi e familiari)
I sondaggi di produttività dicono che sei più veloce con l'AI (su task generici)
Lo studio Anthropic dice che impari meno con l'AI
Ma se usi l'AI nel modo giusto, impari uguale

Non è una contraddizione. È un segnale che il come conta più del se. L'AI non è né lo strumento magico né il distruttore di competenze. È un amplificatore: amplifica il tuo approccio, qualunque esso sia.

Se il tuo approccio è "delega tutto e approva" → deskilling garantito. Se il tuo approccio è "usa come acceleratore, verifica tutto, chiedi perché" → probabilmente ok.

Cosa puoi fare concretamente

Non sto dicendo di smettere di usare l'AI. Sarebbe stupido e controproducente. Ma ci sono pratiche concrete per evitare il deskilling:

1. La regola del "volo manuale" Come i piloti, dedica tempo regolare a programmare senza AI. Un progetto personale, un esercizio, un'ora al giorno. Tieni attivi i percorsi neurali.

2. Mai deployare ciò che non capisci Se l'AI ha scritto qualcosa e non sai spiegare perché funziona — fermati. Chiedi all'AI di spiegarti. O meglio, prova a capirlo da solo prima di chiedere.

3. Debugga prima tu Quando c'è un bug, resisti alla tentazione di incollarlo nell'AI. Prova 10 minuti da solo. Il debugging è la palestra del pensiero logico — se la salti, i muscoli si atrofizzano.

4. Questioning mode Quando l'AI suggerisce qualcosa, chiediti: "Avrei fatto la stessa scelta? Perché o perché no?" Questo mantiene il coinvolgimento cognitivo attivo.

5. Impara i fondamentali (davvero) Se non sai come funziona un database, un'API REST, o un event loop senza AI — colma il gap. L'AI è un moltiplicatore: 10x su zero competenze fa zero.

La domanda giusta

Non è "l'AI ci sta deskillando?" — certo che lo fa, se la usi male.

La domanda giusta è: "come sto usando l'AI?"

Se la risposta è "la faccio scrivere e poi approvo" — hai un problema. Non oggi, forse non domani, ma al primo incidente serio scoprirai un buco nelle tue competenze che non sapevi di avere.

Se la risposta è "la uso come un collega senior con cui discuto" — probabilmente stai bene. Anzi, probabilmente stai crescendo più velocemente di chi non la usa affatto.

La differenza tra un pilota e un passeggero è semplice: il pilota sa cosa sta succedendo. Anche quando l'autopilot è acceso.

Fonti: