C’è una differenza enorme fra appendere un quadro e ristrutturare un appartamento. Il quadro è un gesto isolato: fori, appendi, finito. La ristrutturazione è una catena di decisioni che si tengono l’una con l’altra: se sbagli l’impianto elettrico al secondo giorno, te ne accorgi al ventesimo, quando le pareti sono già chiuse. Fin qui i benchmark che misurano gli agenti di programmazione hanno chiesto loro soprattutto di appendere quadri: scrivere una funzione, risolvere un bug isolato, far passare un test in un file. Un gruppo di ricercatori guidato da Yukang Feng propone di misurarli su una ristrutturazione vera, e il risultato è impietoso.
Il loro benchmark si chiama LongCLI-Bench, dove CLI sta per command-line interface: la riga di comando, l’ambiente in cui gli agenti moderni come Claude Code e Codex lavorano davvero, aprendo file, eseguendo comandi, leggendo output di errore e ripartendo. La parola che conta, però, è l’altra: long. Compiti lunghi, fatti di decine di passi interdipendenti, dove ogni mossa vive del contesto di quelle precedenti.
Perché serviva un altro benchmark
Il problema che gli autori vogliono chiudere ha tre facce. La prima è la lunghezza: i benchmark storici — da HumanEval a MBPP fino alla serie SWE-bench — valutano compiti brevi, spesso un singolo file o una singola issue, e ignorano le dipendenze sequenziali che rendono difficile il lavoro reale. La seconda è la contaminazione: quando i compiti sono raschiati da repository GitHub pubblici, c’è il rischio concreto che il modello li abbia già visti in addestramento, e allora non stiamo misurando la capacità di ragionare ma quella di ricordare. La terza è la grana della misura: molti benchmark restituiscono solo un verdetto binario, superato o fallito, che non dice dove l’agente è inciampato.
Terminal-Bench, il riferimento più vicino, soffre di tutte e tre le cose: compiti corti, feedback binario. Il confronto numerico che gli autori mettono in tabella è la parte più eloquente dell’intero lavoro. Un compito di LongCLI-Bench tocca in media 104 file e oltre 15.000 righe di codice, e richiede a un esperto umano più di 1.000 minuti di lavoro. Un compito di Terminal-Bench@2, in media, tocca 0,69 file, 227,7 righe, e si chiude in poco più di tre ore. Non è la stessa disciplina praticata su scala diversa: è un altro sport.
La grana fine del benchmark: ogni compito è una catena di requisiti dipendenti, e lo step score misura fin dove l’agente è arrivato prima di fermarsi. Due insiemi di test separati controllano cosa è stato costruito e cosa è stato rotto.
Venti compiti scelti a mano
La materia prima non arriva da GitHub. Gli autori partono da 958 esercitazioni universitarie di informatica, prese da 108 corsi che spaziano dai sistemi operativi alle reti al trattamento dati, e da 50 flussi di lavoro reali di ricerca e ingegneria. Su questa base fanno una scrematura durissima: eseguono i compiti con Codex, ispezionano a mano i risultati e scoprono che gli agenti odierni cavano già senza problemi la maggior parte dei compiti di routine. Buttano via quelli troppo facili e quelli impossibili da valutare in modo consistente, e alla fine restano 20 compiti. Pochi, ma calibrati per far male.
Ogni compito appartiene a una delle quattro categorie in cui gli autori dividono il lavoro di ingegneria del software: costruire un progetto dal nulla ($0 \to 1$), aggiungere una funzionalità a un codice esistente ($N \to N+1$), correggere un bug complesso, ristrutturare del codice senza cambiarne il comportamento ($A \to A’$). A questa dimensione se ne incrocia una seconda, il dominio: programmazione di sistema, sviluppo web, ingegneria dei dati, machine learning, applicazioni, DevOps. Per ridurre ancora la contaminazione, i documenti di requisito vengono in parte riscritti, cambiando nomi di variabili, funzioni e storie di sfondo, così che non basti riconoscere il testo per risolverlo.
Due insiemi di test, e un voto a punti
Il contributo metodologico più interessante è il protocollo a doppio insieme. Ogni compito è giudicato da due batterie di test distinte. I test Fail → Pass (F2P) partono falliti sul repository iniziale e devono passare quando il requisito è implementato: misurano quanto l’agente ha costruito. I test Pass → Pass (P2P) sono già verdi all’inizio e devono restare verdi: misurano quanto l’agente non ha rotto. È la distinzione, spesso ignorata altrove, fra fare la cosa nuova e non guastare la cosa vecchia.
Sopra i due insiemi si costruisce lo step score, un voto a percentuale che dice quanti sotto-requisiti sono stati soddisfatti. Un sotto-requisito conta come soddisfatto solo verificando lo stato reale dell’ambiente — per esempio controllando che una porta sia effettivamente in ascolto e che i log dicano la cosa giusta, non che sia stato semplicemente scritto il comando di avvio. Il verdetto binario, poi, è severo: un insieme di test si considera superato solo quando il suo step score tocca il 100 per cento. Il tasso di successo complessivo di un modello è la frazione di compiti in cui passa entrambi gli insiemi:
$$\text{Pass} = \frac{1}{20}\sum_{t=1}^{20}\mathbb{1}\!\left[\, s^{\text{F2P}}_t = 100\% \;\wedge\; s^{\text{P2P}}_t = 100\% \,\right]$$
dove $s^{\text{F2P}}_t$ e $s^{\text{P2P}}_t$ sono gli step score dei due insiemi sul compito $t$. Un compito passa solo se è finito e integro, insieme.
I numeri, senza sconti
Il verdetto è netto: nessun sistema supera il 20 per cento di tasso di successo. Il migliore è Claude Code con Claude-Opus-4.6, che si ferma al 16,7 per cento (con un Pass@3 del 25 per cento su tre tentativi) e uno step score F2P del 50,7 per cento. Codex con GPT-5.3-Codex arriva al 15 per cento, con step score F2P del 44,1. I modelli open source orchestrati dal framework OpenHands — DeepSeek-V3.1, GLM-4.6, Qwen3-235B-A22B — restano fra il 5 e il 6,7 per cento, con step score F2P fra 25 e 29: i sistemi commerciali completano molto di più dei requisiti.
Ma la diagnosi più utile arriva dallo step score. La maggioranza dei compiti si arena sotto il 30 per cento di completamento: gli agenti non falliscono all’ultimo miglio, falliscono alla partenza. È l’effetto della dipendenza sequenziale — se il terzo passo va storto, il ventesimo non è nemmeno raggiungibile — e senza uno step score un semplice «fallito» lo nasconderebbe.
C’è poi un dettaglio che merita attenzione. Gli step score P2P sono altissimi ovunque, sopra il 98 per cento, eppure il tasso di superamento P2P va dal 70 all’88 per cento. Tradotto: quando gli agenti mettono mano a modifiche non banali, in una quota fra il 12 e il 30 per cento dei casi introducono regressioni, rompono qualcosa che prima funzionava. Non a caso il tasso P2P più alto (88,3 per cento) è di DeepSeek-V3.1, il modello che completa di meno: chi tocca poco, rompe poco.
Gli agenti non falliscono all’ultimo miglio. Falliscono alla partenza, e trascinano con sé tutti i passi che dipendevano dal primo.
L’autonomia da sola non basta
La parte più suggestiva del paper è l’esperimento sulla collaborazione uomo-agente, perché ribalta l’idea che la strada sia solo rendere gli agenti più autonomi. Gli autori provano prima l’auto-correzione: l’agente rilegge il feedback dei test e ci riprova, per più turni. Funziona, ma con un prezzo. I guadagni maggiori arrivano dal primo al secondo turno e poi si assottigliano; peggio, l’ultimo giro di correzioni tende ad allargare l’ambito delle modifiche e a reintrodurre regressioni. Claude-Opus-4.6, per dire, porta il tasso P2P al 95 per cento al secondo turno e lo lascia scendere al 90 al terzo.
Poi provano l’intervento umano, in due forme misurate. Nell’iniezione di piano, prima dell’esecuzione un umano fornisce le linee guida strategiche, senza dettagli di codice. Nella guida interattiva, è l’agente a decidere quando chiedere aiuto: l’umano indica il passo successivo e la rotta, ma se il modello chiede codice pronto la richiesta viene negata, per costringerlo a ragionare (al massimo tre interventi per compito). I numeri parlano da soli. Claude Code passa dal 16,7 per cento in autonomia al 55 con auto-correzione, al 58,3 con il piano o con la guida interattiva, fino al 61,7 per cento combinando piano e interazione. Codex con GPT-5.3-Codex segue la stessa scala: 15 per cento da solo, 50 per cento con piano e interazione insieme. E il piano riduce gli interventi necessari (da 2,4 a 2,1 in media): la strategia disegna la rotta, l’umano risolve gli imprevisti.
L’analisi manuale di 50 traiettorie fallite spiega il perché. Gli errori non sono quasi mai sviste di sintassi locale: sono crolli di lungo respiro. L’agente entra in cicli ripetitivi — stesso comando, stesso errore, patch superficiale, di nuovo — senza riconoscere che il piano è sbagliato. Scambia problemi d’ambiente per errori di logica e mette mano al codice giusto per la ragione sbagliata. E lungo esecuzioni lunghe perde il filo, dimentica vincoli dichiarati prima, rompe ciò che aveva costruito. Sono esattamente le cose che una buona strategia iniziale, umana, previene.
I limiti, dichiarati dagli autori
Il titolo stesso contiene la parola preliminary, e non è modestia di facciata. Costruire ogni compito è costato in media 40 ore di lavoro manuale — requisiti, soluzione di riferimento, ambiente Docker, test — ed è la ragione per cui i compiti sono venti e non duecento. È un campione piccolo, e gli stessi autori ammettono che lo step score, per quanto più informativo di un verdetto binario, non cattura ogni sfumatura del lavoro. Vale poi ciò che vale per ogni benchmark su modelli: è una fotografia a una certa data, e i modelli citati saranno superati in fretta. Ma la struttura — compiti lunghi, non contaminati, con doppio test e punteggio a passi — è pensata per sopravvivere ai singoli modelli.
Perché ci riguarda
Il messaggio che LongCLI-Bench consegna, con numeri e non con slogan, è che la programmazione agentica di lungo respiro è un problema aperto. Sui compiti brevi gli agenti sono già bravissimi; su quelli che assomigliano al lavoro vero — decine di passi che si tengono l’un l’altro, la memoria da mantenere, la disciplina di non rompere il resto — barcollano, e barcollano presto. La leva che sposta di più i risultati non è un altro giro di autonomia, ma un umano che al momento giusto dà la direzione. Chi vende agenti che «scrivono software da soli» farebbe bene a leggere la tabella della collaborazione: il salto dal 16 al 62 per cento non lo fa il modello, lo fa la coppia. Gli agenti assistono, il giudizio resta umano.
Il paper
Yukang Feng, Jianwen Sun, Zelai Yang et al., LongCLI-Bench: A Preliminary Benchmark and Study for Long-horizon Agentic Programming in Command-Line Interfaces, arXiv:2602.14337 (2026). Progetto: github.com/finyorko/longcli-bench.
I commenti sono riservati agli iscritti.
Accedi per commentare