The Pulse
Lo studio non rileva vantaggi chiari nella programmazione con gli harness dei fornitori
Un benchmark privato non rileva un vantaggio medio statisticamente chiaro nella programmazione per gli harness nativi dei fornitori rispetto a un’alternativa neutra, ma documenta differenze di configurazione che limitano il confronto.
AI.info Team ·
Un nuovo studio non rileva un vantaggio medio chiaro nella programmazione per gli harness nativi dei fornitori rispetto a un’alternativa neutra, mettendo in discussione un’ipotesi comune nelle valutazioni dei sistemi autonomi di programmazione.
Il paper, «Harness o modello? Isolare l’effetto dell’harness nella programmazione agentica con una suite privata a contaminazione controllata», è stato rivisto e pubblicato su arXiv l’8 settembre 2026. Mohsen Arjmandi confronta gli harness mantenendo costante il modello sottostante, separando il software che gestisce strumenti, prompt, contesto e flusso di controllo dal modello che genera il codice.
Con Claude Opus 4.8, il Claude Agent SDK nativo del fornitore ha risolto il 48,8% dei task, contro il 50,0% dell’harness neutro DeepAgents. Con GPT-5.5, l’OpenAI Codex SDK ha raggiunto il 55,6%, contro il 54,4% di DeepAgents. Nessuna delle due differenze è statisticamente distinguibile da zero nel pool di task selezionato per lo studio.
Stessi modelli, harness diversi
L’esperimento utilizza una suite privata di 256 task progettata per limitare la contaminazione da dati di benchmark pubblici. La suite comprende 179 task su repository, tratti da quattro codebase di produzione, e 77 task di gare di programmazione pubblicati dopo la data limite di ammissibilità dello studio.
Il confronto principale utilizza gli stessi 80 task per ogni coppia modello-harness. Ogni esecuzione avviene in una propria microVM KVM, con seed dei repository e prompt identici. Il paper segnala le differenze di configurazione che restano: la combinazione Codex/GPT-5.5 è stata eseguita in VM da 4 GiB, mentre DeepAgents in VM da 8 GiB. Anche i budget di inferenza e le interfacce degli strumenti erano diversi. Un registro di eventi a sola aggiunta documenta le sessioni, mentre un sistema di valutazione separato, isolato in Docker, verifica le patch ottenute con test nascosti.
Lo studio aveva pianificato 800 chiavi di esecuzione principali in sei celle sperimentali. L’oracolo di valutazione ha prodotto 792 verdetti: 380 esiti positivi, 404 negativi, sette timeout e un errore di applicazione. Otto esecuzioni pianificate si sono concluse con errori infrastrutturali e non sono state valutate.
I risultati di Opus divergono a seconda del tipo di task
Il risultato complessivo di Opus nasconde una netta differenza tra le categorie di task. Nei 61 task su repository, l’harness nativo è indietro di 9,0 punti percentuali rispetto a DeepAgents. Nei 19 task di gare di programmazione, l’harness nativo è avanti di 23,7 punti.
Un test di permutazione attribuisce a questa interazione un valore p di 0,003, ma il paper considera il risultato esplorativo, non conclusivo. La suddivisione tra task su repository e task di gare di programmazione è stata scelta dopo aver esaminato i dati; l’autore afferma quindi che per verificarla adeguatamente servirebbe uno studio progettato intorno a questa distinzione.
Il pool selezionato, inoltre, non rappresenta un campione casuale dell’intera suite di 256 task. Ventiquattro task per i quali i due sistemi nativi dei fornitori avevano dato risultati diversi durante la selezione costituiscono il 30% del pool finale di 80 task. Il disegno dello studio si concentra dunque su task che sembravano già sensibili alla scelta dell’harness.
Una patch corretta non significa sempre che il task sia stato completato
I risultati distinguono due esiti che i benchmark degli agenti di programmazione spesso combinano: se un agente produce una patch corretta e se riesce a completare autonomamente il task entro un limite di tempo.
Le esecuzioni avevano un limite massimo di 1.200 secondi di tempo reale. Delle 81 esecuzioni annullate al raggiungimento del limite, 22 avevano già prodotto patch che avevano superato la verifica dell’oracolo. Un timeout, quindi, non significava sempre che il codice generato fosse errato: in alcuni casi, l’harness non era riuscito a completare la sessione pur lasciando un risultato corretto.
Questa distinzione conta per i team che scelgono i sistemi in base al comportamento operativo, e non soltanto al tasso di superamento. Latenza, criteri di annullamento e gestione del lavoro completato solo in parte possono cambiare il valore pratico di un harness anche quando i tassi di risoluzione finale dei task sono simili.
La stima dei costi è stata riscritta
Il paper rivisto ritratta anche una parte della precedente analisi dei costi. Un normalizzatore della telemetria nel manoscritto dell’agosto 2026 trattava i campi relativi ai token della cache come se tutti gli SDK usassero la stessa convenzione di contabilizzazione. L’autore afferma che l’errore ha alterato le cifre originali dei costi.
Dopo aver ricalcolato i costi a partire dai dati grezzi di utilizzo per turno, applicando i prezzi di listino fissati, l’harness neutro costa da 1,3 a 1,6 volte più dell’harness nativo per ogni task risolto con Opus 4.8. La stima corrispondente per GPT-5.5 è di 1,2 volte tanto. Si tratta di stime basate sull’utilizzo osservato, non di importi fatturati confermati.
Sull’account Anthropic, 58 esecuzioni si sono concluse senza una registrazione dei dati di utilizzo. Attribuire l’intera spesa mancante a uno dei due harness porterebbe il rapporto dei costi di Opus da 0,7 a 2,3, lasciando incerto quale abbia il costo fatturato più basso. Il paper rende pubblici l’orchestratore, l’oracolo di valutazione, il codice di rianalisi e gli aggregati derivati, ma mantiene privata la suite di task.
Cosa può e cosa non può dimostrare lo studio
I risultati non dimostrano che la progettazione degli harness non abbia alcun effetto sugli agenti di programmazione. Mostrano che, in base a questo disegno sperimentale, l’harness di un fornitore non offre un vantaggio medio affidabile rispetto a DeepAgents sui due modelli testati.
Mostrano anche perché le classifiche basate solo sui modelli possono essere incomplete. Un harness determina come un agente riceve gli strumenti, gestisce il contesto, affronta il troncamento, reagisce agli errori e decide quando fermarsi. Queste scelte possono influire sui costi e sul completamento dei task anche quando i tassi di risoluzione delle due combinazioni restano vicini.
Il risultato più solido è più circoscritto: nel pool selezionato di 80 task, l’harness nativo di Claude ottiene 1,25 punti in meno di DeepAgents con Opus 4.8, mentre l’harness nativo di OpenAI ottiene 1,25 punti in più di DeepAgents con GPT-5.5. Entrambi gli intervalli di confidenza includono lo zero.