Pagine

giovedì 5 marzo 2026

The big illusion is over: Artificial Intelligence is not replacing software developers

by Enrico Nardelli

(versione italiana qua)

Let me say upfront — to pre-empt the usual hasty comments from those who won't read to the end — that I do believe tools based on generative Artificial Intelligence (GenAI, hereafter) are genuinely useful in software development, as they are in many other fields. But we need to be able to tell dreams from reality.

In 2023, Big Tech CEOs were more or less unanimously declaring that GenAI would replace most software developers by 2025. As recently as March 2025, Dario Amodei, CEO of Anthropic, was claiming that within 3 to 6 months GenAI would be writing 90% of all code.

The story went that the future would be "agentic" — that developers would have digital colleagues who never slept and never complained and would therefore take their jobs.

2024 closed with no fewer than 152,000 employees laid off across the tech sector worldwide, while by December 2025 the number of layoffs had reached 123,000 — all of it justified, according to the executives themselves, as "realigning towards an AI-centric future."

2026 has now begun, and there is no trace of the miraculous transformations that until recently were being touted as certainties — as I had anticipated several months ago. There I cited the Generative AI Gap report from MIT's NANDA project, published in July 2025, which had found that despite $40 billion in global investment, a staggering 95% of GenAI pilot projects had failed to produce any measurable economic return. Most organisations were seeing a net impact of zero on their bottom line.

Here are some updates that help explain why.

The GitClear report of February 2025 examined 211 million lines of code modified in the open source repositories used by Big Tech, finding that between 2020 and 2024 there was a near-doubling (from 3.05% to 5.67%) in the proportion of code that is added and then deleted within two weeks — so-called code churn. This is a clear indicator of a progressive decline in the quality of software being produced. The only technological or organisational change of any significance that occurred over the same period is that the proportion of developers using GenAI tools rose from zero to 63%. Correlation is not causation, of course, but this looks very much like a smoking gun. Furthermore, the report also recorded an increase in duplicated code blocks and a decrease in code reuse. These too are signs of declining quality. A December 2025 study by CodeRabbit, analysing 470 pull requests on the GitHub platform (used by more than 100 million developers worldwide to share and collaboratively develop code), found that GenAI-generated code produces on average 1.7 times more issues than code written by humans.

Stack Overflow, following a survey involving nearly 50,000 developers across 177 countries, reported that the proportion of developers favourably disposed towards GenAI tools fell from over 70% in 2024 to around 60% in 2025. The main source of frustration, cited by 66% of respondents, was that GenAI-produced solutions are "almost right, but not quite" — which leads to wasted time fixing errors in the code generated this way. That said, 69% of them acknowledged that GenAI does increase productivity in software writing. Several studies carried out in 2024 found that this increase ranges from 10–20% for senior developers to 35–40% for junior ones, who are better placed to benefit from a system that has knowledge of virtually all the software ever written in the world.

These findings are corroborated by studies conducted by the Stanford software engineering productivity research group involving more than 100 developers at major technology companies, which showed that the productivity gains in software development achieved through the use of GenAI tools are on average between 10% and 20%. Using them uncritically for software development, however, risks being a very costly mistake in the long run. While the volume of code produced increases by almost 40%, its quality decreases, requiring additional time for correction. And these are just the short-term consequences. Over the medium or long term — that is, in the context of the adaptive maintenance of software systems that have been in operation for some time — the situation risks becoming explosive.

There are no results yet pointing in this direction, given how little time has passed, but two significant findings emerge from the Stanford group's studies. The first is that without strong discipline in keeping a company's codebase structured and organised in a clear and clean manner, productivity gains evaporate or even reverse. The second is that productivity gains are greatest for new, low-complexity projects, while they diminish considerably for mature, high-complexity ones.

Throughout 2025, the wonders of vibe coding were extolled — the approach to software development in which a developer interacts with GenAI in natural language to "materialise" a complex software system by describing its overall vision. The problem is that this approach is fine for a demo but not for production-grade systems, because — like a sandcastle — it does not hold up solidly over time. This is the so-called GenAI technical debt: the future costs that accumulate when, in the rush of software development, one takes advantage of GenAI's code generation speed without bothering with thorough checks and verification.

During 2025, an approach emerged — conceptually known for some time, though now gaining traction — called specification-driven development, in which the developer uses GenAI tools starting from a specification — that is, a high-level description of the desired behaviour of the entire system — defined by the developer and progressively refined in ever greater detail, also with the support of GenAI. In this way, one partially overcomes the main limitation of these tools, which are based on statistics rather than symbolic representation: their inability to represent concepts that abstract away from the literal context under examination. With this approach, the software developer transforms into a specification developer. It is too early to say where this will lead, however, not least because the problems afflicting GenAI systems will not be overcome until the statistical approach is coupled with the symbolic one. The need to review AI-generated code in order to be confident it can be trusted therefore remains, at least until that integration occurs — and no one can reliably say when that will be. Which means that graduates in informatics and informatics engineering will always be in high demand — but that is a separate conversation.

And then there is the ever-present elephant in the room when it comes to informatics systems: security.

The Veracode October 2025 report on the security of GenAI-generated code reveals that 45% of it contains at least one of the ten most critical vulnerabilities identified by OWASP (Open Worldwide Application Security Project). For Java programs the situation is even worse. This sheds light on another important point: since GenAI tools have been trained on all existing code, and Java systems contain — for partly historical reasons — far more vulnerabilities than those written in other languages, the code that GenAI generates for this language is correspondingly more flawed.

Finally, the most damaging effect of all: the decline in hiring for entry-level software development roles. Because companies believed GenAI could handle junior-level tasks, hiring for these profiles collapsed. In 2024, the 15 largest Silicon Valley companies hired 25% fewer people for positions requiring less than one year of experience, while the reduction at start-ups was 11%. In its wake, we will likely also see a decline in enrolments in university degree programmes and upper secondary school diploma courses centred on informatics.

A suicidal choice, at every level. If companies do not hire inexperienced young people, they will never be able to develop experienced leaders. If young people do not learn to develop informatics systems with their own minds, they will never be able to manage those developed by GenAI.

Companies that have understood how to use GenAI are deploying it to help people be more effective in their work, freeing them from repetitive, low-level tasks. Those that are blindly relying on GenAI to get rid of new hires or pay them less will be forced to think again — and it will hurt.

The pendulum always swings back. What do you think?

--
The original version (in italian) has been published by "StartMAG" on 16 February 2026.

La grande illusione infranta: l'Intelligenza Artificiale non sostituisce gli sviluppatori di software

di Enrico Nardelli

(english version here)

Anticipo subito - per evitare i soliti commenti frettolosi di chi non legge fino in fondo - che ritengo che gli strumenti basati sull'Intelligenza Artificiale generativa (IAGen, nel seguito) abbiano certamente un'utilità nello sviluppo del software, così come in molti altri settori. Ma dobbiamo essere in grado di distinguere i sogni dalla realtà.

Nel 2023 i capi delle Big Tech dicevano più o meno tutti che l'IAGen avrebbe sostituito la maggior parte degli sviluppatori software entro il 2025. Ancora a marzo 2025 Dario Amodei, il CEO di Anthropic, dichiarava che nel giro di 3-6 mesi l’IAGen avrebbe scritto il 90% del codice.

Si raccontava che il futuro sarebbe stato "agentico", che chi sviluppa software avrebbe avuto colleghi digitali che non dormivano mai e non si lamentavano mai e che, quindi, gli avrebbero sottratto il lavoro.

Il 2024 si era chiuso con ben 152.000 dipendenti del settore licenziati in tutto il mondo, mentre a dicembre 2025 i licenziamenti erano arrivati a 123.000. Il tutto, secondo le dichiarazioni degli stessi capi "per riallinearsi verso un futuro incentrato sull'IA".

È iniziato il 2026 e dei cambiamenti miracolosi dati per certi fino a poco fa non si vede traccia, come avevo anticipato già qualche mese fa. Lì citavo il rapporto Il Divario dell'IA Generativa del progetto NANDA del MIT, uscito a luglio 2025, che aveva registrato come, nonostante 40 miliardi di dollari di investimenti globali, un incredibile 95% dei progetti pilota di IAGen non era riuscito a produrre un ritorno economico misurabile. La maggior parte delle organizzazioni stava vedendo un impatto netto pari a zero sui propri profitti.

Ecco alcuni aggiornamenti che spiegano il perché.

Il rapporto di GitClear di Febbraio 2025 ha esaminato 211 milioni di linee di codice modificate negli archivi a sorgente aperto (open source repository) usati dalle Big Tech osservando che dal 2020 al 2024 si è verificato un incremento percentuale quasi doppio (da 3,05% a 5,67%) della quantità di codice che viene aggiunto e poi cancellato nel giro di due settimane (code churn). È questo un segno che indica una progressiva diminuzione della qualità del software prodotto. L'unico cambiamento tecnologico o organizzativo di una qualche rilevanza che è accaduto nello stesso intervallo di tempo è che la percentuale di sviluppatori che usa strumenti di IAGen è passata dallo zero al 63%. La correlazione non è causazione, certo, ma questa sembra essere una vera e propria "pistola fumante". Non solo, il rapporto ha registrato anche un aumento di blocchi di codice duplicati e una diminuzione del riutilizzo del codice. Anche questi sono segnali di diminuzione della qualità. Uno studio di CodeRabbit di Dicembre 2025 ha rivelato, analizzando 470 richieste di integrazione (pull request) di nuove parti di codice in programmi esistenti sulla piattaforma GitHub (usata da più di 100 milioni di sviluppatori in tutto il mondo per condividere codice informatico e collaborare al suo sviluppo), che il codice prodotto da IAGen crea mediamente 1,7 più problemi del codice prodotto da esseri umani

Stack Overflow, a seguito di un'indagine che ha coinvolto quasi 50.000 sviluppatori in 177 paesi, ha riportato che la percentuale favorevole all'utilizzo di strumenti di IAGen è calata da più del 70% nel 2024 a circa il 60% nel 2025. Il motivo principale di frustrazione nel loro utilizzo, riportato dal 66% degli sviluppatori, è che le soluzioni prodotte dall'IAGen sono "quasi corrette, ma non completamente", il che conduce a sprecare tempo nelle attività di correzione degli errori del codice ottenuto per questa via. Il 69% di loro ha comunque riconosciuto che l'IAGen aumenta la produttività nella scrittura del software. Diverse ricerche svolte nel 2024 hanno evidenziato che tale aumento va dal 10-20% dello sviluppatore senior al 35-40% di uno junior, che è in grado di trarre maggior vantaggio da un ambiente che conosce tutto il software sviluppato nel mondo.

Questi dati sono confermati anche dagli studi condotti dal gruppo di ricerca sulla produttività dell'ingegneria del software di Stanford su più di 100 sviluppatori delle maggiori aziende tecnologiche, che hanno evidenziato come l'aumento di produttività nello sviluppo di software ottenuto dall'uso di strumenti di IAGen sia mediamente tra il 10% e il 20%. Usarli acriticamente per lo sviluppo del software rischia però di essere un errore molto costoso a lungo termine. Infatti, mentre la quantità di codice realizzato aumenta di quasi il 40%, la sua qualità diminuisce, richiedendo tempo aggiuntivo per per essere corretto. E queste sono le conseguenze sul breve periodo. Nel medio o lungo, ovvero in un contesto di manutenzione adattiva di sistemi software che sono in funzione da parecchio tempo, la situazione rischia di essere esplosiva.

Non ci sono ancora risultati in questa direzione, considerato il poco tempo trascorso, ma dagli studi di questo gruppo di Stanford due elementi rilevanti emergono. Il primo è che in assenza di una forte disciplina nel mantenere il software dell'azienda strutturato e organizzato in modo chiaro e pulito i guadagni di produttività si annullano o addirittura si invertono. Il secondo è che i guadagni di produttività sono maggiori per progetti nuovi e di bassa complessità, mentre si affievoliscono notevolmente per progetti maturi e di alta complessità.

Per tutto il 2025 sono state decantate le meraviglie del vibe coding, l'approccio allo sviluppo del software nel quale uno sviluppare interagisce in linguaggio naturale con l'IAGen per "materializzare" un sistema software complesso di cui si descrive la visione generale. Il problema è che questo approccio va bene per fare una demo ma non per sistemi da usare a regime, perché – come un castello di sabbia – non rimane solidamente in piedi col passare del tempo. È il cosiddetto debito tecnico dell'IAGen, cioè i costi futuri che si accumulano quando nello sviluppo del software si approfitta, per sbrigarsi, delle velocità di generazione del codice di IAGen senza stare a fare tanti controlli e verifiche.

Nel corso del 2025 è emerso un approccio (che a livello concettuale era però noto da molto tempo) chiamato “sviluppo guidato dalla specifica” (specification driven development) nel quale lo sviluppatore usa gli strumenti di IAgen a partire di una specifica (cioè di una descrizione di massima del comportamento desiderato dell’intero sistema) da lui definita e via via precisata in modo sempre più dettagliato, anche con il supporto dell’IAgen. In tal modo si supera in qualche modo il maggior problema di questi strumenti, basati sulla statistica e non sulla rappresentazione simbolica, cioè quello di essere in grado di rappresentare concetti che astraggono rispetto al contesto letterale preso in esame. Lo sviluppatore di software si trasforma con quest’approccio in uno sviluppatore di specifiche. È presto per dire però dove si arriverà con questo approccio, anche perché i problemi che affliggono i sistemi di IAgen non verranno superati fino a che l’approccio statistico non sarà accoppiato a quello simbolico. Rimane quindi ancora in piedi, almeno fino a questa integrazione (che nessuno può dire in modo affidabile quando avverrà) la necessità di controllare il codice prodotto per essere sicuri di potersi fidare. Il che implica che di laureati in informatica e ingegneria informatica ci sarà sempre un gran bisogno, ma questo è un altro discorso.

E poi c'è il solito "convitato di pietra" quando si parla di sistemi informatici: la sicurezza.

Il rapporto Veracode di ottobre 2025 sulla sicurezza del codice generato dall'IAGen rivela che il 45% di questo contiene almeno una delle 10 vulnerabilità più importanti secondo l'OWASP (Open Worldwide Application Security Project = Progetto per la sicurezza mondiale delle applicazioni open source, gestito dall'omonima fondazione no-profit). Per i programmi scritti in Java la situazione è ancora peggiore. Questo getta luce su un altro elemento importante: dal momento che gli strumenti IAGen sono stati addestrati su tutto il codice esistente, e i sistemi in Java contengono, per ragioni anche storiche, molte più vulnerabilità di quelli in altri linguaggi, i programmi che vengono generati dall'IAGen per questo linguaggio sono più difettosi.

Infine l'effetto più dannoso: la diminuzione delle assunzioni nelle posizioni iniziali dello sviluppo software. Siccome le aziende pensavano che l'IAGen potesse gestire compiti di livello junior, le assunzioni per questi profili sono crollate. Nel 2024 le 15 maggiori aziende della Silicon Valley hanno assunto il 25% in meno nelle posizioni con meno di un anno di esperienza, mentre la riduzione è stata dell'11% nelle start-up. A seguire, vedremo probabilmente anche una diminuzione delle iscrizioni ai corsi di laurea universitari e ai corsi di diploma di scuola secondaria superiore centrati sull'informatica.

Una scelta suicida, a tutti i livelli. Se le aziende non assumono giovani inesperti, non saranno mai in grado di formare leader esperti. Se i giovani non imparano a sviluppare sistemi informatici con la propria testa, non saranno mai in grado di gestire quelli sviluppati dall'IAGen.

Le aziende che hanno capito come usare l’IAGen la stanno mettendo in gioco per aiutare le persone a essere più efficaci nel loro lavoro, liberandole da compiti ripetitivi e di basso livello. Quelle che si stanno affidando ciecamente all’IAGen per liberarsi di neo-assunti o pagarli di meno, saranno costrette a ricredersi dolorosamente.

Il pendolo torna sempre indietro. E voi che ne pensate?

--
Versione originale pubblicata su "StartMAG" il 2 marzo 2026.