ByteDance ha presentato HarnessDev, un framework di valutazione progettato per misurare la capacità dei large language model di costruire e migliorare autonomamente l’harness utilizzato dagli agenti AI. Con il termine harness viene indicato il livello software che trasforma un modello in un sistema capace di svolgere attività reali, gestendo elementi come ciclo di esecuzione, utilizzo degli strumenti, contesto, stato, memoria, recupero dagli errori e verifica dei risultati. La ricerca parte quindi dall’idea che le prestazioni di un agente non dipendano soltanto dal modello sottostante, ma anche dalla qualità dell’ambiente software nel quale viene fatto operare.
La differenza può essere significativa anche utilizzando esattamente lo stesso modello. Nei dati riportati dai ricercatori, GPT-5 ha risolto il 35,2% dei task di Terminal-Bench 2.1 quando utilizzato con Terminus 2, mentre con Codex CLI la percentuale è salita al 49,6%. HarnessDev nasce proprio per isolare e misurare questo fattore, spostando l’oggetto della valutazione dal risultato finale prodotto dal modello al codice eseguibile con cui il modello costruisce il proprio ambiente operativo.
Il framework divide il processo in due fasi, denominate Creation ed Evolution. Nella fase Creation il modello riceve soltanto un “weak seed”, cioè una base software minima che comprende alcune funzioni fondamentali per file, ricerca e gestione dei processi. Mancano invece elementi come execution loop, planner, verificatori, sistemi di retry e recovery, gestione del contesto e dello stato e criteri per stabilire quando interrompere l’attività. Il compito del modello consiste quindi nel costruire autonomamente un harness completo partendo da questa base molto limitata. Il seed non modificato ottiene infatti zero punti in tutti i benchmark utilizzati.
Nella fase Evolution il modello parte invece dall’ambiente che ha già creato, osserva i risultati ottenuti durante l’esecuzione e utilizza il feedback per modificarne progressivamente il codice. Per valutare questa capacità, i ricercatori hanno utilizzato 100 task di SWE-bench Pro e 89 task di Terminal-Bench 2.1 come insieme di feedback, verificando successivamente la generalizzazione su altri 630 problemi di SWE-bench Pro che non erano stati utilizzati nella fase di sviluppo. Complessivamente sono stati analizzati nove diversi percorsi di sviluppo, 73 versioni ufficiali degli harness e 64 passaggi consecutivi da una versione alla successiva.
Gli esperimenti hanno coinvolto sei modelli: Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek-V4 Pro, Qwen 3.7 Max e Seed 2.0 Pro. La fase di creazione è stata valutata in quattro aree, comprendenti programmazione, analisi dei dati, scrittura e ricerca, utilizzando SWE-bench Pro, Terminal-Bench 2.1, MLE-Bench, EQ-Bench 3 e BrowseComp. In totale il test comprendeva 2.207 task distinti e, oltre al tasso di successo, misurava anche il numero di token consumati durante l’esecuzione.
I risultati hanno mostrato differenze marcate a seconda del tipo di attività. Nella modalità Self-Eval, in cui ciascun modello utilizzava il sistema da esso stesso costruito, Claude Opus 4.8 ha ottenuto il punteggio medio più elevato con 67,8 punti. Il risultato è rimasto però nettamente inferiore agli 86,2 punti raggiunti dagli harness maturi progettati da esseri umani, soprattutto nelle attività di ricerca e, in misura minore, nella programmazione. In altri ambiti il divario si è ridotto o invertito: nella scrittura Opus 4.8 ha ottenuto 84,6 punti contro gli 83,7 del riferimento umano, mentre negli esperimenti di machine learning Opus 4.8 e Gemini 3.1 Pro hanno raggiunto rispettivamente 32,9 e 32,4 punti, superando il riferimento di 24,0.
Gli esperimenti hanno mostrato anche che la quantità di codice generato non corrisponde automaticamente a una maggiore qualità del sistema. Nei test dedicati al coding, 18 implementazioni hanno prodotto complessivamente 17.111 nuove linee di codice, ma il miglior risultato su Terminal-Bench è arrivato dall’harness costruito da Gemini 3.1 Pro, che aveva aggiunto soltanto 1.006 linee e ha raggiunto 68,8 punti. I ricercatori hanno quindi osservato che modifiche più mirate e una verifica più rigorosa possono essere più importanti dell’espansione continua del codice.
Durante l’analisi sono emersi anche casi nei quali determinate funzionalità risultavano presenti nel codice ma non venivano realmente utilizzate durante l’esecuzione. Questo è avvenuto, per esempio, con alcuni meccanismi di stato e memoria, evidenziando una differenza tra la capacità di implementare formalmente una funzione e quella di integrarla efficacemente nel comportamento complessivo dell’agente.
La capacità dei modelli di migliorare autonomamente il proprio harness è risultata ancora relativamente instabile. Nei cinque percorsi Self-Eval analizzati, tutte le versioni finali hanno migliorato le prestazioni rispetto all’harness iniziale sui task nascosti, ma l’incremento è rimasto compreso tra 1,43 e 4,44 punti, con una media di 3,11. Quando invece l’esecuzione veniva effettuata utilizzando un modello Gemini fisso, soltanto Claude Opus 4.8 ha prodotto un miglioramento sui task nascosti, mentre gli altri sistemi hanno registrato un peggioramento.
Anche la correlazione tra il feedback osservato durante lo sviluppo e le prestazioni reali sui task non visibili si è dimostrata debole. Nei 64 passaggi da una versione all’altra, i punteggi ottenuti sul feedback e quelli sui test nascosti si sono mossi nella stessa direzione soltanto nel 53,1% dei casi. Inoltre, tra le nove versioni selezionate come finali, soltanto due si sono rivelate effettivamente le migliori quando sono state valutate sui task nascosti. Questo indica che i modelli hanno ancora difficoltà a capire se una modifica apparentemente positiva migliori davvero la capacità di generalizzazione del sistema.
Uno dei casi più interessanti è stato quello di Claude Opus 4.8. Il modello ha individuato una discrepanza tra le 99 esecuzioni su 100 che il proprio sistema considerava completate correttamente e le sole 48 che avevano effettivamente superato la valutazione. Ha quindi identificato come problema principale una conclusione troppo anticipata delle attività e ha aggiunto al codice un ulteriore meccanismo di verifica prima di dichiarare completato il task. Nonostante episodi di questo tipo, i ricercatori hanno indicato proprio la diagnosi sistematica delle cause di errore come uno degli aspetti ancora più deboli dei modelli.
HarnessDev mostra quindi che i sistemi AI più avanzati sono già in grado di costruire ambienti di esecuzione funzionanti e, in alcuni casi, di migliorarli analizzando il feedback delle proprie prestazioni. I risultati non indicano però che sia stata raggiunta una capacità paragonabile a quella di un ingegnere umano nella progettazione di harness robusti e generalizzabili. Le prestazioni cambiano inoltre sensibilmente quando cambia il modello utilizzato per l’esecuzione, rendendo ancora difficile creare un ambiente che continui a funzionare bene con modelli e attività differenti.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)