L'intelligenza artificiale non sostituirà
chi sviluppa software

«Fra due anni i programmatori non serviranno più.» Lo si sente dire da almeno tre anni. Intanto chi scrive software continua a lavorare, e chi ha provato a farne a meno affidandosi solo all'intelligenza artificiale ha scoperto una cosa poco comoda: il modello ti dà una risposta sempre, anche quando è sbagliata, e per accorgertene devi già sapere la risposta.

Questo articolo non è una difesa d'ufficio. Sono dati misurati, con le fonti in fondo.

Il paradosso della produttività

Nel 2025 METR ha condotto uno studio controllato randomizzato su 16 sviluppatori open source esperti, su 246 attività reali prese dai loro stessi repository — non esercizi, ma codice che conoscevano da anni.

Il risultato ha sorpreso anche i ricercatori: con gli strumenti di intelligenza artificiale gli sviluppatori hanno impiegato il 19% di tempo in più. La parte interessante viene dopo: alla fine dell'esperimento gli stessi sviluppatori stimavano di essere stati il 20% più veloci.

Va detto con onestà che METR stessa considera oggi quel risultato storico, riferito agli strumenti disponibili fra febbraio e giugno 2025, e ha rivisto il disegno sperimentale. Ma il punto che conta non è la percentuale: è il divario fra percezione e misura. Chi usa questi strumenti si sente più veloce. È una sensazione, e non coincide necessariamente con la realtà.

Le allucinazioni non sono un dettaglio

Uno studio presentato a USENIX Security 2025 ha generato 2,23 milioni di campioni di codice con 16 modelli diversi, in Python e JavaScript, per contare quante volte i modelli citavano librerie che non esistono.

Il tasso andava dal 5,2% dei modelli commerciali al 21,7% di quelli aperti. Un dettaglio inquietante: ripetendo dieci volte lo stesso prompt, il 43% dei nomi inventati ricompariva ogni singola volta. Non è rumore casuale, è una convinzione stabile del modello.

Da qui nasce lo slopsquatting: qualcuno registra davvero, su npm o PyPI, un pacchetto con il nome che i modelli si inventano, e aspetta che qualcuno lo installi senza controllare. Una ricerca del 2026 sui modelli di frontiera mostra tassi più bassi, fra il 4,6% e il 6,1%: il problema si è ridotto, non è sparito.

Uno sviluppatore esperto, davanti a un import di una libreria che non ha mai sentito nominare, va a controllare. Chi non lo è, la installa.

Il caso dei database

C'è una categoria di problemi in cui la differenza fra chi sa e chi non sa diventa evidente: tutto ciò che vive fra i sistemi invece che dentro un file.

Un modello scrive senza fatica una query o una funzione. Le cose si complicano quando il lavoro riguarda la connessione fra le parti: il pool di connessioni dimensionato male che sotto carico esaurisce le connessioni disponibili; gli indici che mancano e che nessuno nota finché la tabella non ha cento righe; le migrazioni da applicare su un database che contiene già dati di clienti veri; l'isolamento delle transazioni e le condizioni di concorrenza, che non si manifestano quasi mai in sviluppo e quasi sempre in produzione.

Sono problemi che richiedono di tenere insieme il modello dei dati, l'infrastruttura, il traffico reale e il comportamento dell'applicazione. Il modello vede il pezzo che gli hai mostrato, e risponde su quello. Non conosce il resto, e non ti dice che non lo conosce: propone comunque una soluzione, con lo stesso tono sicuro che userebbe per una cosa giusta.

È qui che nasce la giornata persa. Chi non ha le competenze rimane in un ciclo: chiede, prova, non funziona, richiede, prova di nuovo. Chi le ha, guarda il messaggio d'errore e sa già dove intervenire — e usa il modello per scrivere in fretta la soluzione che ha già in testa.

Il conto arriva sulla sicurezza

Nel 2022, alla IEEE Symposium on Security and Privacy, lo studio «Asleep at the Keyboard?» ha analizzato 1.689 programmi generati in 89 scenari costruiti sulle vulnerabilità più diffuse. Circa il 40% dei suggerimenti conteneva una vulnerabilità.

L'anno dopo, alla conferenza ACM CCS, un gruppo di ricercatori di Stanford ha fatto la domanda dal lato opposto: le persone scrivono codice più insicuro quando hanno un assistente? La risposta è stata sì. I partecipanti con accesso all'assistente hanno prodotto codice significativamente meno sicuro — in particolare su cifratura e SQL injection — e allo stesso tempo erano più convinti di aver scritto codice sicuro.

Lo stesso studio contiene però il dato più utile di tutti: i partecipanti che riformulavano i prompt e interrogavano di più lo strumento producevano meno vulnerabilità. Non è lo strumento a determinare il risultato. È chi lo usa.

La conseguenza è prevedibile: nei prossimi anni una quota crescente di siti e applicativi sarà costruita da chi non ha mai studiato né architettura né sicurezza applicativa. Quelle applicazioni funzioneranno — finché qualcuno non andrà a guardarci dentro. E chi le ha commissionate scoprirà che il GDPR, all'art. 32, chiede misure di sicurezza adeguate al rischio, e che risponde il titolare del trattamento, non chi ha scritto il prompt.

Chi sa riconoscere l'errore

Il filo che lega tutte queste ricerche è uno solo: il modello non sa di sbagliare. Non esiste, nella risposta, un segnale che distingua quella corretta da quella inventata. Il tono è identico.

L'unico filtro possibile è la competenza di chi legge. Chi ha studiato riconosce la query che non scalerà, la configurazione che apre un buco, la libreria che non esiste, il pattern che funziona in demo e crolla con cento utenti in contemporanea. Non perché sia più intelligente del modello, ma perché ha un contesto che il modello non ha: il sistema intero, il cliente, i dati veri, quello che è già andato storto altre volte.

Vale anche sul piano normativo. L'AI Act, all'art. 4, introduce un obbligo di alfabetizzazione in materia di IA per chi la usa per conto di un'organizzazione: la competenza non è più solo un vantaggio professionale, sta diventando un requisito. Ne abbiamo scritto nella guida all'AI Act.

Uno strumento, non un sostituto

Nulla di tutto questo significa che l'intelligenza artificiale sia inutile. È esattamente il contrario: usata da chi sa cosa sta facendo è uno degli strumenti più utili degli ultimi anni. Scrive il codice ripetitivo, esplora una libreria sconosciuta, propone alternative, aiuta a ragionare su un problema, riscrive un test in un attimo.

Ma è uno strumento. Come un bisturi: la sua efficacia dipende interamente da chi lo tiene in mano. Non velocizza automaticamente il lavoro — lo studio METR lo mostra bene — e sposta l'asticella delle competenze richieste verso l'alto, non verso il basso. Servono più architettura, più sicurezza applicativa, più capacità di leggere criticamente ciò che una macchina produce.

Il rischio vero non è che l'AI sostituisca chi sviluppa software. È che qualcuno se ne convinca, metta online un sistema che gestisce dati di persone senza che nessuno ne abbia mai valutato l'architettura, e scopra il problema quando è troppo tardi per rimediare a basso costo.

Parliamo del tuo progetto

Fonti

• METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity» (arXiv:2507.09089, luglio 2025) — arxiv.org/abs/2507.09089
• J. Spracklen et al., «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs», USENIX Security 2025 (arXiv:2406.10279) — arxiv.org/abs/2406.10279
• H. Pearce et al., «Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions», IEEE Symposium on Security and Privacy 2022 (arXiv:2108.09293) — arxiv.org/abs/2108.09293
• N. Perry, M. Srivastava, D. Kumar, D. Boneh, «Do Users Write More Insecure Code with AI Assistants?», ACM CCS 2023 (arXiv:2211.03622) — arxiv.org/abs/2211.03622
• Regolamento (UE) 2024/1689 (AI Act) — obbligo di alfabetizzazione in materia di IA, art. 4 — eur-lex.europa.eu/legal-content/IT/TXT/PDF/?uri=OJ:L_202401689