Qualche settimana fa uno sviluppatore italiano con dieci anni di esperienza professionale ha pubblicato un racconto dettagliato di come è cambiato il suo modo di lavorare negli ultimi tre mesi. Lo chiamerò M. perché il nome non è il punto: il punto è quello che racconta, che è insieme illuminante e inquietante, spesso nello stesso paragrafo.
Lo sviluppatore ha lavorato in aziende di primo livello, ha scritto applicazioni web e app iOS, ha coordinato team. Sa di cosa parla quando parla di codice. E quello che racconta è questo: da dicembre 2025 a oggi, il suo flusso di lavoro si è trasformato al punto da non essere più riconoscibile. Prima scriveva codice in un editor, chiedendo aiuto ai modelli AI per le parti ripetitive. Adesso conversa con Claude Code in un terminale, discute l’architettura, fa preparare un piano dettagliato, approva il piano, e poi dice “scrivi il codice”. E il codice arriva, funzionante, in cinque o otto minuti.
La frase che colpisce di più nel suo racconto è questa: “Ho quasi completamente smesso di guardare il codice.” Lo dice con una specie di meraviglia soddisfatta, come chi ha scoperto che il pilota automatico dell’aereo funziona talmente bene da rendere superfluo guardare fuori dal finestrino. Il suo controllo di qualità adesso consiste nel verificare l’interfaccia, nel testare la funzionalità, nel vedere che il risultato corrisponde a quello che aveva in mente. Il codice in sé, le righe, la struttura, le scelte architetturali a basso livello, quelle le guarda sempre meno.
Aggiunge un dettaglio che lui stesso riconosce come significativo: il 95% delle volte il codice generato funziona al primo colpo. Paragona l’esperienza a quella di lavorare con un ingegnere software capace, a cui dai un brief dettagliato e che poi lo esegue senza bisogno di supervisione riga per riga.
Il dato dietro l’aneddoto
La tentazione è di liquidare tutto come l’aneddoto di un entusiasta. Sarebbe un errore, perché i dati confermano che qualcosa di strutturale è cambiato nel software tra la fine del 2025 e i primi mesi del 2026.
La ricerca del METR (Model Evaluation & Threat Research) misura l’orizzonte temporale dei sistemi AI, cioè per quanto tempo riescono a lavorare autonomamente su compiti di programmazione reali senza intervento umano. Quell’orizzonte raddoppia ogni sette mesi nella media storica, e nel periodo recente ha accelerato a circa quattro mesi. I modelli che il nostro sviluppatore usa (Claude Opus 4.5 prima, 4.6 adesso) sono quelli che nella ricerca METR hanno spostato la frontiera in modo misurabile, completando autonomamente compiti che a un esperto umano richiederebbero diverse ore.
La programmazione è il caso più favorevole possibile per l’AI. L’output è verificabile in modo automatico (compila o non compila, passa i test o non li passa), il corpus di addestramento è sterminato (tutto il codice open source del mondo), e il ciclo di feedback è immediato. Generalizzare dall’esperienza di un singolo sviluppatore a “tutto il lavoro cognitivo” sarebbe lo stesso errore che Matt Shumer commise nel suo post virale di febbraio, quello che Gary Marcus definì “hype weaponizzato”. Il coding è l’avanguardia, e il nostro programmatore ha ragione a dire che è lì che si vede prima dove arriva l’AI. Ma l’avanguardia per definizione non è la media.
Detto questo, il dato resta impressionante. E lui ha ragione anche su un altro punto che merita attenzione: chi non sta usando i modelli di frontiera (non quelli gratuiti, non quelli di sei mesi fa, quelli di adesso, quelli che costano venti dollari al mese) ha una percezione del cambiamento che è genuinamente distorta rispetto alla realtà. Il gap percettivo tra chi sperimenta questi strumenti ogni giorno e chi ne legge sui giornali è probabilmente il più grande da quando esiste l’AI generativa, e continua ad allargarsi.
La domanda che non si fa
La parte interessante del racconto non è però quella che lo sviluppatore racconta con orgoglio. È quella che non racconta, o che racconta senza rendersi conto che dovrebbe preoccuparlo.
Lui stesso ammette che nell’estate del 2025, quando faceva “vibe coding” accettando le modifiche dell’AI senza guardarle, una funzionalità gli era uscita “mezza rotta”. Se ne era accorto giorni dopo. Quella brutta esperienza lo ha portato a raffinare il processo, a introdurre la fase di pianificazione condivisa, a essere più preciso nelle istruzioni. E il processo raffinato funziona molto meglio, al punto che adesso il 95% delle volte va tutto bene.
Ma quel 5% che non va bene, in produzione, da cosa è rappresentato? È un bug che si trova subito? Un errore sottile che emerge dopo settimane? Un problema architetturale che si accumula nel tempo fino a rendere il software fragile in modi che nessun test automatico rileva? Non lo dice, e probabilmente non lo sa, perché per saperlo dovrebbe guardare il codice, che è esattamente la cosa che ha smesso di fare.
C’è un parallelo che mi sembra calzante. Chi usa sempre il navigatore GPS per i propri spostamenti, dopo qualche mese non sa più come organizzare un percorso. Non ha perso la capacità cognitiva di orientarsi: l’ha sospesa, per mancanza di esercizio. Il giorno in cui il GPS non funziona (batteria scarica, tunnel senza segnale, zona non mappata) quella persona si scopre in difficoltà in un modo che sarebbe stato impensabile prima di delegare la navigazione.
Il nostro sviluppatore sta facendo la stessa cosa con la comprensione del codice che il suo software produce. Il muscolo della lettura critica, quello che dopo dieci anni di esperienza ti fa “sentire” che qualcosa non torna in una funzione prima ancora di aver capito cosa, quel muscolo si indebolisce se non lo eserciti. E si indebolisce in modo silenzioso, perché il 95% delle volte tutto funziona e il feedback negativo non arriva.
La ricerca cognitiva ha un nome per questo fenomeno: cognitive offloading. Sparrow, Liu e Wegner lo documentarono già nel 2011 in un paper pubblicato su Science a proposito della memoria: sapere che un’informazione è recuperabile online riduce la probabilità che il cervello la registri. Il METR stesso ha pubblicato nel 2025 uno studio che merita più attenzione di quanta ne abbia ricevuta: i developer che usano strumenti AI per il coding impiegano in media il 19% in più, non in meno, dei colleghi che non li usano per completare gli stessi compiti. Il risultato sembra paradossale e probabilmente riflette una fase di adattamento, ma segnala che la relazione tra AI e produttività nel coding è meno lineare di quanto la narrazione entusiastica suggerisce.
Chi forma i futuri sviluppatori?
Il problema più serio che questa testimonianza solleva non riguarda chi l’ha scritta. Il nostro programmatore ha dieci anni di esperienza, ha scritto tanto codice a mano, ha sviluppato quel senso dell’architettura software che viene dalla pratica prolungata. Quando dice all’AI “no, questo così non lo voglio, lo voglio in un altro modo”, quel giudizio viene da un decennio di lavoro in cui ha visto cosa funziona e cosa no, cosa scala e cosa crolla, cosa è manutenibile e cosa diventa un incubo. L’AI amplifica quel giudizio accumulato. Fin qui, tutto bene.
Il problema è chi viene dopo di lui. Lo sviluppatore che entra oggi nel mercato del lavoro e che impara a programmare in un contesto dove il codice lo scrive l’AI e il suo ruolo è supervisionare un output che non ha mai imparato a produrre autonomamente. Toyota ha scoperto qualcosa di simile quando ha provato ad automatizzare completamente alcune linee di produzione: gli ingegneri che non lavoravano più a fianco delle macchine avevano perso la capacità di migliorare i processi, perché il kaizen (il miglioramento continuo che è il cuore del sistema produttivo Toyota) richiede una comprensione del processo che si sviluppa solo attraverso la pratica diretta.
Nel software il rischio è analogo. La conoscenza tacita dello sviluppatore esperto, quella che lo psicologo della scienza Michael Polanyi descriveva con la frase “sappiamo più di quanto riusciamo a dire”, si forma attraverso migliaia di ore di pratica: debugging, refactoring, lettura di codice altrui, tentativi falliti, architetture ripensate. Se la nuova generazione di developer salta questa fase formativa perché l’AI gestisce i compiti di base, la catena di trasmissione della competenza si interrompe. Si producono professionisti capaci di supervisionare l’AI quando tutto funziona, ma incapaci di intervenire quando l’AI fallisce in modi che non rientrano nei pattern noti.
Intelligente, o che fa cose intelligenti?
Nel suo racconto lo sviluppatore si scalda su un punto: dice che è “assurdo” negare che questi modelli manifestino una forma di intelligenza, e che chi lo fa sta negando l’evidenza. Poi aggiunge che non parla di autocoscienza, non parla di diritti, non parla di ontologia. Ma la sua retorica punta in una direzione che le sue premesse escludono.
La questione merita una sfumatura che nell’entusiasmo rischia di perdersi. Che l’AI faccia compiti che richiedono intelligenza è un fatto documentato. Che l’AI “sia intelligente” nel senso in cui lo è un essere umano è un’affermazione di natura diversa, e la seconda non discende automaticamente dalla prima. Un calcolatore del 1960 faceva compiti che richiedevano capacità matematica superiore a quella di qualsiasi essere umano, e a nessuno veniva in mente di attribuirgli intelligenza. La differenza di scala tra un calcolatore e un LLM è enorme, certo, e le capacità dei modelli attuali sono qualcosa che vent’anni fa sarebbe parso fantascienza. Ma il salto da “fa cose intelligenti” a “è intelligente” implica qualcosa che la filosofia della mente discute da decenni senza consenso, e che non si risolve con “è un fatto, punto”.
La distinzione è importante per una ragione pratica. Se l’AI “è intelligente” allora è un collega, e ci si rapporta con un collega diversamente da come ci si rapporta con uno strumento. Se l’AI “fa cose intelligenti ma è uno strumento”, allora la responsabilità dell’output resta interamente umana, e la supervisione critica non è un optional da esercitare quando capita ma un obbligo professionale che richiede competenza specifica.
La Legge 132/2025, che ha recepito in Italia l’AI Act europeo, ha scelto con chiarezza la seconda cornice. L’articolo 13 stabilisce che nelle professioni intellettuali l’AI può essere usata solo in funzione strumentale, con prevalenza del lavoro umano, e che il professionista deve comunicare al cliente quali strumenti AI ha utilizzato. L’articolo 14 fa lo stesso per la pubblica amministrazione, l’articolo 15 per l’attività giudiziaria, l’articolo 7 per la sanità. Il legislatore non ha dubbi: la responsabilità è umana, la supervisione deve essere sostanziale, e chi non la esercita si espone a conseguenze concrete.
Il vero messaggio
Lo sviluppatore ha ragione sulla cosa più importante: il cambiamento è reale, è rapido, e chi non lo tocca con mano ogni giorno fa fatica a capirne la portata. Tre mesi sono un’era geologica nella velocità attuale dell’AI, e le valutazioni fatte sul mondo di dicembre 2025 sono già parzialmente obsolete a marzo 2026.
Ma la conclusione da trarne non è quella che lui propone, e cioè che l’AI è intelligente e chi non lo ammette è indietro. La conclusione è che stiamo costruendo una dipendenza da uno strumento potentissimo di cui comprendiamo il funzionamento in modo ancora parziale, e che la velocità con cui lo adottiamo sta superando la velocità con cui capiamo cosa stiamo cedendo in cambio dell’efficienza che guadagniamo.
Lo dico con una certa cognizione di causa, perché la storia che ho raccontato non è solo la sua. È anche la mia, con una variante che la rende forse ancora più significativa. Io non sono mai stato un programmatore. Non ho dieci anni di esperienza nello sviluppo software, non ho mai scritto un’app iOS, non ho mai lavorato in un team di ingegneri. Eppure negli ultimi mesi ho costruito e messo in produzione applicazioni web funzionanti, con database, autenticazione, pagamenti, deploy su server reali. Le ho costruite conversando con l’AI, esattamente come fa il nostro sviluppatore: descrivo quello che voglio, discuto l’architettura, approvo il piano, e il codice arriva. Il termine che si usa è “vibe coder”, e io lo sono diventato “senza passare dal via”, dalla fase in cui si impara a programmare.
Se un sessantenne senza formazione tecnica riesce a costruire in poche ore quello che fino a ieri richiedeva un team e settimane di lavoro, la portata del cambiamento va oltre la comunità degli sviluppatori. Riguarda chiunque faccia lavoro cognitivo, perché dimostra che la barriera d’ingresso alle competenze tecniche si sta abbassando a una velocità che rende obsolete le categorie con cui pensavamo (e in realtà pensiamo ancora) il mercato del lavoro. E se questo da un lato è entusiasmante (io sono il primo a trovarlo straordinario), dall’altro rende ancora più urgente la domanda su cosa succede alla competenza profonda, a quella che si sviluppa solo attraverso anni di pratica, quando la pratica stessa diventa opzionale.
Il nostro sviluppatore ha smesso di guardare il codice. Io non ho nemmeno mai iniziato a farlo, e per ora funziona per entrambi. Il problema è che “per ora” potrebbe essere una finestra più corta di quanto pensiamo, e che il giorno in cui qualcosa si romperà in modi che l’AI non sa aggiustare, potremmo scoprire di aver perso qualcosa che non sapevamo nemmeno di aver bisogno di possedere.
Non è una storia di tecnofobia. Non sono un luddista, ma quello che mi preoccupa è la differenza tra usare uno strumento e dipendere da uno strumento, e il fatto che la seconda condizione tende a instaurarsi in modo silenzioso, confortevole, e molto difficile da invertire una volta che si è consolidata. Che è poi il motivo per cui mi sembra importante pensarci adesso, e non quando quel “5% che non funziona” diventerà il problema che nessuno di noi sa più risolvere a mano.