Manutenzione del codice scritto da un agente: contano i test che non passano più

Il codice scritto da un agente rende più difficile la manutenzione successiva? Uno studio uscito il 10 ottobre 2026 risponde con una distinzione utile a chi guida un team: il peso non sta in una difficoltà intrinseca del codice dell'agente, sta nei test già rotti che la lavorazione successiva eredita. Per una software house è una notizia utile, perché i test rotti si contano e si bloccano prima del merge. Qui riporto cosa hanno misurato gli autori, cosa lasciano fuori e quale controllo introdurre lunedì mattina.

Cosa hanno misurato Pan e colleghi

Lo studio si intitola "Do Modifications Made by Coding Agents Make Subsequent Software Maintenance Harder?". Lo firmano Ruwei Pan, John Zhang, Linhao Wu, Yakun Zhang, Hongyu Zhang e Lu Zhang ed è un preprint su arXiv del 10 ottobre 2026. La pagina non dichiara finanziamenti né conflitti di interesse specifici del lavoro.

Il metodo è un confronto a coppie. Gli autori costruiscono SWE-Maintain: 100 episodi di tre modifiche ciascuno, presi dalla storia di 50 repository Python reali, con test certificati e nascosti all'agente. Ogni modifica successiva viene eseguita due volte con lo stesso agente e gli stessi test. La prima volta parte dalle modifiche scritte dagli sviluppatori, la seconda da quelle che l'agente aveva fatto nei passaggi precedenti.

I sistemi provati sono cinque (Mini-SWE-Agent, Agentless, SE-Agent, OpenHands e Claude Code), con due modelli, GPT-5.6-Luna e DeepSeek-V4-Flash-0731, per 1.996 coppie di modifiche successive.

Dove si perde la lavorazione successiva

Partendo dal codice dell'agente, la modifica successiva riesce in media 5,6 punti percentuali meno spesso, con un intervallo di confidenza al 95% da meno 7,2 a meno 4,1. Se per considerarla riuscita si chiede anche che passino tutti i test delle modifiche precedenti, il divario sale a 14,0 punti: la quota scende dal 33,6% al 19,6%.

Il peso sta nei test già rotti

La differenza viene quasi tutta da un punto. In 1.349 casi su 1.996, cioè circa due terzi, il codice di partenza dell'agente falliva già test precedenti. Da quella situazione solo l'1,9% delle modifiche successive arriva alla fine con tutti i test accumulati verdi, contro il 23,7% partendo dalla storia degli sviluppatori.

Quando invece il codice ereditato supera i test precedenti, lo svantaggio sparisce: la differenza è più 2,7 punti, con intervallo da meno 0,5 a più 6,1. Gli autori ne concludono che il costo sta nei test ereditati rotti e non in un difetto misurabile del codice che conserva il comportamento già testato.

Un esempio dal paper

Uno dei casi descritti dagli autori riguarda Claude Code. Lo sviluppatore aveva aggiunto un alias a livello di modulo per la compatibilità con Python 3. L'agente aveva corretto soltanto i punti di chiamata esercitati dal compito, e la modifica passava i test del momento. Quando il codice successivo ha usato l'alias in tutto il modulo, 8 test su 10 sono falliti con un errore di nome non definito.

Cosa lo studio non dimostra

Sei cautele impediscono di trasformare questi numeri in una regola per il vostro team. I repository sono 50, tutti Python e di dimensioni piccole, con una mediana di 1.744 righe di codice Python. Gli episodi hanno tre modifiche e ogni modifica è stata eseguita una sola volta per condizione.

I test precedenti erano nascosti all'agente: lo studio non dice cosa accade quando l'agente li può eseguire, ed è proprio ciò che gli autori raccomandano di fare. Nessuna persona rivede il lavoro, quindi manca la parte di revisione che in un team reale intercetta una parte dei problemi.

"Nessuno svantaggio" è una lettura prudente, non una prova: l'intervallo da meno 0,5 a più 6,1 include lo zero e per quel gruppo di casi gli autori riportano p uguale a 0,09. Infine non vengono provati altri linguaggi, repository grandi, né Cursor o GitHub Copilot.

La tesi che segue è mia e non è dello studio: la lavorazione successiva dovrebbe partire da una base di cui si conoscono i test rossi.

Cosa cambiare lunedì mattina

Il primo cambiamento è nel contratto di lavorazione. Come ho scritto nell'articolo sul contratto di lavorazione per un agente, il primo campo è lo stato di partenza, cioè il commit da cui l'agente parte. Aggiungete a quel campo l'elenco dei test che su quel commit sono già rossi. Una lavorazione che parte con una lista vuota dichiara una base verde; se la lista non è vuota, la prima lavorazione è sistemare quei test, non aggiungere funzioni.

Il secondo è un controllo prima dell'accettazione. Con pytest, per esempio, basta confrontare i test falliti sulla base e sul ramo dell'agente:

git checkout "$BASE" && pytest -q -rf | grep '^FAILED' | sed 's/ - .*//' | sort > base.txt
git checkout "$HEAD" && pytest -q -rf | grep '^FAILED' | sed 's/ - .*//' | sort > head.txt
comm -13 base.txt head.txt

Ogni riga stampata da comm -13 è un test rotto dalla modifica. Se l'elenco non è vuoto, la pull request non viene accettata. Così l'agente non può lasciare ai compiti successivi quello che i test già dicevano di non rompere.

Il terzo è una misura. Contate, sulle ultime 20 lavorazioni con un agente, quante sono partite da un commit con almeno un test rosso. È un numero che scrivo io come proposta di controllo: non esiste una soglia universale. Come ho spiegato parlando di chi scrive il test che giudica l'agente e delle metriche di delivery dopo il merge, le rilavorazioni vanno guardate dopo il merge, non solo il volume di pull request aperte.

Dove l'ho applicato io

Le routine che scrivono gli articoli di questa serie seguono lo stesso principio. Una procedura versionata nel repository stabilisce che prima di ogni pubblicazione deve girare un controllo automatico, e che se fallisce l'articolo non esce.

DETENT, il metodo che sto costruendo per software house e team di sviluppo, dichiara sul sito la stessa impostazione: l'unità di lavoro è un contratto di lavorazione che comincia con l'SHA di partenza, e chi esegue non scrive le prove che lo giudicano.

Il quadro più ampio, la industrializzazione della produzione di software con gli agenti AI, si riduce qui a una domanda da fare a ogni lavorazione: da quale base parte, e quali test restano verdi quando finisce?