🤖 AI

The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation

Questo articolo dimostra che l'ambiente di valutazione influenza significativamente le prestazioni e l'efficienza degli agenti di codifica — spesso più della scelta del modello sottostante — rivelando variazioni nell'uso dei token fino a 40 volte e pattern di fallimento indipendenti dal modello, argomentando così a favore della segnalazione delle specifiche complete dell'ambiente e delle metriche di token/latenza insieme ai confronti tra i modelli.

Autori originali: Naman Vats, Oleg Golev

Pubblicato 2026-07-28

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Naman Vats, Oleg Golev

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

La mano invisibile dietro il programmatore robotico

Immaginate di assistere a una competizione culinaria. Vedete due chef brillanti, lo Chef A e lo Chef B, entrambi impegnati a preparare la torta al cioccolato perfetta. I giudici di solito guardano solo la torta finale e dicono: "Lo Chef A ha preparato una torta migliore!". Ma cosa succederebbe se i giudici avessero dimenticato di menzionare che lo Chef A stava usando una cucina hi-tech automatizzata che sminuzzava ogni ingrediente e preriscaldava il forno al secondo esatto, mentre lo Chef B lavorava in un capannone polveroso con un coltello arrugginito e una stufa rotta? Il risultato non riguarda solo il talento degli chef; riguarda la cucina che è stata loro data.

Nel mondo dell'intelligenza artificiale, specificamente dei "coding agent" (programmi di IA che scrivono software), abbiamo fatto esattamente questo. Abbiamo classificato i modelli di IA in base a quanti problemi di programmazione risolvono, ignorando la "cucina" in cui stanno lavorando. Questa cucina è chiamata harness (impalcatura/ambiente di esecuzione). Pensate a un harness come a un assistente invisibile che consegna all'IA i suoi strumenti, gestisce la sua memoria e decide quando smettere di lavorare. Alcuni harness sono come un maggiordomo robotico super efficiente che organizza tutto perfettamente; altri sono come uno stagista caotico che continua a fare la stessa domanda più e più volte, sprecando tempo ed energia. La grande domanda che i ricercatori si pongono è: conta di più il cervello dell'IA o la qualità del suo assistente?

Il grande esperimento della "Cucina"

Un team di ricercatori ha deciso di smetere di tirare a indovinare e ha iniziato a misurare. Hanno allestito un enorme esperimento per vedere cosa succede quando si scambia la "cucina" (l'harness) mantenendo lo stesso "chef" (il modello di IA) esattamente identico. Hanno scelto due modelli di codifica IA molto intelligenti, Qwen 3.6 Plus e MiniMax M2.5, e hanno chiesto loro di risolvere 50 diversi enigmi di programmazione. Ma ecco il colpo di scena: hanno eseguito questi stessi modelli attraverso tre diversi harness open-source, chiamati Goose, OpenCode e OpenHands-SDK.

I risultati sono stati, per dirla tutta, scioccanti.

Quando i ricercatori hanno osservato quanti enigmi l'IA risolveva (il "pass rate"), la differenza tra gli harness era minima. Che l'IA utilizzasse Goose, OpenCode o OpenHands-SDK, risolveva approssimativamente lo stesso numero di problemi — solitamente tra il 38% e il 50%. Cambiare l'harness non rendeva l'IA improvvisamente un genio o un fallimento; il tasso di successo rimaneva sostanzialmente piatto.

Tuttavia, quando hanno guardato il costo per risolvere quei problemi, la storia è cambiata completamente. I ricercatori hanno misurato questo valore in "token", che sono essenzialmente le unità di dati che l'IA elabora (come parole o pezzi di codice). Hanno scoperto che la scelta dell'harness cambiava il costo in modo sbalorditivo: 40 volte.

Per dare un'idea: se l'harness Goose aiutava l'IA a risolvere un enigma usando circa 28.000 token, l'harness OpenCode faceva usare all'esatta stessa IA oltre 1,1 milioni di token per risolvere lo stesso enigma. È una differenza di costo di 40 volte per lo stesso risultato! È come se uno chef usasse un singolo uovo per preparare una torta, mentre l'altro chef ne usasse 40 per la stessa identica torta, semplicemente perché i suoi strumenti di cucina sono inefficienti.

La tassa del "Turno Inattivo"

Perché il costo è aumentato così tanto? I ricercatori hanno scoperto un colpevole nascosto: i turni inattivi (idle turns).

Immaginate di parlare con un amico che sta cercando di riparare il vostro computer. A volte, si limita a stare lì pensando: "Hmm, lasciami controllare questo...", senza scrivere nulla o cambiare nulla sullo schermo. Nel mondo dell'IA, questi sono chiamati "turni senza azione". L'harness OpenCode faceva sedere l'IA in questi loop di pensiero circa 2 volte per task, mentre l'harness Goose lo faceva solo circa 0,2 volte.

Ogni volta che l'IA si ferma in uno di questi loop, deve reinviare tutta la cronologia della conversazione al server per tenere traccia di dove si trova. È come spedire un diario di 100 pagine ogni volta che ci si ferma a riflettere. Poiché OpenCode faceva fermare l'IA e riflettere molto più spesso, consumava i token a un ritmo massiccio. I ricercatori chiamano questa la "tassa di attesa per task". Non è solo un costo in termini di denaro; è un costo in termini di tempo. Uno sviluppatore umano che osserva l'IA deve attendere attraverso questi loop di inattività, fissando uno schermo che non sta facendo nulla, semplicemente bruciando soldi e pazienza.

L'impronta digitale del fallimento

Lo studio ha anche scoperto che ogni harness aveva il proprio modo unico di fallire, come un'impronta digitale. Questi schemi non cambiavano in base al modello di IA utilizzato; erano causati dall'harness stesso.

Goose era il cauto. Quando rimaneva bloccato, si fermava e diceva: "Non posso farlo", piuttosto che tirare a indovinare. Raramente perdeva tempo nel cercare di verificare un'idea sbagliata.
OpenHands-SDK era il persistente. Continuava a provare a verificare le sue risposte o a eseguire operazioni finché non raggiungeva un limite rigido sul numero di tentativi consentiti (il limite di "max turns").
OpenCode era quello che rimaneva intrappolato nei loop. Esauriva il tempo a disposizione (il limite di "wall-time") o rimaneva in uno stato di "hang" (blocco), girando a vuoto senza mai finire.

Questo significa che, se siete uno sviluppatore, non state solo scegliendo un'IA; state scegliendo uno stile di fallimento. Volete un'IA che si arrenda velocemente e onestamente, o una che continui a girare a vuoto finché non esaurite la pazienza?

La grande lezione

La lezione principale di questo articolo è che abbiamo guardato i benchmark di codifica dell'IA nel modo sbagliato. Abbiamo classificato i modelli come Qwen o MiniMax come se fossero l'unica cosa che conta. Ma questo studio dimostra che l'harness (la cucina) è importante quanto il modello (lo chef).

Se volete sapere quanto vi costerà realmente un'IA o quanto tempo ci vorrà per finire un lavoro, non potete guardare solo il nome del modello. Dovete guardare la coppia: il modello e l'harness in cui è in esecuzione. Un modello intelligente in un cattivo harness può essere 40 volte più costoso di un modello intelligente in un buon harness.

I ricercatori suggeriscono che in futuro non dovremmo limitarci a riportare il "Pass Rate". Dobbiamo riportare il costo per task risolto, il numero di turni inattivi e i modelli di fallimento. Perché per un vero sviluppatore umano, la differenza tra un tasso di successo del 50% che costa 1 dollaro e un tasso di successo del 50% che costa 40 dollari è la differenza tra uno strumento utile e un buco nero per il denaro. L' "Effetto Scaffold" è reale, ed è ora di smettere di ignorare la mano invisibile che guida il robot.

Sintesi Tecnica: L'Effetto Scaffold negli Agenti di Coding

Problema
Le attuali classifiche pubbliche per gli agenti di coding classificano principalmente i sistemi in base al nome del modello e al tasso di successo (pass rate), trattando l'impalcatura circostante — lo "scaffold" che emette strumenti, gestisce il contesto e determina la terminazione — come una costante fissa o sotto-specificata. Questo approccio confonde le prestazioni del modello con l'efficienza dello scaffold. Quando le impalcature variano, le metriche di prestazione (pass rate) e le metriche di efficienza (utilizzo di token, latenza) si intrecciano, oscurando il vero costo e l'onere di supervisione richiesto per il deployment di un agente. Il documento sostiene che, per una valutazione incentrata sull'uomo, l'unità di confronto debba essere la coppia harness–modello, non il solo modello, poiché l'harness determina i costi reali e la natura della supervisione umana richiesta.

Metodologia
Gli autori hanno condotto uno studio controllato per isolare l'effetto dell'harness rispetto al modello.

Modelli: Sono stati valutati due recenti modelli agentici di coding: Qwen 3.6 Plus e MiniMax M2.5.
Harness: Sono stati testati tre distinti harness open-source, ciascuno con diverse filosofie di scaffolding:
- Goose: Un agente IDE pesante con pre-iniezione avida dell'albero dei file.
- OpenCode: Un agente a loop di strumenti persistente senza pre-caricamento automatico del contesto.
- OpenHands-SDK: Un'architettura a micro-agente caratterizzata da delega a sub-agenti, tentativi di riprova interni e passaggi di verifica espliciti.
Task: Un sottoinsieme stratificato di 50 task è stato estratto dal dataset Terminal-Bench Pro, coprendo otto archetipi (Bug fix, Build, Data, Implementation, ML, Puzzle, Security, System). Tutti i task hanno utilizzato suite di valutazione pytest deterministiche.
Protocollo: Tutti i trial sono stati eseguiti tramite l'API di OpenRouter con istruzioni del task e prompt di sistema identici (variando solo nel vocabolario specifico degli strumenti). Lo studio ha mantenuto costanti il manifesto del task, l'ambiente sandbox e il limite di tempo (900 secondi), permettendo a ciascun harness di operare con le proprie API di strumenti native, gestione del contesto e logica di riprova interna.
Metriche: Lo studio ha misurato i pass rate, il totale dei token per task risolto, il numero medio di turni (turns), i "turni senza azione" (turni senza modifiche ai file o nuovi comandi) e una tassonomia di fallimento a sei classi (REASON, VERIFY, TIME, MAX TURNS, HANG, ERROR). La significatività statistica è stata valutata utilizzando intervalli di confidenza bootstrap a coppie del 95% ( $B=10.000$ ).

Risultati Chiave

Disparità del costo dei token (Il divario 40×): La scelta dell'harness ha indotto una differenza massiccia nell'efficienza. OpenCode ha consumato circa 40 volte più token per task risolto rispetto a Goose (ad esempio, ~1,5M di token contro ~37K per MiniMax). Al contrario, aggiornare il modello mantenendo fisso l'harness ha prodotto solo una differenza di 1,0–1,3× nell'utilizzo dei token.
Stabilità del Pass Rate: All'interno di un modello fisso, le differenze di pass rate tra gli harness sono state piccole, variando tra 0 e 8 punti percentuali. La maggior parte delle differenze a coppie era statisticamente indistinguibile dallo zero (i CI al 95% includevano lo zero), tranne per il divario maggiore.
Impronte dei Fallimenti (Failure Fingerprints): Modalità di fallimento specifiche si sono replicate in entrambi i modelli, indicando che sono proprietà dell'harness, non del modello:
- Goose: Dominato da fallimenti di tipo REASON (arresto quando bloccato) con zero fallimenti di tipo VERIFY.
- OpenHands-SDK: Caratterizzato da fallimenti VERIFY e MAX TURNS, indicando una tendenza a persistere verso la chiusura o l'esaurimento dei limiti di iterazione.
- OpenCode: Caratterizzato da fallimenti TIME e HANG (esaurimento dei limiti di tempo parete) con zero MAX TURNS (a causa della mancanza di un flag di budget dei turni) e zero VERIFY.
Turni Senza Azione come Tassa sulla Supervisione: OpenCode ha presentato 10 volte più turni senza azione (loop di ragionamento inerti) rispetto a Goose. Questi turni accumulano token di contesto senza fare progressi, creando una "tassa di attesa per task" per gli utenti umani che devono monitorare questi loop inerti.
Efficienza di Pareto: Goose ha dominato la frontiera di Pareto, offrendo pass rate comparabili ad altri harness a una frazione del costo dei token. OpenCode era Pareto-dominato da entrambi gli altri harness.

Contributi Chiave

Quantificazione dell'Effetto Scaffold: Lo studio fornisce prove controllate che la scelta dell'harness guida un divario di 40× nei costi dei token pur spostando il pass rate di al massimo 8 punti percentuali, dimostrando che l'efficienza è in gran parte una proprietà dello scaffold.
Fingerprinting dei Fallimenti Indipendente dal Modello: Gli autori identificano che modalità di fallimento specifiche (ad es., REASON vs. VERIFY vs. TIME) sono coerenti tra diversi modelli quando l'harness è fisso, provando che queste sono distorsioni strutturali dello scaffold.
Proxy Meccanicistico per la Supervisione: Il paper introduce i "turni senza azione" come un proxy per l'onere della supervisione umana, inquadrandoli come un costo (sia finanziario che temporale) che un utente human-in-the-loop deve assorbire, distinto dai semplici costi dei token.
Unità di Valutazione Proposta: Gli autori sostengono che la coppia harness–modello sia l'unità di confronto corretta per la valutazione incentrata sull'uomo, piuttosto che il solo nome del modello.

Significatività e Rivendicazioni
Il paper sostiene che la segnalazione attuale dei benchmark è incompleta perché isola il modello dallo scaffold. Riportando solo i pass rate, le classifiche oscurano il costo reale, la latenza e lo sforzo di supervisione richiesti per il deployment di un agente. Gli autori affermano che, per il deployment pratico, gli sviluppatori devono valutare le coppie harness–modello sotto specifici budget di token/latenza. Raccomandano che le valutazioni future riportino token per task risolto, media dei turni senza azione e vettori di categoria di fallimento insieme ai pass rate per fornire una visione olistica della deployabilità di un agente. Lo studio non pretende di risolvere il problema della valutazione degli agenti, ma piuttosto di sistematizzare l'osservazione che la "scelta dello scaffold" è un driver primario di efficienza e profili di fallimento, spesso superando gli aggiornamenti del modello.