I sistemi di intelligenza artificiale imparano a scrivere i propri test prima di fidarsi delle correzioni

Il redattore di test ha un compito arduo: scrivere una verifica che fallisca sul codice difettoso e funzioni dopo la correzione giusta. Non basta. La verifica deve anche distinguere le correzioni valide da quelle errate. Se fallisce solo per il motivo sbagliato, può indirizzare la riparazione in modo fuorviante.

Il modello che genera i test ha un compito preciso: scrivere una verifica che fallisca sul codice difettoso e passi dopo la correzione corretta. Non basta. La verifica deve anche distinguere le patch valide da quelle errate. Se fallisce per il motivo sbagliato, rischia di indirizzare la riparazione in modo fuorviante.

Le regole di addestramento sono rigide. Un invio senza test validi riceve una penalità di -0,2. Un pacchetto valido che non fallisca sulla base difettosa e non passi dopo la correzione di riferimento ottiene 0. Superata questa soglia iniziale, conta la qualità: se la verifica separa le patch corrette da quelle errate con un’accuratezza bilanciata inferiore all’80%, guadagna 0,2. Tra l’80% e il 100% escluso, ne guadagna 0,5. La separazione perfetta vale 1,0. In pratica, un test che si limita a inciampare sul bug non viene premiato: deve comportarsi come una sonda affidabile.

Il modello non può consultare la cronologia nascosta delle soluzioni. Può ispezionare solo l’albero di lavoro corrente e i materiali pubblici, usando comandi come git status, add -AN o un diff semplice. Non gli sono consentiti comandi che rivelino commit o rami precedenti. Il comportamento atteso deve derivare esclusivamente dal testo del problema, dalla documentazione pubblica, dal codice difettoso e dai test esistenti.

Prima di scrivere le asserzioni, il modello deve identificare il comportamento pubblico minimo a rischio. Deve anche considerare una lettura alternativa plausibile del problema prima di scartarla. Un fallimento netto sul codice difettoso è necessario ma non sufficiente: dimostra solo che la verifica non concorda con il bug, non che sia allineata alla correzione prevista.

Il test dovrebbe puntare a qualcosa di visibile per gli utenti: una chiamata API, un risultato da riga di comando, un output renderizzato o un passaggio di migrazione. Va evitato lo stato interno privato solo perché è facile da ispezionare. Se il problema riguarda il rendering, la verifica deve guardare al risultato renderizzato, non a una flag interna.

Messaggi esatti, conteggi e ordinamenti possono essere fissati solo se il problema, i documenti o un test pubblico esistente li specificano. Altrimenti, il modello usa la proprietà osservabile più debole che il problema garantisce e che il codice difettoso viola.

Il pacchetto deve formare un unico gruppo di regressione coerente per il problema. Può aggiungere diversi test e aggiornare i fixture, ma non può inserire coperture non correlate. Il comando di esecuzione deve indicare ogni nodo di test dichiarato. Un comando a livello di file o suite viene rifiutato anche se fallisce sulla base difettosa.

Il modello invia anche un breve contratto comportamentale. Indica il punto d’ingresso pubblico, l’innesco che espone il bug e l’output corretto minimo su cui si fa l’asserzione. Documenta le prove a supporto, le ipotesi alternative scartate, i letterali tentanti lasciati non fissati e ogni nodo di test esatto eseguito.

L’invio è meccanico. Poi crea un patch non vuoto contenente solo le modifiche previste per i test di regressione. Quel patch viene inviato con una singola chiamata finale bash. Il testo da solo non conta.

L’agente di riparazione si affida a un unico test fisso per il feedback locale

L’agente di riparazione parte con un tentativo completo per correggere il bug: ha a disposizione fino a 200 turni prima che sia consentito qualsiasi feedback. A quel punto ha prodotto una patch completa, ma questa non viene ancora valutata dalla suite di test ufficiale. Viene invece verificata rispetto a un singolo controllo congelato.

Un controllo congelato è un test automatizzato unico, mantenuto invariato durante la riparazione. L’agente non ne vede né il codice sorgente né l’origine: riceve solo feedback di esecuzione limitati, ovvero se il codice patchato ha fatto passare quel controllo fisso. Questo segnale locale è economico e indica se la patch corrente gestisce il comportamento mirato, ma non decide il successo finale.

Se il controllo congelato fallisce, l’agente può rivedere la propria proposta: dispone di fino a cinque round di revisione, ciascuno dei quali consente 40 turni. L’agente modifica sempre la stessa patch cumulativa. Prima di ogni verifica, il sistema ripristina il codice originale con il bug e applica nuovamente l’intero candidato, evitando così catene disordinate di piccole modifiche. Un errore nel sorgente del codice patchato conta come feedback utile di fallimento, mentre un crash dell’ambiente non lo è.

La ricompensa durante l’addestramento segue questa ripartizione: una patch mancante o invalida ottiene zero. Una patch utilizzabile che fa ancora fallire il controllo congelato guadagna un punteggio basso. Se passa il controllo congelato ma fallisce la valutazione ufficiale, guadagna di più. Se entrambi passano dopo la revisione, l’agente riceve credito pieno. Se entrambi passano già al Round 0, ottiene un bonus aggiuntivo. Questo insegna all’agente a usare il controllo locale come una bussola, non come la destinazione.

In un’impostazione di valutazione, la revisione guidata dal feedback ha portato il tasso di risoluzione dal 68,3% al 72,6%. Tra le 120 traiettorie di riparazione che sono entrate in fase di revisione, il costo mediano è stato di soli 11 turni aggiuntivi, con una media di 13. Quasi la metà si è conclusa entro dieci turni. Nelle esecuzioni con test generati, un pacchetto di test qualificato viene riutilizzato in tre esecuzioni di riparazione e tutte le loro revisioni, poiché la generazione dei test avviene una volta per ogni problema e sorgente. Il verdetto finale proviene ancora da un valutatore ufficiale nuovo. I risultati del gate locale vengono registrati separatamente, guidano la revisione ma non sostituiscono la verifica completa.

Quanto rende di più la coppia: test addestrati o presi in prestito

I test addestrati migliorano le prestazioni della coppia molto più di quelli presi in prestito. Il confronto più chiaro parte da un agente di riparazione non addestrato su questo compito: senza feedback dai test, risolve il 61,2% dei problemi. Se a fornire i controlli è un generatore di test anch’esso non addestrato, le prestazioni scendono al 57,3%, con un calo di 3,9 punti. I test generati sono troppo rumorosi e finiscono per fuorviare il processo di riparazione.

Una fonte esterna più forte aiuta di più. I test di GPT-5.6-sol portano lo stesso agente base al 65,3%, un guadagno di 4,1 punti rispetto all’assenza di feedback. I controlli Oracle fail-to-pass spingono il risultato oltre, fino al 69,4%, con un aumento di 8,2 punti. Questi test presi in prestito sono utili perché puntano a fallimenti reali, ma non eguagliano ancora la migliore configurazione addestrata.

Il salto più grande arriva quando entrambi i ruoli sono addestrati. Un agente di riparazione addestrato sul feedback raggiunge il 73,5% con i test GPT-5.6-sol e il 77,6% con i controlli Oracle. Rispetto alla sua baseline senza test addestrati (64,6%), il risultato Oracle rappresenta un guadagno di 13 punti. Quel divario mostra che la qualità dei test conta quanto l’abilità nella riparazione.

Il generatore di test addestrato migliora anche l’agente di riparazione più debole. Sostituire i test del modello base con quelli addestrati tramite reinforcement learning porta la risoluzione dal 57,3 al 64,1%, un aumento di 6,8 punti. Per l’agente di riparazione addestrato, la stessa sostituzione lo sposta dal 64,6 al 72,6%, con un guadagno di 8,0 punti. I due miglioramenti non sono magia indipendente: indicano nella stessa direzione, ovvero che controlli migliori rendono la riparazione più affidabile.

La coppia completamente addestrata raggiunge il 72,6% su SWE-bench Verified senza fare affidamento sul feedback GPT-5.6 o Oracle durante la valutazione. Sono 11,4 punti sopra l’agente base di riparazione originale senza feedback, che si attesta al 61,2%. Se alla coppia addestrata viene aggiunto il feedback Oracle, la risoluzione sale al 77,6%. Il divario residuo di cinque punti suggerisce che una migliore qualità dei test e una copertura più ampia potrebbero ancora garantire ulteriore progresso.

Due casi concreti: quando il test generato corregge la rotta della riparazione

Due casi concreti illustrano come un test generato possa correggere la rotta della riparazione, evitando soluzioni errate. Nel primo caso, Django doveva implementare una procedura di fallback per i database privi di supporto nativo all’operatore XOR. L’XOR è un operatore logico che verifica se un numero dispari di ingressi risulta vero. Il fallback codificava però in modo errato la parità, intesa come risultato pari o dispari atteso dall’operazione. Un test generato copriva tre casi di parità e falliva nettamente sul codice difettoso: un esito utile, poiché rispecchiava esattamente il comportamento descritto nella segnalazione. La prima correzione gestiva correttamente la parità, ma riutilizzava un connettore XOR durante la ricostruzione del nodo di fallback, generando un RecursionError all’interno del test congelato. Dopo un giro di feedback e 23 turni aggiuntivi, l’agente ha sostituito quel connettore con AND. La patch finale ha superato sia il test generato sia una nuova verifica ufficiale: il test non si è limitato a segnalare l’errore, ma ha indicato direttamente il sottosistema difettoso.

Il secondo caso riguarda Sphinx e la gestione dei parametri tipizzati. Sphinx interpretava la virgola all’interno di dict(str, str) come un separatore, producendo output renderizzato malformato. Un test generato, basato su un tipo dict tra parentesi, falliva sul codice difettoso e superava la verifica dopo la correzione di riferimento. La prima riparazione interveniva però su un parser Napoleon non correlato al problema. Il test congelato ha evidenziato il reale disallineamento nel rendering, reindirizzando l’agente verso il parser dei campi tipizzati in docfields.py. Dopo due giri e 75 turni aggiuntivi, la patch finale manteneva l’intero tipo prima del nome dell’ultimo parametro, senza più spezzare alla virgola. Anche un caso di tipo tra parentesi quadre funzionava attraverso lo stesso percorso di analisi. La patch per Sphinx includeva anche una modifica precedente non correlata: corretta, ma non minima.

I bassi conteggi dei turni sono significativi: dimostrano che il test forniva un indizio preciso. L’agente non ha dovuto cercare in tutto il codicebase, ma poteva verificare un singolo percorso sospetto, correggerlo ed eseguire di nuovo lo stesso check congelato. Il test generato guidava la riparazione, mentre un valutatore ufficiale separato emetteva il verdetto finale.

Perché tenere separati i due ruoli è la soluzione più sicura

Un modello unico apparirebbe più semplice: un solo checkpoint potrebbe scrivere test e correggere codice, trasferendo conoscenze tra le due attività. Ma questa comodità nasconde un rischio concreto. I due ruoli non apprendono dagli stessi segnali. Il redattore di test viene premiato per creare verifiche che falliscano sul codice difettoso, passino dopo la correzione giusta e distinguano i patch validi da quelli errati. La ricompensa massima spetta solo quando questa separazione è netta. L’agente di riparazione, invece, riceve un premio soltanto se la sua modifica al sorgente supera un controllo finale indipendente. Sono obiettivi che tirano in direzioni opposte. Se un unico modello interpreta entrambi i ruoli, rischia di ottimizzare il ciclo anziché risolvere il bug: potrebbe scrivere test facili da soddisfare per sé stesso o correggere il codice adattandolo alla verifica, invece di ripristinare il comportamento pubblico descritto nella segnalazione. Questa coordinazione sembra efficiente all’inizio, ma in pratica può peggiorare le prestazioni della coppia.

Mantenere i ruoli separati impedisce che la verifica diventi un bersaglio. Il pacchetto di test viene generato una sola volta e poi mantenuto fisso durante la riparazione. L’agente vede solo feedback di esecuzione limitati, non il codice sorgente né l’identità del test. Non può quindi riscriverlo per far apparire migliore la propria patch. Questo è cruciale perché i test deboli possono fuorviare la correzione: una verifica che fallisce per il motivo sbagliato può indirizzare la riparazione su un percorso errato. L’addestramento separato facilita l’integrità di ciascun ruolo: da un lato si devono produrre verifiche affidabili, dall’altro risolvere il problema rispettando quelle verifiche. Il risultato non è una garanzia universale, ma un design più sicuro perché l’indipendenza limita le possibilità che il sistema possa ingannare se stesso.

Il risultato più convincente non nasce da un singolo trucco ingegnoso, ma da un ciclo. Il modello che scrive i test produce una verifica piccola e rivolta all’esterno. L’agente di riparazione tenta di soddisfarla. Se la verifica fallisce, l’agente riceve un segnale breve e rivede il codice. Questo meccanismo ha portato il tasso di successo dal 61,2% al 72,6%, con entrambi i modelli addestrati e senza l’uso di oracoli esterni durante la valutazione.

Il guadagno non è magia: deriva da un feedback economico. Un pacchetto di test generato può essere riutilizzato in diversi tentativi di riparazione. Le revisioni hanno aggiunto in media solo circa tredici turni dell’agente, pur consentendo fino a cinque round. Questo aspetto è cruciale perché le correzioni reali del software richiedono tempo e risorse di calcolo: un controllo locale dal costo contenuto guida molte piccole modifiche senza consumare un budget elevato.

Resta comunque un limite superiore. Con un feedback oracolare più forte, il successo raggiunge il 77,6%. Il divario residuo punta alla qualità dei test e alla loro copertura: verifiche migliori potrebbero esporre di più del comportamento reale attorno a un bug, mentre controlli indipendenti aggiuntivi ridurrebbero la falsa sicurezza. Un modello condiviso, capace sia di scrivere test sia di riparare codice, sarebbe più semplice da implementare e permetterebbe alle conoscenze di fluire tra i due ruoli.

L’ostacolo principale è la fiducia. Test deboli o disallineati possono deviare la riparazione dal problema reale. Il modello che scrive i test non deve inseguire dettagli interni facili, stato privato o sintomi del bug. Deve puntare al comportamento osservabile che il problema promette davvero. L’addestramento congiunto rende questo compito più difficile perché i due ruoli hanno ricompense e azioni diverse: se imparano a compiacersi a vicenda invece di risolvere il problema, il ciclo diventa auto- giustificante.

L’opportunità resta ampia. Un sistema può generare un controllo utile, eseguirlo localmente, correggere il codice e sottometterlo per la verifica ufficiale. Il prossimo passo potrebbe riguardare meno la capacità di programmazione pura e più l’autotest disciplinato: una macchina può imparare a dubitare del proprio test?

Il risultato migliore non nasce da un singolo trucco ingegnoso, ma da un ciclo continuo. Il modello che scrive i test produce una verifica piccola e rivolta al comportamento pubblico. L’agente di riparazione tenta di soddisfarla. Se la verifica fallisce, l’agente riceve un segnale breve e rivede il codice. Questo meccanismo ha portato il tasso di successo dal 61,2% al 72,6%, con entrambi i modelli addestrati e senza l’uso di oracoli esterni durante la valutazione.

Il guadagno non è magia: deriva da un feedback economico. Un pacchetto di test generato può essere riutilizzato in diversi tentativi di riparazione. La revisione ha aggiunto in media solo circa tredici turni dell’agente, con un massimo di cinque round consentiti dal sistema. Questo aspetto è cruciale perché le correzioni reali del software richiedono tempo e risorse di calcolo: una verifica locale a basso costo può guidare molte piccole modifiche senza consumare un budget elevato.

Esiste comunque un limite superiore. Con un feedback oracolare più forte, il successo ha raggiunto il 77,6%. Il divario residuo indica che la qualità dei test e la loro copertura restano fattori determinanti: test migliori potrebbero esporre di più del comportamento reale attorno a un bug, mentre controlli indipendenti aggiuntivi potrebbero ridurre la falsa sicurezza. Un modello unico in grado sia di scrivere test sia di riparare codice sarebbe più semplice da implementare e permetterebbe una maggiore condivisione delle conoscenze tra i due ruoli.

L’ostacolo principale resta la fiducia. Test deboli o non allineati possono deviare la riparazione dal problema reale. Il modello che scrive i test deve evitare di inseguire dettagli interni facili, stati privati o semplici sintomi del bug. Deve puntare al comportamento osservabile che il problema promette effettivamente. L’addestramento congiunto rende questo compito più difficile perché i due ruoli hanno ricompense e azioni diverse: se imparano a compiacersi a vicenda invece di risolvere il problema, il ciclo diventa auto- giustificante.

L’opportunità è ancora ampia. Un sistema può generare una verifica utile, eseguirla localmente, rivedere il codice e sottometterlo per la verifica ufficiale. Il prossimo passo potrebbe dipendere meno dalla pura capacità di programmazione e più da un autotest disciplinato. Una macchina può imparare a dubitare dei propri test?