AI coding consapevole – Qualità, sicurezza e produttività

Qualità, manutenibilità e fiducia nel codice generato dall’AI

L’illusione di correttezza

Gli LLM (Large Language Models) sanno fare benissimo ciò per cui sono stati addestrati: produrre testi plausibili.
Generano codice sintatticamente corretto, ben formattato e commentato. Questo aspetto professionale abbassa la soglia critica di chi lo esamina, fenomeno noto come automation bias [1], amplificato dai ritmi dello sviluppo Agile: una pull request che sembra funzionare tende a passare con meno scrutinio di una scritta da zero.

La distinzione cruciale è tra codice plausibile e codice corretto: un modello linguistico genera sequenze di token statisticamente verosimili, non ragionamenti causali sul comportamento a runtime. Può gestire correttamente il caso standard ma fallire sugli edge case non rappresentati nel prompt, o estrapolare un pattern architetturale corretto nel contesto di origine per applicarlo in modo inadatto altrove.

Degrado della manutenibilità

Quando ogni interazione con l’AI è contestualmente locale — il modello vede il prompt e qualche file di contesto — si rischia un “effetto Frankenstein”: una codebase di pezzi singolarmente corretti ma privi di coerenza stilistica e architetturale. Non ci si può aspettare che un LLM acquisisca implicitamente la comprensione dell’architettura complessiva, delle decisioni di design, delle astrazioni costruite dal team.

Il debito tecnico che ne deriva non emerge nei singoli commit ed è difficile da intercettare in code review, a meno che il revisore abbia una conoscenza profonda dell’intero sistema. Secondo il rapporto “State of AI-Powered Engineering“ 2026 di Lightrun, il 43% del codice AI-generato ha richiesto debugging manuale in produzione, con un aumento dei cicli di redeployment e una riduzione dell’osservabilità complessiva [2].

Ownership del codice e debito tecnico invisibile

Scrivere una funzione da zero comporta un processo cognitivo che produce comprensione sia di cosa fa il codice sia di perché è strutturato in quel modo — una risorsa a cui attingere per spiegarlo, debuggarlo o modificarlo.
Quando la stessa funzione è generata da un assistente AI e accettata con modifiche marginali, questa comprensione non si sviluppa: si è autori del commit, ma non nel senso cognitivo del termine.

Le code review rischiano due derive ugualmente problematiche:

1. accettare quasi passivamente il codice AI-generato assumendone l’affidabilità senza comprenderlo a fondo;
2. investire molto più tempo per verificarlo rispetto a quello necessario a generarlo.

Il caso Amazon [3] è emblematico: un’interruzione del servizio, parzialmente attribuita a modifiche introdotte da un assistente AI, ha portato l’azienda a introdurre controlli più stringenti e a rallentare deliberatamente il deployment.

L’elemento significativo non è l’incidente in sé, ma la scelta di reintrodurre in maniera forzata un “attrito controllato“ in un processo accelerato dall’AI. La morale suggerita è che un’elevata velocità di generazione del codice senza adeguati meccanismi di controllo possa contribuire all’instabilità sistemica.

Il debito tecnico invisibile è il rischio più difficile da gestire, poiché non produce segnali immediati: a differenza di un bug che causa un crash visibile, un’architettura degradata produce fragilità latente che emerge solo sotto stress — picchi di carico, modifiche di feature, scaling — quando è già diffusa nell’intera codebase.

Sicurezza, vulnerabilità e il “CVE surge” dell’AI-generated code

Pattern insicuri e superficie d’attacco

Gli LLM sono addestrati su grandi quantità di codice pubblicamente disponibile, che includono inevitabilmente codice vulnerabile e pattern deprecati, i quali vengono potenzialmente replicati in assenza di vincoli di sicurezza espliciti nel prompt.

La Cloud Security Alliance ha pubblicato ad aprile 2026 un’analisi empirica dei commit assistiti da AI, rilevando una densità di vulnerabilità circa 10 volte superiore rispetto ai commit tradizionali, con un incremento significativo dei CVE (Common Vulnerabilities and Exposures) attribuibili a codice generato da AI [4].

La questione è in parte matematica: se l’AI consente di generare codice 2, 5 o 10 volte più velocemente ma la capacità di security review non scala proporzionalmente, il risultato netto è un aumento della superficie d’attacco. Il rapporto introduce il concetto di security debt accelerato dall’AI: mentre il debito tecnico tradizionale si accumula lentamente per scelte architetturali subottimali, quello assistito da AI può crescere alla stessa velocità di produzione del codice.

Responsabilità, attribuzione e il caso Moonwell

In molte organizzazioni i sistemi di incident response si basano sull’assunto che qualcuno conosca il codice coinvolto. Quando quel codice è stato generato automaticamente e approvato distrattamente, questa assunzione cade, e la questione della responsabilità in caso di vulnerabilità rimane aperta.

In marzo 2026, il protocollo DeFi Moonwell ha perso circa 1,78 milioni di dollari [5] in un exploit legato a un bug nella definizione del prezzo del token cbETH [6]. L’analisi post-mortem, secondo il parere del security auditor Pashov, ha rivelato che il codice vulnerabile [7] era stato scritto con assistenza di Claude Opus, e che il bug riguardava un edge case che uno sviluppatore con piena ownership del codice avrebbe probabilmente esaminato con maggiore attenzione. Il caso è illustrativo non perché l’AI abbia “causato“ l’exploit in senso diretto, ma perché documenta come la strada da “codice AI-assisted” a “vulnerabilità in produzione” sia percorribile anche in sistemi reali con conseguenze finanziarie concrete.

Workflow e rischi del “vibe coding”

Compressione del ciclo e collasso del design thinking

Uno degli effetti più profondi degli assistenti AI è la compressione del tempo che passa dall’idea all’artefatto. Il vibe coding — termine coniato da Andrej Karpathy nel febbraio 2025 per descrivere l’approccio in cui lo sviluppatore interagisce con l’AI tramite descrizioni ad alto livello accettando il codice generato con modifiche minime — tende a collassare in un unico flusso prompt-driven le fasi tradizionalmente distinte di: comprensione del problema, design, prototipazione, implementazione e testing.

Forbes, in un’analisi del fenomeno pubblicata ad aprile 2026 [8], suggerisce che questa compressione scavalca i meccanismi consolidati di controllo della qualità e di esercizio del giudizio ingegneristico. La fase di design è normalmente il momento per ragionare sui trade-off, identificare i vincoli del problema, considerare gli edge case e le invarianti del sistema. Quando viene sostituita da un prompt, questi passaggi non vengono eseguiti da nessuno. Il risultato non è necessariamente codice sbagliato nell’immediato, ma parti aggiunte senza la comprensione dei vincoli al contorno — fragilità che emerge solo quando il sistema evolve.

Ottimizzazione locale vs degrado globale

Il vibe coding può produrre un’ottimizzazione locale a costo di un degrado globale: la velocità aumenta in modo tangibile sui singoli sprint, ma su orizzonti più lunghi si rischia di ottenere un sistema che nessuno conosce davvero nella sua interezza. La reintroduzione deliberata di attrito nei processi di Amazon [3] è una risposta empirica concreta a questo fallimento — non luddismo, ma una correzione empirica dopo aver osservato le conseguenze nocive di un ciclo di sviluppo eccessivamente compresso.

La narrativa della produttività: metriche e costi nascosti

Output vs outcome

“L’AI aumenta la produttività degli sviluppatori“ è una delle affermazioni più diffuse nel dibattito sull’adozione dell’AI. La domanda è: cosa misura esattamente questa produttività?

La maggior parte degli studi misura linee di codice per unità di tempo, PR approvate per sprint, velocità di completamento di task isolati — metriche con due limiti critici: misurano l’output e non l’outcome, e non valutano i costi a valle. IBM sottolinea che la produttività va misurata end-to-end, includendo costo, velocità, ragionamento e valore per gli utenti, non solo il throughput locale [9].

Un team che genera il 40% di codice in più per sprint ma accumula il doppio dei bug non è più produttivo: sta solo spostando i costi nel tempo, rendendoli meno visibili. I dati di Uplevel, pubblicati nel settembre 2024 [10], mostravano un risultato provocatorio: un guadagno netto di produttività praticamente nullo nonostante un aumento del volume di pull request, accompagnato da un incremento del review time e dei merge conflict.

Sebbene la ricerca in questione faccia riferimento a tecnologie ormai vecchie di due anni, e nonostante altri studi mostrino risultati positivi in contesti specifici, pare lecito affermare che una maggiore quantità di codice generato non implichi automaticamente una maggiore produzione di valore.

La “review tax“ come costo nascosto

Il costo e il tempo si spostano dal developer che produce il codice al reviewer che lo esamina. In molti casi, la revisione del codice generato da AI è più onerosa di quella del codice scritto da uno sviluppatore esperto, sia per la quantità di codice, sia perché richiede la verifica di aspetti — correttezza semantica, coerenza architetturale, gestione degli edge case — che nel codice tradizionale erano implicitamente garantiti dalla comprensione del developer. Il rapporto Lightrun [2] quantifica questo in termini di aumento dei cicli di redeployment e dei tempi di debugging in produzione: costi reali, ma che non appaiono nelle metriche di sprint velocity.

Velocità

Un dato interessante viene da METR (Model Evaluation & Threat Research), che ha condotto uno studio su sviluppatori open source esperti nel primo trimestre 2025.

Contrariamente alle aspettative, gli sviluppatori AI-assisted non erano significativamente più veloci su task di complessità reale, e in alcuni casi erano più lenti [11]. Il vantaggio di produttività dell’AI potrebbe quindi essere concentrato in task semplici e ripetitivi — esattamente quelli meno rilevanti per la creazione di valore ingegneristico. Il campione (sviluppatori open source esperti) potrebbe non essere rappresentativo, ma il dato è sufficiente a giustificare uno scetticismo verso le generalizzazioni sulla produttività.

Per completezza, va detto che un altro studio della stessa organizzazione [12] a pochi mesi di distanza riporta stime più ottimistiche, in seguito alla diffusione ed evoluzione dei tool di AI-coding. Al contempo, rileva una maggiore difficoltà di ottenere dati significativi per via di un “effetto di selezione“: gli sviluppatori coinvolti hanno scelto di non includere nell’esperimento quei task che non avrebbero più voluto completare senza AI – aspetto a mio parere abbastanza significativo, che tratto nel secondo articolo “AI coding consapevole – Competenze, carico cognitivo e fragilità epistemica“.

Conclusioni

L’adozione degli strumenti di AI coding sta modificando profondamente il modo in cui il software viene progettato, scritto e mantenuto. I vantaggi in termini di velocità e automazione sono concreti, ma rischiano di condurre a fragilità pericolose quando vengono valutati esclusivamente attraverso metriche di throughput o produttività apparente.

Qualità del codice, sicurezza applicativa, coerenza architetturale e sostenibilità dei workflow non possono essere considerate conseguenze automatiche dell’accelerazione introdotta dagli LLM. Al contrario, l’analisi mostra come l’aumento della velocità di generazione del codice renda ancora più centrale il ruolo delle pratiche di governance, della revisione critica e della progettazione consapevole.

L’AI non elimina la necessità di ragionare sui trade-off, ma rischia al contrario di mascherarli e renderli meno visibili, guidati dalla promessa della rapidità nel breve periodo. Per questo motivo, introdurre “attrito controllato” nei processi di sviluppo non rappresenta un passo indietro, ma una forma di tutela della qualità tecnica e della stabilità dei sistemi.

Nel mio secondo articolo analizzerò gli impatti meno immediati ma potenzialmente più profondi dell’AI-assisted development: il carico cognitivo sui team, il decadimento delle competenze ingegneristiche e le implicazioni epistemiche della delega progressiva del ragionamento ai sistemi AI.

Fonti e riferimenti

1. Forbes — “Automation Bias: What It Is And How To Overcome It“ (mar.2024)
2. Lightrun — “State of AI-Powered Engineering 2026“ (apr.2026)
3. Business Insider — “Amazon Tightens Code Guardrails After Outages Rock Retail Business“ (mar.2026)
4. Cloud Security Alliance — “Vibe Coding’s Security Debt: The AI-Generated CVE Surge“ (apr.2026)
5. Grafa — “Moonwell loses $1.78M in oracle mishap“ (feb.2026)
6. Moonwell Forum — “MIP-X43 cbETH Oracle Incident Summary – Announcements & Updates“ (feb.2026)
7. Pashov — “Claude Opus 4.6 wrote vulnerable code“ (feb.2026)
8. Forbes — “Vibe coding will break your company“ (apr.2026)
9. IBM — “Top 5 tips for measuring the productivity of gen AI in an enterprise“
10. Uplevel — “Does GenAI Improve Software Developer Productivity?“ (set.2024)
11. METR — “Measuring Early-2025 AI on Experienced OSS Developers Productivity“ (lug.2025)
12. METR — “Wider adoption of AI has made it more difficult to measure task-level productivity“ (feb.2026)