Cosa si intende per produttività nello sviluppo del software?
Perché la discussione in corso sullo sviluppo del software assistito da AI è quanto meno prematura, se non superficiale e distorta.
Qualche giorno fa avevo segnalato che l’uso degli assistenti AI nello sviluppo del software presenta spine e non solo rose.

In questi giorni, sui social continuo a leggere annunci e affermazioni forti secondo cui gli assistenti di AI come Claude Code stiano cambiando radicalmente le modalità di lavoro e le dinamiche del processo nel suo complesso. Ovviamente, questi strumenti sono molto potenti e promettenti, ma molti annunci sono prematuri e, per molti aspetti, superficiali, distorti e anche controproducenti. Vediamo perché.
Innanzitutto, bisogna ricordare che sviluppare software è molto più di “scrivere linee di codice”. Il codice deve essere progettato, testato, integrato e gestito (ci sono sempre errori da correggere e estensioni da apportare). Per cui, per valutare la produttività, bisogna considerare il processo end-to-end e non solo la fase di coding in senso stretto.
Inoltre, per la manutenzione abbiamo bisogno di persone esperte sia delle tecnologie sia delle architetture applicative, nonché del dominio applicativo. Questo know-how non può essere “solo” detenuto dall’AI, anche quando, in linea di principio, fosse tecnicamente possibile. Banalmente, chi è responsabile dei danni causati da un errore? Ovviamente, non è né Claude né un assistente AI, quindi l’essere umano deve essere in grado di verificare e rispondere di ciò che è stato sviluppato.
Peraltro, oggi spesso non si “scrive codice”, ma si personalizzano le piattaforme. Molti progetti riguardano la customizzazione di sistemi come Salesforce. Non c’è solo “coding” classico.
Se andiamo a vedere le esperienze che emergono dall’uso di assistenti AI, ci si accorge che questi rischi e problemi sono chiaramente evidenti.
In un post del 29 gennaio 2026, Anthropic presenta i risultati di uno studio sull’impatto dell’AI sullo sviluppo delle competenze degli ingegneri del software. Riporto alcuni passaggi molto significativi.
In primo luogo, gli autori richiamano il concetto di cognitive offloading che segnalavo nel mio precedente post:
It’s unclear whether this cognitive offloading can prevent people from growing their skills on the job, or—in the case of coding—understanding the systems they’re building. Our latest study, a randomized controlled trial with software developers as participants, investigates this potential downside of using AI at work.
This question has broad implications—for how to design AI products that facilitate learning, for how workplaces should approach AI policies, and for broader societal resilience, among others. We focused on coding, a field where AI tools have rapidly become standard. Here, AI creates a potential tension: as coding grows more automated and speeds up work, humans will still need the skills to catch errors, guide output, and ultimately provide oversight for AI deployed in high-stakes environments. Does AI provide a shortcut to both skill development and increased efficiency? Or do productivity increases from AI assistance undermine skill development?
In secondo luogo, lo studio ha rilevato una perdita di capacità statisticamente significativa.
We found that using AI assistance led to a statistically significant decrease in mastery. On a quiz that covered concepts they’d used just a few minutes before, participants in the AI group scored 17% lower than those who coded by hand, or the equivalent of nearly two letter grades. Using AI sped up the task slightly, but this didn’t reach the threshold of statistical significance.
Interessanti alcune considerazioni finali:
Our results suggest that incorporating AI aggressively into the workplace, particularly with respect to software engineering, comes with trade-offs. The findings highlight that not all AI-reliance is the same: the way we interact with AI while trying to be efficient affects how much we learn. Given time constraints and organizational pressures, junior developers or other professionals may rely on AI to complete tasks as fast as possible at the cost of skill development—and notably the ability to debug issues when something goes wrong.
Si noti che gli ingegneri del software non “nascono” già senior, quindi la formazione e lo sviluppo delle competenze dei junior sono un passaggio importantissimo per lo sviluppo delle capability dell’impresa.
Though preliminary, these results suggest important considerations as companies transition to a greater ratio of AI-written to human-written code. Productivity benefits may come at the cost of skills necessary to validate AI-written code if junior engineers’ skill development has been stunted by using AI in the first place. Managers should think intentionally about how to deploy AI tools at scale, and consider systems or intentional design choices that ensure engineers continue to learn as they work—and are thus able to exercise meaningful oversight over the systems they build.
Simili considerazioni emergono da un post di cio.com di poche ore fa che riprende proprio il tema della produttività che citavo in precedenza.
The deployment of AI copilots into the workflows of experienced engineers isn’t producing the frictionless acceleration promised in the brochures. Instead, I’m seeing the emergence of a productivity trap — a hidden tax on velocity that is disproportionately hitting your most valuable technical talent.
When I write code from scratch, I am doing forward-engineering. I build a mental model of the logic. I know why every variable exists. If a bug appears, I can trace my own steps back to the error.
When I use an AI, I am forced into reverse-engineering. I get a block of code I didn’t write. I have to read it, decipher the intent of the model and then map that intent against the requirements of my system.
Sono solo alcune delle riflessioni che, vorrei essere chiaro, non devono rallentare le sperimentazioni e le applicazioni pratiche. Esse devono essere fatte, ma con raziocinio e senza cadere vittime della fascinazione per le tecnologie. Lo dico io che ovviamente ne sono un cultore!
Quello che intendo dire è che serve tanta tanta prudenza e che le competenze delle persone non sono sostituibili dall’AI.


