SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

Il paper presenta SWE-CI, il primo benchmark a livello di repository basato sul ciclo di integrazione continua, progettato per valutare la capacità degli agenti LLM di mantenere la qualità del codice durante l'evoluzione a lungo termine, superando i limiti degli approcci statici e monolitici.

L'essenziale

Immagina di assumere un architetto e un muratore digitali (un'intelligenza artificiale) per ristrutturare una casa.

Fino a poco tempo fa, per testare questi "robot", gli scienziati facevano loro una domanda semplice: "Ecco un muro rotto, riparalo ora". Se il robot riparava il muro e la casa non crollava, prendeva un bel voto. Questo è come funzionavano i vecchi test per l'IA: una soluzione singola e immediata.

Ma la vita reale è diversa. Costruire e mantenere un software (o una casa) non è un lavoro di un giorno. È un processo che dura anni, con nuove stanze da aggiungere, finestre da spostare e tubature da cambiare. Se il tuo muratore digitale ripara il muro di oggi in modo "frettoloso" (usando nastro adesivo invece che cemento), domani, quando dovrai aggiungere una finestra, il muro crollerà di nuovo.

SWE-CI è il nuovo, rivoluzionario test che cambia le regole del gioco. Ecco di cosa si tratta, spiegato in modo semplice:

1. Il Problema: La "Fotografia" vs. Il "Film"

I vecchi test erano come una fotografia: ti mostravano un momento fermo e chiedevano: "È tutto a posto?".
SWE-CI è invece un film in movimento. Non chiede solo di riparare un errore, ma di mantenere la casa in piedi per mesi.
Immagina di dare al tuo muratore digitale una casa che deve evolvere per 233 giorni (circa 8 mesi), con 71 piccoli lavori da fare uno dopo l'altro. Il test non guarda solo se la prima riparazione funziona, ma se la casa rimane solida dopo il 10°, il 50° e il 71° lavoro.

2. La Soluzione: Il Duo "Architetto" e "Programmatore"

Per gestire questa sfida, SWE-CI non usa un singolo robot, ma una squadra di due:

• L'Architetto (Il Capo): Guarda i problemi, capisce cosa manca e scrive un piano di lavoro. Non dice come costruire, ma cosa deve succedere.
• Il Programmatore (Il Muratore): Prende il piano e esegue i lavori concreti sul codice.

Loro lavorano in un ciclo continuo (come un team reale): L'Architetto dice "Dobbiamo aggiungere una porta", il Programmatore la costruisce, poi si controlla se tutto funziona, e si riparte. Se il Programmatore fa un lavoro di bassa qualità, l'Architetto si troverà a dover gestire un disastro nei lavori successivi.

3. La Misura del Successo: L'"EvoScore" (Punteggio di Evoluzione)

Come si valuta chi vince? Non basta dire "Ha riparato il muro".
SWE-CI usa un punteggio speciale chiamato EvoScore.

• Se il robot fa un lavoro veloce ma "sporco" (lascia disordine), all'inizio sembra bravo, ma dopo pochi lavori il punteggio crolla perché il codice diventa ingestibile.
• Se il robot fa un lavoro più lento ma pulito e organizzato, il punteggio sale man mano che i lavori successivi diventano più facili da fare.

È come se valutassi un muratore non per quanto velocemente ha posato il primo mattone, ma per quanto è facile per il suo collega posare il mattone successivo senza inciampare nei suoi errori.

4. Cosa Hanno Scoperto?

Gli autori hanno fatto fare questo test a 18 diversi modelli di intelligenza artificiale (come Claude, GPT, ecc.) usando 100 progetti reali presi da GitHub. Ecco le scoperte principali:

• Stanno migliorando: I modelli più recenti sono molto più bravi di quelli vecchi a mantenere il codice nel tempo.
• Non sono ancora perfetti: Anche i migliori robot tendono a fare errori a catena. Spesso, quando correggono un problema, ne creano due nuovi senza accorgersene (questo si chiama "regressione"). È come se riparassero una perdita nel tetto, ma poi, senza volerlo, buchino il muro del salotto.
• Stili diversi: Alcuni modelli sono "avventati" (vogliono risolvere tutto subito, anche se poi crea problemi), altri sono più "cauti" e pensano al lungo termine.

In Sintesi

SWE-CI ci dice che l'Intelligenza Artificiale sta diventando bravissima a scrivere codice per risolvere problemi singoli, ma fatica ancora a essere un vero "collega" a lungo termine che mantiene un progetto sano, ordinato e privo di errori per mesi.

È un passo fondamentale: ci stiamo spostando dal chiedere all'IA "Sai scrivere una riga di codice?" al chiedergli "Sai gestire un intero cantiere per un anno senza far crollare il tetto?".

Sommario tecnico

Ecco una sintesi tecnica dettagliata del paper "SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration", presentata in italiano.

1. Il Problema: Limiti degli Approcci Attuali

Il campo dell'ingegneria del software automatizzata ha fatto grandi passi avanti grazie agli agenti basati su Large Language Models (LLM), come dimostrato da benchmark esistenti (es. SWE-bench, HumanEval). Tuttavia, questi benchmark condividono un limite fondamentale: adottano un paradigma di valutazione "snapshot" (istantanea).

• Natura statica: Gli agenti ricevono un requisito completo e devono produrre una soluzione "one-shot" (in un solo colpo).
• Cecità sulla manutenibilità: In questo scenario, un agente che applica una correzione fragile e "hard-coded" ottiene lo stesso punteggio di uno che scrive codice estensibile e pulito, purché entrambi passino i test iniziali.
• Realtà del software: Lo sviluppo software reale è un processo dinamico di lungo termine, caratterizzato da iterazioni continue, cambiamenti dei requisiti e manutenzione. La qualità del software tende a degradare con la manutenzione (Legge di Lehman), e le decisioni architetturali iniziali influenzano la facilità delle modifiche future.
• Gap: Manca un benchmark in grado di valutare la capacità di un agente di mantenere la qualità del codice durante un'evoluzione a lungo termine, dove le conseguenze delle decisioni passate si accumulano.

2. Metodologia: SWE-CI e il Paradigma di Valutazione Evolutiva

Per colmare questo gap, gli autori propongono SWE-CI, il primo benchmark a livello di repository basato sul ciclo di Continuous Integration (CI).

A. Formalizzazione del Task

A differenza dei benchmark tradizionali che mappano un codice base ($c_0$) e uno "golden" ($c^*$) in un singolo requisito statico, SWE-CI utilizza un paradigma basato sull'evoluzione:

1. Si parte da un commit base ($c_0$) e si mira a un commit target ($c^*$) in un repository reale.
2. Il processo è iterativo: l'agente genera requisiti basati sul gap funzionale corrente ($r_i = \text{require}(c_i, c^*)$), modifica il codice ($c_{i+1} = \text{code}(c_i, r_i)$) e ripete il ciclo.
3. Questo loop garantisce che le decisioni prese nelle iterazioni iniziali influenzino direttamente la difficoltà delle iterazioni successive.

B. Curatela dei Dati (Data Curation)

Il dataset è stato costruito attraverso un processo rigoroso su repository GitHub Python:

• Filtraggio: Selezione di repository attivi da almeno 3 anni, con >500 stelle, licenze permissive e suite di test.
• Estrazione: Identificazione di sequenze di commit massimali dove le dipendenze non cambiano.
• Costruzione Ambiente: Creazione automatica di ambienti Docker con meccanismi di "self-repair" per garantire l'esecuzione dei test.
• Filtraggio Finale: Selezione di 100 task da 68 repository distinti. Ogni task copre in media 233 giorni di storia e 71 commit consecutivi, con almeno 500 righe di codice modificate.

C. Protocollo di Valutazione Dual-Agent

Per simulare un team di sviluppo reale, SWE-CI utilizza due agenti collaborativi in un ciclo CI:

1. Architect Agent: Analizza i test falliti, individua le cause radice e genera un documento di requisiti ad alto livello (massimo 5 requisiti urgenti per iterazione).
2. Programmer Agent: Interpreta i requisiti, pianifica l'implementazione e scrive il codice.
   Questo approccio separa la definizione del "cosa" fare dall'implementazione del "come", simulando il flusso di lavoro reale.

D. Metriche di Valutazione

• Normalized Change ($a(c)$): Una metrica granulare che misura il progresso rispetto alla linea di base, penalizzando le regressioni (test che passavano prima e falliscono dopo).
• EvoScore (Evolution Score): La metrica principale. È una media pesata dei punteggi di normalizzazione su tutte le iterazioni:
  $$e = \frac{\sum \gamma^i a(c_i)}{\sum \gamma^i}$$
  Dove $\gamma \ge 1$. Un $\gamma > 1$ premia la stabilità a lungo termine: un agente che sacrifica la velocità immediata per un design più pulito (che facilita le modifiche future) ottiene un punteggio più alto.

3. Risultati Sperimentali

Gli esperimenti hanno coinvolto 18 modelli di 8 fornitori diversi, consumando oltre 10 miliardi di token.

• Progresso Accelerato: Le capacità di manutenzione del codice stanno migliorando rapidamente. I modelli rilasciati dopo il 2026 mostrano guadagni significativi rispetto ai predecessori. La serie Claude Opus e GLM-5 si distinguono come leader.
• Differenze tra Fornitori: Esistono preferenze strategiche diverse tra i fornitori.
  • Modelli come MiniMax, DeepSeek e GPT tendono a privilegiare guadagni a lungo termine (alta manutenibilità).
  • Modelli come Kimi e GLM sembrano orientati verso ritorni a breve termine.
  • Qwen, Doubao e Claude mostrano stabilità attraverso diverse impostazioni.
• Il Problema delle Regressioni: Nonostante i progressi, gli LLM attuali faticano a evitare regressioni durante la manutenzione a lungo termine. La maggior parte dei modelli ha un tasso di "zero-regression" (nessun test rotto durante tutto il processo) inferiore al 25%. Solo due modelli della serie Claude Opus superano il 50%. Questo indica che, sebbene bravi nelle correzioni statiche, gli agenti non sono ancora affidabili nello sviluppo software autonomo e iterativo.

4. Contributi Chiave

1. SWE-CI Benchmark: Il primo benchmark repository-level basato sul ciclo di Continuous Integration, progettato specificamente per valutare la manutenibilità a lungo termine invece della sola correttezza funzionale istantanea.
2. Nuovo Paradigma di Valutazione: Spostamento dalla valutazione "snapshot" a quella "evolutiva", dove la qualità è misurata attraverso la capacità di gestire modifiche successive senza accumulare debito tecnico.
3. Metrica EvoScore: Introduzione di una metrica che pesa la stabilità futura, permettendo di distinguere tra soluzioni fragili e soluzioni robuste.
4. Analisi Empirica: Fornisce una panoramica dettagliata delle capacità attuali degli agenti LLM, evidenziando che la gestione delle regressioni è il collo di bottiglia principale per l'automazione completa del ciclo di vita del software.

5. Significato e Impatto

SWE-CI rappresenta un cambio di paradigma fondamentale nella ricerca sull'IA per l'ingegneria del software. Dimostra che la semplice capacità di "passare i test" non è sufficiente per definire un agente software maturo.

• Diagnostica: Il benchmark rivela che gli agenti attuali accumulano rapidamente debito tecnico quando costretti a iterazioni multiple.
• Direzione Futura: Indirizza la ricerca verso lo sviluppo di modelli capaci di pianificazione architetturale a lungo termine e di gestione della stabilità del codice, essenziali per l'adozione reale degli agenti AI in ambienti di produzione complessi.
• Rilevanza Industriale: Poiché la manutenzione rappresenta il 60-80% dei costi del ciclo di vita del software, strumenti in grado di valutare e migliorare questa specifica capacità hanno un potenziale impatto economico e qualitativo enorme.