L'AI Non Sostituirà gli Sviluppatori. Renderà Evidente Chi lo È Davvero.
C’è una frase che sento ripetere con insistenza crescente negli ultimi mesi: “L’AI sostituirà i programmatori.” La dicono manager che non hanno mai scritto una riga di codice, la rilanciano giornalisti in cerca di titoli acchiappa-click, la temono junior che hanno appena iniziato il loro percorso. E ogni volta che la sento, penso la stessa cosa: chi dice così non ha la minima idea di cosa significhi davvero sviluppare software.
Perché sviluppare software non è — e non è mai stato — solo “scrivere codice”.
Scrivere Codice è la Parte Facile
Lo dico da oltre vent’anni di esperienza sul campo, e lo ribadisco ogni volta che ho l’occasione di parlare con colleghi, clienti o studenti: la scrittura del codice è una frazione del lavoro di uno sviluppatore. Spesso non è nemmeno la parte più difficile.
Provate a chiedere a un LLM di negoziare i requisiti con un cliente che non sa cosa vuole ma sa benissimo cosa non vuole. Provate a chiedere a Claude o a ChatGPT di decidere se vale la pena introdurre un livello di astrazione in più nell’architettura, sapendo che tra sei mesi il team raddoppierà. Provate a fargli gestire il trade-off tra consegnare una feature incompleta venerdì o rischiare di perdere il contratto.
Non possono. Non perché siano “stupidi”, ma perché queste decisioni richiedono qualcosa che nessun modello statistico possiede: contesto umano, responsabilità e conseguenze reali.
Il lavoro vero inizia davanti alla lavagna, non davanti all'IDE. Photo by You X Ventures on Unsplash
Uno sviluppatore vero non è un traduttore di specifiche in codice. È un risolutore di problemi che opera in un ecosistema fatto di vincoli tecnici, vincoli di business, vincoli umani. E l’AI, per quanto potente, opera in uno spazio completamente diverso.
Il Vero Impatto: Diverso per Ogni Livello di Esperienza
Una delle cose che mi colpisce di più nel dibattito sull’AI è come venga trattato come un fenomeno monolitico. “L’AI cambierà lo sviluppo software” — sì, ma come lo cambierà dipende enormemente da chi sei e da quanta esperienza hai.
Lo Sviluppatore Junior
Per chi è alle prime armi, l’AI è un tutor sempre disponibile. E questo è fantastico. Quando io ho iniziato, per capire come funzionava un pattern dovevo comprare un libro, leggerlo, provare, sbagliare e riprovare. Oggi un junior può chiedere a un LLM di spiegargli il pattern Observer con un esempio in Delphi e ottenere una risposta ragionevole in tre secondi.
Ma c’è un rischio enorme che troppi sottovalutano: l’AI non sa quando sta insegnando qualcosa di sbagliato. E un junior non ha gli strumenti per accorgersene. Senza un mentore umano che faccia da filtro, il rischio è di costruire fondamenta fragili su codice che “funziona” ma è architetturalmente un disastro. L’AI accelera l’apprendimento, ma può anche accelerare l’acquisizione di cattive abitudini. Non è un caso che, secondo il survey Stack Overflow 2025, il 45% degli sviluppatori citi come principale frustrazione le “soluzioni AI che sono quasi giuste, ma non del tutto” — un “quasi” che per un junior senza esperienza è quasi impossibile da individuare.
Lo Sviluppatore Mid-Level
È qui che l’AI dà il meglio di sé. Lo sviluppatore con 3-7 anni di esperienza ha abbastanza competenza da valutare criticamente l’output di un LLM, ma trae enorme beneficio dal supporto nella scrittura di boilerplate, nella generazione di test, nell’esplorazione di API poco familiari. L’AI riduce il carico cognitivo sulle attività ripetitive, liberando energia mentale per le decisioni che contano.
Lo Sviluppatore Senior
Per un senior, l’AI è un moltiplicatore di forza. Non cambia cosa decide, ma comprime drasticamente il tempo tra una decisione architetturale e la sua implementazione. Ho visto personalmente la differenza: task che richiedevano mezza giornata di scaffolding ora si completano in un’ora. Ma le decisioni fondamentali — quale pattern usare, dove mettere i confini tra i moduli, come gestire la migrazione dei dati — restano saldamente umane.
Dal “Vibe Coding” al “Context Engineering”
A febbraio 2025, Andrej Karpathy — ex direttore dell’AI a Tesla e cofondatore di OpenAI — ha coniato il termine “vibe coding”: “There’s a new kind of coding where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Scrivi un prompt vago, l’AI genera codice, lo copi-incolli nel progetto e speri che funzioni. È l’equivalente informatico di cucinare seguendo la “vibrazione” invece della ricetta.
Il problema? Funziona per i demo, crolla in produzione.
Come negli scacchi, la differenza la fa la strategia, non la velocità delle mosse. Photo by Michał Parzuchowski on Unsplash
La cosa interessante è che lo stesso Karpathy, un anno dopo, ha dichiarato il vibe coding superato, introducendo il concetto di “agentic engineering”: non più prompt casuali, ma orchestrazione strutturata di agenti AI con supervisione umana, quality gates e review rigorosa. In pratica, anche chi ha inventato il termine si è reso conto che senza disciplina ingegneristica, il vibe coding è un vicolo cieco.
Parallelamente, è emerso il concetto di “context engineering” — un termine che Tobi Lutke, CEO di Shopify, ha definito come “l’arte di fornire tutto il contesto necessario affinché il task sia risolvibile dall’LLM”. Non si tratta più di scrivere prompt furbi, ma di fornire al modello specifiche precise, contesto architetturale, vincoli di progetto, convenzioni del codebase.
In pratica, stanno tutti scoprendo quello che ripeto da tempo: più sei bravo come sviluppatore, meglio sai usare l’AI.
È un paradosso solo apparente. Per scrivere un prompt efficace che generi codice di qualità, devi sapere esattamente cosa vuoi ottenere. Devi conoscere i pattern, le best practice, i trade-off. Devi avere quella che io chiamo “visione architetturale” — la capacità di vedere il sistema nel suo insieme, non solo la singola funzione.
Chi non ha queste competenze si ritrova a fare “vibe coding” permanente, producendo un accumulo di debito tecnico che prima o poi presenterà il conto. Con gli interessi.
E qui arriviamo a un punto che considero cruciale: fermati un secondo e pensaci. Se non hai le competenze per valutare quello che un’AI ti dice, ti stai fidando di un sistema probabilistico. Un sistema che probabilmente ti sta dicendo una cosa vera. Probabilmente. Sei sicuro di poterlo accettare? Quando il codice che generi gestisce transazioni finanziarie, dati sanitari o infrastrutture critiche, “probabilmente corretto” non è abbastanza. Devi avere le competenze per valutare criticamente quello che un’AI produce — altrimenti non stai programmando, stai giocando alla roulette con il software di qualcun altro. Martin Fowler, in un articolo del 2025, ha osservato che gli LLM possono affermare con sicurezza che tutti i test passano quando in realtà falliscono — e si chiede: “If that was a junior engineer’s behavior, how long would it be before H.R. was involved?” Ecco, se il tuo “collega AI” ha questo livello di affidabilità, forse è il caso di non dargli accesso incondizionato alla codebase di produzione.
La Questione della Responsabilità
C’è un punto che nel dibattito viene spesso glissato, e che invece considero fondamentale: la responsabilità.
Quando un sistema va in produzione e qualcosa non funziona — un data breach, un calcolo fiscale errato, un’interfaccia che causa errori medici — chi ne risponde? L’AI? Il prompt che hai scritto? Il modello che ha “allucinato” una validazione inesistente?
No. Ne rispondi tu. Lo sviluppatore. Il team. L’azienda.
L’AI può suggerire best practice di sicurezza, può generare codice che sembra sicuro. Ma non si assume nessuna responsabilità legale, etica o professionale. Ogni riga di codice generata da un LLM che finisce in produzione diventa tua responsabilità. E questo significa che devi essere in grado di:
- Leggere quel codice e capirlo fino in fondo
- Valutare se è sicuro, performante, manutenibile
- Decidere se è adeguato al contesto specifico
- Rispondere quando qualcosa va storto
Ogni riga di codice che va in produzione passa sotto la tua responsabilità — che l'abbia scritta tu o un LLM. Photo by Kevin Ku on Unsplash
Delegare la generazione del codice è possibile. Delegare la responsabilità del codice non lo è. E non lo sarà per molto tempo.
Il Mercato del Lavoro: Tra Opportunità e Rischi Concreti
Sarebbe ingenuo negare che l’AI avrà un impatto sul mercato del lavoro degli sviluppatori. Lo avrà, e in parte lo sta già avendo. Ma non nel modo catastrofico che certa stampa vorrebbe farci credere.
Partiamo dai dati: il Bureau of Labor Statistics americano prevede una crescita del 15% nell’occupazione degli sviluppatori software tra il 2024 e il 2034 — cinque volte più veloce della media di tutte le professioni (3%). Si stimano circa 129.000 nuove posizioni all’anno. Non è esattamente lo scenario di “sostituzione di massa” che ci raccontano. Il survey di Stack Overflow 2025, condotto su oltre 49.000 sviluppatori, conferma: il 64% non vede l’AI come una minaccia al proprio lavoro. Allo stesso tempo, un dato mi ha colpito: la fiducia nell’accuratezza dell’AI è scesa dal 40% al 29% anno su anno. L'80% usa strumenti AI, ma li usa con crescente consapevolezza dei limiti.
Detto questo, la domanda di “code monkey” — sviluppatori che traducono meccanicamente specifiche in codice — diminuirà. Questo è quasi certo. Se il tuo valore aggiunto principale è scrivere CRUD senza errori di sintassi, hai un problema. Non perché l’AI lo faccia meglio di te, ma perché lo fa abbastanza bene da rendere il tuo costo non giustificabile.
Ma la domanda di professionisti che sanno progettare sistemi, prendere decisioni architetturali, gestire la complessità e assumersi responsabilità — quella non solo non diminuirà, ma crescerà. Perché più codice viene generato più velocemente, più serve qualcuno che sappia valutarlo, integrarlo, mantenerlo e farlo evolvere. Non a caso, secondo il report Robert Half 2026, le posizioni in AI/ML sono cresciute del 163% nel 2025 e quelle in cybersecurity del 124% — servono più persone che sappiano costruire con l’AI e proteggersi dall’AI, non meno.
È la stessa dinamica che abbiamo visto con ogni salto tecnologico: i compilatori non hanno eliminato i programmatori, i framework non hanno eliminato gli architetti, il cloud non ha eliminato i system administrator. Ha cambiato cosa fanno, non se servono.
Il Pericolo Sottile: Qualità Sacrificata sull’Altare della Velocità
C’è un rischio che mi preoccupa più della sostituzione dei programmatori, ed è la commoditizzazione della qualità. Manager e decisori non tecnici vedono l’AI generare codice in secondi e pensano: “Perché paghiamo sviluppatori senior quando l’AI può fare lo stesso lavoro?”
La risposta è semplice: perché non è lo stesso lavoro.
Il software di qualità nasce da un processo ingegnerizzato con cura artigianale: rigore e ripetibilità, non estro casuale. Photo by Dan-Cristian Pădureț on Unsplash
Il codice generato dall’AI tende a essere “corretto in media” — funziona per i casi comuni, segue i pattern più frequenti nel training set. Ma il software di qualità vive nei dettagli: nella gestione degli edge case, nella resilienza agli errori, nella manutenibilità a lungo termine, nella sicurezza by design.
Non è solo la mia esperienza a confermarlo. I numeri sono impietosi. Il report Veracode 2025, che ha testato oltre 100 LLM su 80 task reali in Java, Python, C# e JavaScript, ha rilevato che il 45% dei campioni di codice generato dall’AI introduce vulnerabilità OWASP Top 10. Per Java il dato è ancora peggiore: 72%. L'86% del codice generato non difende dal cross-site scripting, l'88% è vulnerabile a log injection. La conclusione degli autori è lapidaria: “I modelli sono migliorati nel generare codice sintatticamente corretto, ma non nel generare codice sicuro.”
Uno studio di Stanford e NYU (“Asleep at the Keyboard?”), presentato all’IEEE Symposium on Security and Privacy, aggiunge un dettaglio che dovrebbe far riflettere chiunque: analizzando 89 scenari e 1.689 programmi generati da Copilot, circa il 40% conteneva vulnerabilità di sicurezza. Ma il dato più inquietante è un altro: gli sviluppatori che usavano l’assistente AI erano più propensi a credere di aver scritto codice sicuro rispetto a chi lavorava senza. In pratica, l’AI non solo introduce bug di sicurezza, ma genera anche una falsa confidenza in chi la usa senza il giusto spirito critico.
Ho visto questa dinamica con i miei occhi in consulenze recenti: management che decide di “velocizzare” lo sviluppo affidandosi pesantemente all’AI senza supervisione tecnica adeguata. Il risultato? Codice che passava i test funzionali ma era un incubo di sicurezza. SQL injection nascoste in query costruite con concatenazione di stringhe. Token di autenticazione memorizzati dove non dovevano essere. Validation logic apparentemente corretta ma bypassabile con input crafted.
L’AI non fa queste cose per malevolenza. Le fa perché ottimizza per la risposta più probabile, non per la risposta più sicura. E la differenza tra “probabile” e “sicuro” è esattamente dove si gioca il valore di uno sviluppatore competente.
Allora, Cosa Fare?
Se sei uno sviluppatore e ti stai chiedendo come posizionarti in questo nuovo scenario, il mio consiglio è diretto e senza giri di parole:
1. Impara a usare l’AI, subito. Non è opzionale. Ignorare questi strumenti oggi è come aver ignorato Internet nel 1998. Non devi diventare un esperto di machine learning, ma devi integrare gli LLM nel tuo flusso di lavoro quotidiano e capire dove eccellono e dove falliscono.
2. Investi nelle competenze che l’AI non può replicare. Architettura software, system design, analisi dei requisiti, comunicazione con gli stakeholder, gestione della complessità. Queste sono le competenze che ti rendono insostituibile, non la velocità di battitura.
3. Non smettere mai di capire il “perché”. L’AI ti dà il “come” — a volte bene, a volte male. Ma il “perché” dietro ogni decisione tecnica è ciò che separa un professionista da un operatore. Perché quel pattern e non un altro? Perché quell’architettura? Perché quel trade-off?
4. Pensa all’AI come a un junior molto veloce. Tu sei il senior. È la metafora che uso più spesso e che trovo più efficace: un’AI è come un developer junior incredibilmente veloce nel leggere documentazione e scrivere codice, ma che non ha esperienza di progetto, non conosce il contesto di business, e a volte prende scorciatoie discutibili. Il tuo ruolo è quello del senior che guida, orienta e revisiona. Non sono il solo a pensarla così: Addy Osmani, engineering lead di Google Chrome, descrive l’AI esattamente come “a fast but unreliable junior developer who needs constant oversight”. Se non fai code review su quello che produce l’AI con la stessa attenzione che dedicheresti al codice di un junior appena assunto, stai abdicando alla tua responsabilità professionale. L’AI è potente, ma ha bisogno di una direzione. Quella direzione sei tu.
5. Costruisci esperienza reale, non simulata. Lavorare su progetti reali, con utenti reali, con vincoli reali, con deadline reali — è questo che costruisce la competenza che l’AI non può darti. Nessun tutorial e nessun prompt può sostituire l’esperienza di un deploy andato male alle 3 di notte e la capacità di capire, sotto pressione, cosa è successo e come risolverlo.
Conclusione
L’intelligenza artificiale non è qui per sostituire gli sviluppatori. È qui per amplificare ciò che già siamo. Se sei un professionista competente, l’AI ti renderà più veloce, più produttivo, più efficace. Se non lo sei — se il tuo unico valore era scrivere codice meccanicamente — l’AI renderà questa lacuna impossibile da nascondere.
È un momento di selezione naturale professionale, e come ogni selezione, premia chi si adatta e penalizza chi rimane fermo. La buona notizia è che adattarsi non richiede di ricominciare da zero: richiede di fare ciò che ogni buon sviluppatore ha sempre fatto — continuare a imparare, restare curioso, non accontentarsi mai.
Il software di qualità continuerà ad aver bisogno di esseri umani competenti. L’unica domanda è: sarai tra quelli?
– Daniele Teti
Comments
comments powered by Disqus