Cos’è successo.

Due paper pubblicati a luglio propongono benchmark che misurano i coding agent su quello che fanno davvero nel 2026: prendere un’intenzione vaga e costruirci sopra un progetto funzionante. ICAE-Bench (480 task, 12 linguaggi) simula un utente che affida all’agente una richiesta di prodotto incompleta, valutando pianificazione, chiarimento dei requisiti, debugging e integrazione a livello di repository. Tencent WorkBuddy Bench costruisce task reverse-engineered da commit e pull request reali, su quattro domini: codice, web, office, sicurezza.

Perché ti riguarda.

Se usi Claude Code o Codex, sai che la parte difficile non è più fargli scrivere una funzione. La parte difficile è spiegargli cosa vuoi quando tu stesso non lo sai ancora fino in fondo. I benchmark tradizionali tipo SWE-bench, come raccontavamo nella guida al paper che ha definito il campo, danno all’agente una issue di GitHub con istruzioni precise e misurano se la risolve. ICAE-Bench e WorkBuddy partono da un presupposto diverso: l’input è fuzzy, l’agente deve fare domande, prendere decisioni di design, gestire vincoli nascosti.

I risultati di ICAE-Bench lo dicono chiaro: gli agenti riproducono il comportamento visibile ma faticano sui vincoli nascosti, i casi limite e l’integrazione su orizzonti lunghi. È esattamente il punto dove il tuo lavoro di contesto e verifica fa la differenza fra un prototipo che gira e un software che regge.

Nel dettaglio

Il cambio di paradigma è netto. SWE-bench, il benchmark che ha definito come misuriamo i coding agent finora, parte da issue di GitHub con descrizioni già precise: c’è un bug, c’è una feature richiesta, l’agente deve produrre una patch che superi i test. È un modello che corrisponde al lavoro di un programmatore a cui arriva un ticket ben scritto.

Il vibe-coding, il termine con cui si è diffuso l’uso di agenti che costruiscono software da descrizioni informali, ha spostato il baricentro. Chi usa Claude Code o Codex non scrive più specifiche complete: butta un’idea, l’agente fa domande, itera. I benchmark dovevano adeguarsi.

ICAE-Bench affronta il problema con un’architettura interessante. Ogni task deriva da un repository open-source reale con comportamento eseguibile verificato. L’ambiguità non è inventata: viene dalla differenza tra quello che un utente chiederebbe a parole e quello che il codice deve fare davvero. Un User Agent automatico simula la controparte umana, svelando vincoli nascosti man mano che l’agente fa domande, senza però inventare requisiti nuovi o far trapelare la soluzione. La valutazione combina test black-box standardizzati con diagnostiche multi-dimensionali: correttezza funzionale, similarità semantica e API, fedeltà strutturale, qualità del design, qualità dell’interazione.

I risultati su sei modelli e due framework agentici mostrano un pattern ricorrente. Gli agenti riescono a riprodurre il comportamento visibile dell’applicazione, ma cadono sui vincoli nascosti, i casi al contorno e l’integrazione su orizzonti lunghi. La demo funziona, i dettagli no.

Tencent WorkBuddy Bench prende una strada diversa per lo stesso obiettivo. Invece di adattare testo di issue pubbliche, ogni task è ricostruito a ritroso da un commit, una pull request o uno scenario aziendale reale, poi riformulato per resistere alla contaminazione (il rischio che il modello abbia già visto la soluzione nei dati di addestramento). Copre quattro domini: codice, web, office, sicurezza. Il focus sulla contaminazione è rilevante: quando i benchmark si basano su repository pubblici, i modelli più grandi hanno un vantaggio spurio perché hanno memorizzato il codice durante il training.

Cosa cambia per chi usa questi strumenti? Due cose pratiche. Primo, quando leggi un punteggio di coding agent, controlla cosa misura: un numero alto su task con specifiche precise ti dice poco su come l’agente se la caverà con la tua richiesta vaga del venerdì pomeriggio. Secondo, i punti deboli che ICAE-Bench mette in luce (vincoli nascosti, casi limite, integrazione lunga) sono esattamente quelli dove il tuo lavoro di chiarificazione e verifica a campione fa la differenza fra consegnare un prototipo e consegnare software usabile.

I limiti di entrambi i benchmark vanno dichiarati. ICAE-Bench simula l’utente con un modello, il che introduce la variabilità tipica del LLM-as-a-judge: l’User Agent potrebbe essere più o meno collaborativo di un umano vero. WorkBuddy è costruito da un team Tencent e la documentazione completa della metodologia è nel paper, ma la leaderboard cross-model non è ancora pubblica in forma verificabile indipendentemente.