Alibaba e cinque università asiatiche hanno pubblicato un benchmark che ridimensiona parecchio l’hype sui coding agent. Si chiama Co-Design Bench, e il dato che conta è questo: il modello migliore passa il 69,9% dei criteri, ma completa davvero solo il 26,4% dei task. Uno su quattro. Il resto sono consegne incomplete.
Il problema è che tutti i benchmark precedenti stavano diventando troppo facili. Su WebCompass-edit, opus-4-8 in modalità agentica arriva al 99,4%. Numeri che fanno pensare al problema risolto. Poi provi con richieste vere di utenti veri, e la percentuale crolla al 64,9%.
Da dove vengono i task (e perché non sono sintetici)
Il team — Fudan University, Zhejiang University, Chinese University of Hong Kong, Shanghai Jiao Tong University, Nanyang Technological University e Alibaba Token Hub — è partito da 39.325 query di produzione raccolte in 26.314 sessioni reali di coding. Dopo deduplicazione: 37.463 richieste uniche. Da lì hanno estratto 273 task, ciascuno con un’applicazione web funzionante da modificare e una richiesta utente che può includere immagini, video, audio o documenti.
Ogni task porta con sé criteri di accettazione scritti da esperti — 2.331 in totale — che restano nascosti agli agenti durante l’esecuzione. Niente codice di riferimento, niente screenshot target. L’agente riceve solo la richiesta, l’app di partenza e il contesto. Poi deve consegnare.
Due track, due mondi
Multimodal Editing (ME): 100 task, modifiche localizzate su una singola pagina. L’agente riceve un’annotazione che indica la regione da toccare, più eventuali allegati. Media di 5,5 criteri per task, 553 in totale. Gli allegati principali sono audio in 32 casi, video in 27, documenti in 17, immagini in 4. Venti task non hanno allegati.
Repository Editing (RE): 173 task, modifiche coordinate su repository frontend multi-file. Media di 10,3 criteri per task, 1.778 in totale. Il 77% dei task richiede modifiche di stile, l’87% strutturali, il 76% interattive, il 65% di contenuto. E 166 task su 173 combinano almeno due tipi di modifica.
Le classifiche cambiano da una track all’altra. qwen3.8-27b — un modello open da 27 miliardi di parametri — sale dal quinto al secondo posto passando da ME a RE. kimi-k3 fa il percorso inverso: quarto su ME, sesto su RE. Il ranking globale nasconde queste differenze.
La classifica completa (tutti e 273 i task)
Strict completion è la percentuale media di criteri superati per task. Graded completion conta i PARTIAL come 0,5. Full-pass rate è la quota di task consegnati al 100%.
1. gpt-6-astra (OpenAI): 69,9% / 75,3% / 26,4%
2. opus-5 (Anthropic): 66,1% / 71,9% / 18,3%
3. qwen3.8-max-0902 (Qwen): 65,3% / 71,6% / 16,5%
4. qwen3.8-27b (Qwen): 64,4% / 70,9% / 15,0%
5. kimi-k3 (Kimi): 62,9% / 69,5% / 15,8%
6. gpt-5.6-sol (OpenAI): 61,1% / 67,9% / 14,3%
7. opus-4-8 (Anthropic): 58,1% / 64,9% / 10,3%
8. glm-5.3-flash (Z.ai): 57,3% / 63,9% / 10,6%
9. glm-5.2 (Z.ai): 56,7% / 63,7% / 9,5%
10. grok-4.6 (xAI): 51,1% / 58,0% / 6,6%
Il divario tra strict completion e full-pass è il messaggio. gpt-6-astra passa quasi il 70% dei criteri ma consegna completo solo un task su quattro. Il resto del credito viene da task incompiuti con alcuni criteri soddisfatti. Non è consegna, è credito parziale.
Più compiti insieme, risultati peggiori
Quando un task di repository richiede tre o quattro tipi di modifica diversi — struttura, stile, interattività, contenuto — tutti e dieci i modelli calano in media di 6,3 punti di strict completion rispetto ai task con uno o due tipi. Dal 65,4% al 59,1%. La percentuale di task con zero criteri superati passa dallo 0,9% al 5,8%.
Coordinare cambiamenti su file diversi, con logiche diverse, è un’altra cosa rispetto a ritoccare un componente isolato.
Sforzo e risultato non coincidono
Su ME, gpt-6-astra usa 32 turni mediani e 1,24 milioni di token per task, arrivando al 75,4%. glm-5.2 macina 69 turni e 7,29 milioni di token, fermandosi al 57,2%. Su RE, qwen3.8-27b impiega 57 turni e 6,72 milioni di token per il 64,5%; gpt-6-astra ne usa 48 e 2,33 milioni per il 66,7%.
All’estremo basso, grok-4.6 spende 14 turni su ME e 9 su RE. Risultato: il punteggio più basso del gruppo. Ma più tentativi e più token non garantiscono la consegna. L’efficienza dipende dal modello.
Gli agenti si costruiscono gli strumenti di percezione
I task multimodali non passano solo testo al modello, e i modelli non si limitano a leggere. Il 68,5% delle esecuzioni sui task video chiama OpenCV, il 31,5% ffmpeg. ffmpeg compare anche nel 25% delle run audio, faster-whisper nel 4,4%.
Alcuni agenti scaricano ed eseguono modelli preaddestrati: Whisper, CLIP, DINOv2, OWLv2, CLAP, AST, Qwen2-Audio. Se il modello di base non ha percezione nativa, l’agente se la procura.
Un esempio concreto: tre animazioni, sei criteri
Task video: l’agente riceve una clip di 6 secondi, 600×300 pixel, 20 fps, senza audio. Tre righe di testo animate in modo diverso. Deve riprodurre i tre effetti su altrettanti titoli segnati in rosso sulla pagina, mantenendo testo e layout originali.
qwen3.8-max-0902, con harness Claude Code 2.1.152, estrae tutti i 120 frame, misura luminosità e tonalità, implementa shimmer, ciclo di colori e animazione carattere per carattere. Durante il test si accorge da solo che il testo sparisce durante l’effetto. Corregge. 47 richieste al modello, 60 chiamate a strumenti, 6 criteri su 6 superati.
Altri due task pubblicati: correggere una spesa partendo da una ricevuta PDF e ricalcolare totali e grafici dipendenti (7/7); sincronizzare conteggi di click da un file XLSX e da una foto di bozza stampata su KPI, tabella, grafico e classifica (7/8).
Giudica, poi confuta
Il protocollo di valutazione è in quattro fasi. Build: compila e avvia l’app in sandbox isolata. Gather: raccoglie prove dal codice sorgente, screenshot e interazioni browser tramite Playwright. Judge: assegna PASS, PARTIAL o FAIL a ogni criterio confrontando l’app modificata con quella di partenza. Refute: un verificatore LLM separato contesta ogni verdetto positivo, cercando stub, valori hardcoded, funzionalità non raggiungibili dall’interfaccia.
Niente screenshot di riferimento, niente gold code. Il verificatore non sa come dovrebbe essere implementato il task, sa solo cosa deve fare. Se funziona e soddisfa il criterio, passa.
Perché i vecchi benchmark sembravano risolti
Sugli stessi 150 task di WebCompass-edit, qwen3.7-plus passa dal 73,6% in single-shot al 95,1% in modalità agentica. opus-4-8 arriva al 99,4%. Su Co-Design Bench, lo stesso opus-4-8 si ferma al 64,9% di graded completion.
Gli autori precisano che il confronto usa pool di task e protocolli diversi, quindi non è diretto. Ma il punto regge: l’esecuzione agentica gonfia i punteggi sui task sintetici o semplificati, mentre su richieste reali composite il divario rispetto alla consegna completa resta largo.
Cosa è pubblico
Codice e strumenti di valutazione: GitHub, repo Wiselnn570/Co-Design-Bench. Dataset: Hugging Face, 96 task della track ME su 100 totali, 521 criteri. I task Repository Editing non risultano nel rilascio pubblico. Il paper — arXiv 2610.35138, 22 ottobre 2026 — porta 16 autori, tre primi autori a pari contributo (Xilin Wei, Shengyuan Ding, Xinyu Fang) e tre corresponding author (Dahua Lin, Hang Zhang, Shuai Bai).
Co-Design Bench si affianca a RealSWE e SWE-Together, benchmark 2026 nati dalla stessa esigenza: misurare gli agenti su richieste vere, non su problemi di scuola. SWE-bench e simili si stanno saturando. Questo no.
