Contenuto articolo
La “morte del programmatore” è stata annunciata così tante volte, e con tale insistenza, da essere diventata quasi un genere letterario della Silicon Valley. Da Jensen Huang di Nvidia che invita a non imparare più il C++, fino ai CEO delle startup che promettono intere app generate da un prompt. L’hype è visibile, accecante. Quello che si vede meno, però, è una frattura silenziosa che si sta aprendo sotto i piedi dell’industria tech. Una biforcazione che distingue, forse per la prima volta in modo davvero netto, chi “scrive codice” da chi “costruisce software”.
I numeri parlano chiaro e arrivano dal Bureau of Labor Statistics (BLS) degli Stati Uniti, l’ente che monitora il polso del mercato del lavoro americano. Nelle proiezioni per il decennio 2024-2034 emerge una divergenza brutale. Da un lato abbiamo i “computer programmers”, figure focalizzate sulla scrittura e il test del codice, il cui impiego è previsto in contrazione del 6%. Dall’altro i “software developers”, coloro che progettano, mantengono e architettano sistemi: per loro si prevede un boom del 15%, un tasso di crescita definito “molto più veloce della media” di tutte le altre professioni, trainato da investimenti in sicurezza, IoT e automazione.
L’AI sta trasformando la sintassi in una commodity, ma sta rendendo la semantica il vero asset strategico.
Il cortocircuito dello studente
Per capire questa forbice occorre addentrarsi nella “scatola nera” di come l’intelligenza artificiale approccia lo sviluppo. Ed è qui che entra in gioco un paper pubblicato a marzo 2025 dal MIT, intitolato “Challenges and Paths Towards AI for Software Engineering”. Lo studio, firmato tra gli altri da Armando Solar-Lezama, scardina una delle narrative più popolari: l’idea che l’AI possa sostituire l’ingegnere del tutto.
“Le narrative popolari tendono a ridurre il software engineering a un esercizio da studente universitario”, spiega Solar-Lezama. Il professore si riferisce a quello scenario idealizzato dove qualcuno ti fornisce una specifica perfetta per una singola funzione isolata e tu devi solo implementarla. Quello che solitamente viene testato alle interview tecniche per le posizioni da dev. “Ma questa è solo una frazione infinitesimale del lavoro reale”.
Gli attuali Large Language Models (LLM) eccellono nella code generation (ad esempio nel produrre snippet di codice sintatticamente corretti) ma faticano ancora enormemente nel software engineering. Manca loro quello che i ricercatori chiamano “long-horizon planning”: la capacità di ragionare su come una decisione presa a riga 10 influenzerà la stabilità del sistema a riga 10.000, sei mesi dopo.
Oltre la linea di codice
Il problema è strutturale, non solo di potenza di calcolo. Alex Gu, primo autore dello studio del MIT, sottolinea come la scrittura di software reale richieda di navigare compromessi complessi: performance contro memoria, velocità di sviluppo contro manutenibilità, debito tecnico contro feature immediate. L’AI attuale non “ragiona” in questi termini; predice il prossimo token.
L’interazione tra sviluppatore e AI oggi avviene attraverso una “linea di comunicazione sottilissima”: l’AI restituisce codice opaco, senza spiegare il suo livello di confidenza o le alternative scartate. Se richiedi spiegazioni, la sycophancy prende subito il sopravvento. È come lavorare con un programmatore junior velocissimo ma muto, che ti consegna il compito senza dirti se è sicuro al 100% o se ha tirato a indovinare.
Inoltre, c’è il problema della memoria e del contesto. Nonostante le finestre di contesto (context window) dei modelli si stiano allargando a dismisura, l’AI non possiede un vero modello mentale della codebase completa. Non “ricorda” l’evoluzione storica del progetto, non sa perché tre anni fa è stata fatta quella scelta architetturale specifica che magari ora sembra strana ma serviva a evitare un bug critico col database.
L’illusione dei benchmark
Ed è qui che scatta l’inganno. Spesso vediamo benchmark trionfali (come SWE-bench) dove l’AI risolve problemi complessi. Ma questi test toccano solitamente poche centinaia di righe di codice o repository contenute. Il refactoring di un sistema legacy con milioni di righe, l’integrazione di sistemi distribuiti, o la riscrittura di core business logic su sistemi già in produzione: questi sono i terreni dove l’ingegnere umano non ha rivali, e dove l’AI tende ad avere il fiato corto.
La contrazione del 6% dei ruoli di pura programmazione rilevata dal BLS è la cronaca di questa obsolescenza annunciata. Chi si limita a tradurre istruzioni in C++ o Python sta vedendo il proprio valore eroso dall’automazione. Ma quel +15% per gli sviluppatori e ingegneri racconta l’altra faccia della medaglia: la complessità non sta sparendo, si sta solo spostando più in alto, verso l’astrazione.
Dal coding all’orchestrazione
Se la scrittura del codice diventa “cheap” e abbondante, il valore si sposta sulla capacità di giudizio. L’ingegnere del software del futuro assomiglierà sempre meno a chi scrive codice e sempre più a chi decide quale codice ha senso scrivere. L’obiettivo, suggerisce lo studio del MIT, dovrebbe essere liberare gli umani dai compiti di routine per concentrarsi su decisioni critiche e design di alto livello.
Siamo di fronte a un cambio di paradigma. Fino a ieri, il collo di bottiglia era la velocità di scrittura: quante righe di codice un umano poteva ragionevolmente produrre in una giornata lavorativa. Domani, il collo di bottiglia sarà la capacità di validare, integrare e dare senso strategico a una mole infinita di codice generato dalle macchine.
La posta in gioco è la qualità stessa del futuro digitale. Se deleghiamo totalmente la costruzione del software a sistemi che non sanno ragionare sul lungo termine, rischiamo di costruire grattacieli digitali con fondamenta di argilla.
Chi non ha mai imparato a ragionare sui trade-off architetturali, con l’AI non diventa un senior engineer: diventa solo un generatore di debito tecnico ad alta velocità.
Per questo i dati ci dicono che non stiamo andando verso la fine dello sviluppo software, ma verso la sua fase adulta. Non ci serve più chi sa parlare la lingua delle macchine (per quello ora abbiamo le macchine), ci serve chi sa decidere cosa dire. E, soprattutto, perché.
Per approfondire
-
BLS: Computer Programmers Outlook 2024-2034 — Le proiezioni ufficiali del governo USA: -6% di occupazione, con automazione e AI tra le cause principali.
-
BLS: Software Developers Outlook 2024-2034 — L’altro lato della medaglia: +15% di crescita trainata da AI, IoT e sicurezza informatica.
-
MIT: Challenges and Paths Towards AI for Software Engineering (arXiv) — Il paper completo (75 pagine) con tassonomia dei task, bottleneck e direzioni di ricerca.
-
MIT News: Can AI really code? — L’articolo divulgativo con citazioni dirette di Solar-Lezama e Gu.
-
SWE-bench — Il benchmark più usato per valutare AI su task di software engineering. Utile per capire cosa misurano (e cosa no) le metriche che leggiamo.
-
Jensen Huang: “Don’t learn to code” (TechRadar) — Il discorso del CEO Nvidia al World Government Summit (febbraio 2024) che ha scatenato il dibattito.
