Riepilogo Tecnico: SWE-Together

Problematica

I benchmark attuali per gli agenti di codifica, come la famiglia SWE-Bench e Terminal-Bench, si basano prevalentemente su protocolli statici a turno singolo (single-turn). In queste configurazioni, un agente riceve una descrizione completa del compito in anticipo ed è valutato esclusivamente sulla correttezza della sua sottomissione finale del codice. Questo approccio non riflette la realtà dell'assistenza all'ingegneria del software, che è intrinsecamente interattiva e multi-turno. Nei flussi di lavoro reali, gli utenti rivelano incrementalmente l'intento, chiariscono richieste ambigue, raffinano i requisiti e forniscono feedback correttivi attraverso più turni.

I benchmark esistenti soffrono di due discrepanze primarie rispetto alla pratica:

1. Design del Task: Trattano i compiti come istruzioni fisse, ignorando che le informazioni rilevanti per il task sono spesso distribuite su più turni e che le richieste iniziali sono frequentemente incomplete.
2. Metriche di Valutazione: Si concentrano esclusivamente sul successo del task finale, fallendo nel catturare il costo dell'interazione. Due agenti possono ottenere lo stesso punteggio finale, ma uno potrebbe avere successo partendo da una richiesta generica mentre l'altro richiede specifiche dettagliate estese e ripetuti feedback correttivi.

Inoltre, costruire un benchmark che preservi un'interazione utente realistica garantendo al contempo la verificabilità è una sfida. I log delle conversazioni grezze spesso mancano di stati di repository riproducibili, obiettivi identificabili o risultati osservabili. Inoltre, semplicemente riprodurre i turni originali dell'utente per un nuovo agente è fallace perché i turni successivi dell'utente devono essere condizionati dalla traiettoria del nuovo agente per evitare il drift dell'interazione, pur dovendo rimanere ancorati all'intento dell'utente originale.

Metodologia

Per affrontare queste sfide, gli autori introducono SWE-Together, un benchmark composto da 109 task a livello di repository ricostruiti da reali sessioni utente-agente. La metodologia consiste in tre componenti principali:

1. Pipeline di Costruzione Sessione-Task

Gli autori curano 109 task da 11.260 sessioni registrate provenienti da quattro dataset a monte: DataClaw, Pi-staging, Hyperswitch e SWE-chat. La pipeline di costruzione prevede tre fasi:

• Filtraggio Deterministico di Eleggibilità: Le sessioni grezze vengono filtrate per trattenere quelle con interazioni multi-turno genuine, modifiche al codice concrete e contesti di repository recuperabili. Le sessioni in cui l'utente umano ha redatto la modifica finale sono escluse per garantire che l'agente abbia svolto un lavoro sostanziale.
• Screening di Viabilità: Un giudice LLM esamina i candidati per garantire che il lavoro di codifica possa essere ricostruito come un task autosufficiente ed eseguibile localmente. Le sessioni che dipendono da stati esterni (es. deployment di servizi live, credenziali private) vengono rifiutate.
• Costruzione del Task: Un orchestratore sandbox converte le sessioni viabili in pacchetti di benchmark eseguibili. Ciò include il ripristino del repository a un commit fissato, la definizione di artefatti di verifica deterministici e la generazione di prompt di simulazione utente specifici per il task.

2. Simulatore Utente Ancorato e Condizionato allo Stato

Per riprodurre le interazioni con nuovi agenti, gli autori sviluppano un simulatore utente reattivo basato su LLM. A differenza delle riproduzioni statiche, questo simulatore:

• Si Condiziona sulla Traiettoria: Osserva l'ultimo turno dell'agente valutato, le modifiche al repository e il tempo trascorso.
• Si Ancora all'Intento Originale: Utilizza un'analisi pre-calcolata della sessione originale (obiettivi, vincoli e condizioni di intervento) per garantire che la simulazione rimanga fedele agli obiettivi dell'utente originale.
• Politica Decisionale Condizionata allo Stato: Il simulatore decide se intervenire (inviare un messaggio) o rimanere inattivo (no-op) in base al fatto che la traiettoria attuale dell'agente richieda un feedback secondo la logica della sessione originale. Ciò evita interventi prematuri o irrilevanti.

3. Protocollo di Valutazione Congiunto

La valutazione misura due dimensioni distinte:

• Correttezza del Task: Lo stato finale del repository è valutato rispetto a una rubrica implementativa-agnostica congelata. Questa rubrica è derivata nella Fase 1 (offline) dalla sessione originale e dal patch di riferimento, per poi essere applicata nella Fase 2 ai repository candidati. La valutazione combina controlli eseguibili deterministici con un giudice rubrica agentico per valutare la completezza comportamentale piuttosto che la similarità del codice.
• Diagnostica dell'Interazione:
  • Correzione Utente: Quantifica lo steering correttivo elicitato dall'agente. Conta le correzioni esplicite e i "nudge" pesati (feedback più morbidi) forniti dal simulatore.
  • Copertura dell'Intento: Una metrica diagnostica che misura quanto fedelmente il simulatore preserva gli intenti e l'ambito dell'utente originale attraverso diverse esecuzioni dell'agente.

Contributi Chiave

1. Benchmark SWE-Together: Un benchmark di 109 task ricostruiti da reali sessioni multi-turno utente-agente, caratterizzato da una pipeline che converte le sessioni registrate in task verificabili e sandboxed.
2. Simulatore Utente Ancorato e Condizionato allo Stato: Un simulatore LLM ancorato che preserva gli intenti originali dell'utente e l'ordine degli interventi, adattando al contempo la tempistica del feedback alla specifica traiettoria di ogni agente valutato.
3. Protocollo di Valutazione Congiunto: Un framework che valuta la correttezza finale del repository rispetto a rubriche fisse, caratterizzando al contempo le traiettorie di interazione tramite Correzione Utente e Copertura dell'Intento, andando oltre le semplici metriche pass/fail.

Risultati

Gli autori hanno valutato sette modelli di codifica all'avanguardia sul benchmark di 109 task utilizzando l'harness opencode con due repliche per task.

• Classifica delle Prestazioni: Claude Opus 4.8 ha ottenuto le prestazioni più elevate in tutte le metriche (pass@1: 63%, Stable Solve Rate: 59%, Mean Judge Score: 0.801). GPT-5.5 si è classificato secondo (Mean Judge: 0.763), seguito da Claude Opus 4.6. I modelli più deboli sono stati DeepSeek-V4-Pro e MiniMax-2.7.
• Capacità vs Intervento: È stata osservata una forte correlazione negativa tra la capacità del modello e la Correzione Utente (correlazione di Pearson di -0.92 con pass@1). I modelli più forti richiedevano significativamente meno interventi correttivi per raggiungere livelli di prestazione comparabili (ad esempio, Claude Opus 4.8 richiedeva in media 1.38 correzioni, mentre MiniMax-2.7 ne richiedeva 2.17).
• Efficienza: GPT-5.5 è stato il più efficiente, richiedendo meno token (29.9k) e tempo di esecuzione (10.7 min) per task, mantenendo un'alta capacità.
• Fedeltà del Simulatore: La Copertura dell'Intento è rimasta stabile tra tutti i gruppi di modelli (punteggi tra 0.70–0.72), indicando che il simulatore ha preservato costantemente gli intenti originali indipendentemente dal comportamento dell'agente.
• Indistinguibilità dall'Umano: In un test stile Turing, gli annotatori umani non sono stati in grado di distinguere statisticamente tra le traiettorie simulate e quelle reali (tasso di successo del 46%, CI che include il 50%).

Significato e Rivendicazioni

Il paper sostiene che SWE-Together riformula la valutazione degli agenti di codifica da task a turno singolo a sessioni riproducibili e multi-turno, offrendo una valutazione più realistica dell'esperienza utente.

• Oltre la Correttezza Finale: I risultati suggeriscono che valutare gli agenti solo sul codice finale è insufficiente; l'entità dello steering correttivo richiesto è un indicatore critico di capacità e di esperienza utente.
• Interazione Realistica: Derivando i task da sessioni reali e utilizzando un simulatore condizionato allo stato, il benchmark cattura la natura dinamica dell'ingegneria del software dove i requisiti evolvono.
• Confronto Affidabile: La stabilità della Copertura dell'Intento e l'indistinguibilità delle traiettorie simulate da quelle reali validano la capacità del benchmark di fornire valutazioni eque e comparabili tra diversi gruppi di modelli.

Gli autori concludono che SWE-Together dimostra l'importanza di valutare gli agenti di codifica non solo in base al se completano un compito, ma in base a quanto supporto umano richiedono per farlo, allineando così le metriche del benchmark più strettamente ai reali flussi di lavoro degli utenti.