Il 75% degli AI Agent Rompe Codice nel Tempo: Ma di Chi è la Colpa?

La stragrande maggioranza dei modelli AI rompe codice che prima funzionava. Non al primo commit — nel tempo, iterazione dopo iterazione, senza che nessuno se ne accorga.

Il dato arriva da SWE-CI, uno studio di Alibaba pubblicato a marzo 2026. 18 modelli da 8 provider, 100 task su 68 repository Python reali, oltre 10 miliardi di token consumati. Il risultato: la maggior parte dei modelli introduce regressioni nella stragrande maggioranza dei task. Solo Claude Opus 4.6 se la cava bene, con un 76% di task completati senza rompere nulla. In mezzo, pochi modelli (Opus 4.5, Kimi, GLM, Qwen) superano di poco il 25%. Il resto è ben sotto.

Prima di chiudere la tab pensando "ecco, l'ennesimo articolo anti-AI": fermati. Perché il dato più interessante non è quel 75%. È come è stato prodotto. E cambia completamente la lettura.

SWE-CI non è SWE-bench

Quasi tutti i benchmark di coding AI funzionano allo stesso modo: prendi un bug, dai il codice all'agente, misuri se lo fixa. Un'istantanea. Un colpo singolo.

SWE-bench funziona esattamente così. Prendi un issue da un repository reale, fornisci il contesto, l'agente produce una patch, la confronti con quella umana. Fine. È utile — ci dice quanto è bravo un modello a risolvere un problema isolato.

Ma il software reale non funziona così. Nel software reale fixi un bug e ne introduci un altro. Refactori un modulo e rompi un test in un modulo diverso. Aggiorni una dipendenza e il build crolla.

SWE-CI misura esattamente questo: la capacità di un agente di lavorare su un codebase nel tempo, per iterazioni consecutive, senza degradare quello che già funziona.

Come? Ogni task copre in media 233 giorni e 71 commit consecutivi di storia reale di un repository. L'agente lavora in una pipeline dual-agent (architect + programmer) e affronta fino a 20 iterazioni di manutenzione. La CI gira dopo ogni iterazione. Se un test che passava inizia a fallire, è una regressione.

E qui sta il punto: nessun umano interviene tra un'iterazione e l'altra. Zero review. Zero feedback. L'agente è completamente autonomo.

Chi rompe cosa

I risultati parlano chiaro. La metrica chiave è lo zero-regression rate — la percentuale di task completati senza introdurre nessuna regressione nei test esistenti.

Modello	Zero-regression rate
Claude Opus 4.6	76%
Claude Opus 4.5	51%
Kimi-K2.5	37%
GLM, Qwen	~25-30%
GPT, Gemini, altri	< 25%

Claude Opus 4.6 è nettamente davanti. Opus 4.5 sta a metà. Alcuni modelli (Kimi, GLM, Qwen) si difendono intorno al 25-37%, ma la maggioranza — inclusi GPT e Gemini — resta sotto.

Ma attenzione: anche il 76% di Claude Opus 4.6 significa che un task su quattro introduce comunque regressioni. E parliamo del modello migliore in assoluto.

La differenza con SWE-bench è drammatica. Su SWE-bench, molti di questi modelli hanno performance comparabili. Su SWE-CI, il gap si spalanca. Risolvere un bug isolato è un conto. Mantenere un codebase integro per 20 iterazioni consecutive è tutt'altra storia.

Il vero risultato: l'autonomia senza supervisione degrada tutto

Ecco la parte che cambia la lettura di tutto lo studio.

Jean-François Lépine, CTO di Darkmira, ha commentato i risultati con una frase chirurgica:

"Queste cifre valutano gli agenti in modalità autonoma, senza review umana tra le iterazioni."

E questo è il punto. SWE-CI misura cosa succede quando lasci un agente completamente solo, senza supervisione, per 20 iterazioni consecutive. Nessun dev che guarda le diff. Nessun code review. Nessun "aspetta, questa modifica ha senso?".

In quelle condizioni, anche il miglior modello al mondo rompe qualcosa in un caso su quattro. Ed è logico: senza feedback umano, piccoli errori si accumulano. Una modifica introduce un'assunzione sbagliata. L'iterazione dopo, quell'assunzione diventa la base per un'altra decisione. Al terzo giro, il danno è fatto.

Ma — e qui sta il punto fondamentale — questo non succede solo con l'AI. Succede con qualsiasi codice non reviewato. Se un junior committasse 20 volte senza code review, il risultato sarebbe identico. Forse peggiore.

Il problema non è l'intelligenza dello strumento. È il processo.

L'analogia col junior: infinitamente veloce, zero giudizio

Un agente AI è un junior developer con due superpoteri e un difetto fatale.

Superpotere 1: velocità. Può produrre codice a un ritmo che nessun umano eguaglierà mai. Centinaia di righe al minuto, 24 ore al giorno, senza pause caffè.

Superpotere 2: breadth. Ha visto più codice di qualsiasi developer vivente. Conosce ogni pattern, ogni framework, ogni API.

Difetto fatale: non sa quando sta sbagliando. Non ha il campanello interno che dice "aspetta, questa modifica potrebbe rompere il modulo di pagamento". Non ha memoria di progetto. Non ha giudizio architetturale.

Birgitta Boeckeler di Thoughtworks ha centrato il problema: ai volumi che l'AI può produrre, se non controlli, il degrado è lento ma costante. Non è la singola riga sbagliata — è l'accumulo di mille piccole decisioni sub-ottimali che, una dopo l'altra, degradano il codebase. Code churn che raddoppia. Refactoring che crolla. Duplicazione che esplode.

E il junior infinitamente veloce, senza supervisione, produce questo accumulo a un ritmo che nessun team può gestire dopo il fatto. Prevenire costa meno che curare — e con l'AI questo è vero mille volte di più.

Il gap percettivo: crediamo che vada bene quando non va bene

Se il danno fosse visibile, il problema si risolverebbe da solo. Ma non lo è.

Lo studio di METR — un trial randomizzato controllato su 16 sviluppatori esperti — ha prodotto il dato più disturbante dell'anno: con l'AI, i developer erano il 19% più lenti. Ma erano convinti di essere il 20% più veloci. Un gap percettivo di 39 punti percentuali.

Tradotto: non solo l'AI non ci rende più veloci in certi contesti, ma ci convince che lo stia facendo. È il peggior tipo di bug — quello che non sai di avere.

Lo stesso pattern emerge nei dati di LinearB: il 67.3% delle PR generate con AI viene rifiutato in code review, contro il 15.6% di quelle manuali. Ma chi le genera è convinto che siano buone.

E da GitClear: il code churn — codice riscritto entro due settimane dal commit — è raddoppiato dall'arrivo dell'AI. Il refactoring è crollato dal 25% a sotto il 10%. Si scrive più codice, lo si butta via più spesso, e lo si ristruttura meno.

Il report DORA 2025 conferma il pattern su scala enterprise: l'adozione di AI ha una relazione negativa con la stabilità della delivery — ma solo nei team senza sistemi di controllo robusti. Nei team con CI solida, review obbligatorie e monitoring, l'effetto è neutro o positivo.

La variabile che cambia tutto non è l'AI. È il processo attorno all'AI.

I dati macro: il pattern si ripete ovunque

SWE-CI non è un caso isolato. I dati macro raccontano la stessa storia da angolazioni diverse.

Metrica	Dato	Fonte
Dev che usano AI	84%	Stack Overflow 2025
Dev che si fidano dell'AI	29%	Stack Overflow 2025
PR AI rifiutate vs manuali	67.3% vs 15.6%	LinearB
Issue in più nel codice AI	1.7x	CodeRabbit
Code churn (riscrittura entro 2 settimane)	Raddoppiato	GitClear
Refactoring (dal 25%)	< 10%	GitClear

L'84% usa AI. Solo il 29% si fida. E i dati oggettivi danno ragione a chi non si fida — ma il problema non è lo strumento in sé.

È che lo stiamo usando come se fosse un senior autonomo. E non lo è. È un junior con un turbo.

Cosa fare: cinque regole per non rompere tutto

Il messaggio di SWE-CI non è "smetti di usare agenti AI". È: "smetti di lasciarli soli".

1. Mai più di N iterazioni senza review

Il dato SWE-CI mostra che il degrado accelera con le iterazioni. Non lasciare che un agente accumuli 10 o 20 commit senza che un umano guardi le diff. Il numero esatto dipende dalla complessità, ma come regola base: ogni 2-3 iterazioni, revisiona.

2. La CI non è opzionale

SWE-CI usa la CI come oracolo: se un test che passava inizia a fallire, è una regressione. Se non hai test, non hai modo di sapere quando l'agente ha rotto qualcosa. E lo scoprirai in produzione.

3. Diff piccole, sempre

Più grande la modifica, più difficile individuare dove l'agente ha introdotto il problema. Decomponi il lavoro in chunk piccoli con output verificabile. È lo stesso principio delle PR atomiche — vale ancora di più con l'AI.

4. Non fidarti della percezione

Il gap di METR (39 punti tra percezione e realtà) è reale. Non "sentire" che il codice è buono. Verificalo. Guarda i test. Guarda la coverage. Guarda le metriche di qualità. La sensazione di produttività è il peggior indicatore di produttività reale.

5. Trattalo come un junior — perché lo è

Revieweresti il codice di un junior senza guardarlo? Faresti merge diretto di 20 commit consecutivi di un junior? No. Allora non farlo con l'agente. La velocità dell'AI non cambia il fatto che il suo codice ha bisogno di supervisione. Lo rende solo più urgente.

Il paradosso della velocità

C'è un paradosso sottile in tutto questo. L'AI è pericolosa proprio perché è veloce. Non perché è stupida.

Un junior lento fa pochi danni: produce poco codice, i problemi sono contenuti, il team li intercetta naturalmente. Un junior che produce a velocità macchina? Il danno scala linearmente con l'output. In assenza di review, ogni iterazione in più è un rischio in più.

La velocità è un moltiplicatore. Se il processo è buono, moltiplica il valore. Se il processo è assente, moltiplica il danno.

SWE-CI lo dimostra con i numeri: 20 iterazioni senza supervisione portano al degrado anche il miglior modello al mondo. Ma l'implicazione inversa è altrettanto vera: con supervisione adeguata, quello stesso modello è uno strumento straordinario.

Claude Opus 4.6 con il suo 76% di zero-regression non è perfetto. Ma un dev che revisiona quel 24% di casi problematici e li corregge al volo ha un sistema che produce codice di manutenzione a una velocità e una consistenza che nessun team umano può eguagliare.

Il problema non è mai stato l'AI. È sempre stato il processo. E la buona notizia è che il processo lo controlliamo noi.

Fonti