Un team di ricercatori provenienti da Alibaba e da diverse università asiatiche ha presentato Co‑Design Bench, un nuovo test pensato per valutare gli agenti di programmazione (coding‑agent) su compiti reali derivati da sessioni di sviluppo software. A differenza dei benchmark tradizionali, che spesso consentono ai modelli di eseguire, verificare e correggere autonomamente il proprio codice, Co‑Design Bench utilizza richieste autentiche degli utenti, includendo modifiche richieste tramite testo, immagini, registrazioni vocali, video o documenti.

Motivazioni e differenze rispetto ai benchmark precedenti

Gli autori sottolineano che i benchmark esistenti sono ormai saturi: permettendo ai modelli di auto‑testare il proprio output, si registrano punte superiori al 99 % e le differenze tra i modelli risultano difficili da misurare. In test più tradizionali, come WebCompass‑edit, gli agenti di coding raggiungono quasi il punteggio pieno, ma su Co‑Design Bench rimangono più di 35 punti di differenza rispetto al massimo teorico.

Co‑Design Bench è stato costruito selezionando casi in cui gli utenti hanno dovuto riformulare più volte la loro richiesta o annullare modifiche precedenti, evidenziando così le situazioni in cui gli agenti incontrano le maggiori difficoltà. Le attività spaziano da piccole correzioni, ad esempio aggiornare tutti i totali di una ricevuta di cassa, fino a ristrutturazioni complete di interi progetti.

Struttura del test e criteri di valutazione

Il benchmark è diviso in due tracce principali:

Traccia multimodale: gli agenti devono estrarre valori da documenti, tabelle o video e aggiornare in modo coerente tutte le visualizzazioni dipendenti.
Traccia repository: le modifiche sono limitate al codice sorgente di un progetto, ma possono includere cambiamenti di layout, design, logica di interazione e contenuti.

La valutazione è estremamente rigorosa. Un primo KI‑Verifier esegue l’applicazione modificata in un browser, mentre un secondo verifica ogni risultato positivo alla ricerca di "attrappe" o valori hard‑coded. Solo le funzionalità realmente operative nella UI ottengono punti.

Performance dei modelli testati

Dieci modelli sono stati valutati, con GPT‑6 Astra al vertice, seguito da Claude Opus 5 e Qwen 3.8‑Max. Il modello più debole è stato Grok 4.6. Sorprendentemente, Qwen 3.8‑27B, nonostante la sua dimensione più contenuta, ottiene il secondo posto nelle ristrutturazioni più complesse, dimostrando che la dimensione del modello non è l’unico fattore determinante.

Nel dettaglio, GPT‑6 Astra soddisfa in media il 70 % dei requisiti di una singola attività, ma completa interamente solo il 26,4 % delle richieste. In particolare, risolve completamente il 41 % dei compiti multimodali e appena il 18 % dei compiti della traccia repository.

L’effetto della complessità delle richieste

Un risultato chiave è la correlazione inversa tra il numero di tipologie di modifica richieste e la performance del modello. Quando una singola attività combina tre o quattro diverse categorie di cambiamento (layout, design, interazione, contenuto), tutti i modelli mostrano un calo marcato dei risultati. Questo è particolarmente rilevante perché, nella pratica, le richieste di sviluppo sono quasi sempre interconnesse.

Ad esempio, un caso di studio del benchmark richiedeva di:

estrarre un importo da un’immagine di ricevuta,
aggiornare tutti i totali correlati nel database,
modificare il layout della pagina per visualizzare il nuovo importo,
adeguare il messaggio di conferma per riflettere il cambiamento.

Nessun modello è riuscito a soddisfare integralmente tutte e quattro le sotto‑attività, evidenziando una lacuna significativa nella capacità di gestire richieste multidimensionali.

Impatto dell’ambiente di esecuzione (harness)

Un esperimento aggiuntivo ha confrontato le stesse architetture su diversi “harness”, ovvero le piattaforme attraverso cui gli agenti leggono, scrivono ed eseguono il codice. Qwen 3.8‑27B, per esempio, ha mostrato una performance del 75 % in un ambiente ottimizzato, ma è sceso al 56 % in un contesto più restrittivo. Questo dimostra che la valutazione di un agente non può basarsi solo sul modello, ma deve includere l’intera catena operativa.

Gli autori suggeriscono quindi di riportare sempre sia il modello sia l’ambiente di lavoro nei risultati di benchmark, e di testare entrambe le componenti congiuntamente quando si sceglie una soluzione per l’azienda.

Limiti del benchmark e considerazioni pratiche

Co‑Design Bench presenta alcune restrizioni: valuta solo una singola richiesta per volta, ignorando possibili interazioni iterative tra utente e agente, come domande di chiarimento o correzioni in tempo reale. Inoltre, gli KI‑Verifier possono commettere errori di valutazione.

Una ricerca della organizzazione METR ha confrontato le metriche di SWE‑bench Verified con l’adozione reale del codice generato da IA, riscontrando una differenza di circa 24 punti percentuali a sfavore dell’adozione pratica. Ciò indica che i risultati dei benchmark tendono a sovrastimare la capacità dei modelli di produrre codice realmente utilizzabile.

Altri studi hanno evidenziato che vulnerabilità negli ambienti di test possono far “passare” un agente senza che abbia risolto realmente il problema. Tuttavia, una recente indagine su coding‑agent ha mostrato che harness più complessi non offrono vantaggi misurabili, nonostante il consumo di token fino a tre volte superiore.

Conclusioni per professionisti e aziende

Il panorama dei coding‑agent è in rapida evoluzione, ma i risultati di Co‑Design Bench sottolineano che, al momento, la maggior parte dei modelli consegna solo una parte delle funzionalità richieste, lasciando al programmatore la responsabilità di verificare e completare il lavoro. Le aziende che considerano l’adozione di tali strumenti dovrebbero:

valutare sia il modello sia l’ambiente di esecuzione in scenari specifici di progetto;
pianificare risorse per la revisione manuale del codice generato;
preferire benchmark basati su richieste reali e multimodali per una stima più realistica delle capacità operative.

Solo attraverso test concreti e iterativi sarà possibile colmare il divario tra i promettenti numeri dei benchmark e l’effettiva produttività in contesti di sviluppo software.