Il costo nascosto della configurazione di un agente di coding

1. Introduzione: il problema si è spostato da “se” a “come”

A giugno 2026 Uber ha messo un tetto alla spesa AI per il coding dei propri ingegneri, dopo aver esaurito il budget annuale in quattro mesi (TechCrunch, giugno 2026). Circa 5.000 ingegneri usavano Claude Code, con un costo mensile per persona che oscillava tra 150 e 2.000 dollari a seconda dell’uso: autocompletamento da un lato, orchestrazione di agenti paralleli su un intero monorepo dall’altro. Un dettaglio aggrava il quadro più della cifra in sé: un’iniziativa interna premiava con una leaderboard chi usava di più lo strumento, un incentivo culturale che ha accelerato il consumo invece di contenerlo. Il tetto arrivato dopo, 1.500 dollari al mese per utente, è la conseguenza di una domanda che nessuno si era posto in tempo: quanto costa, in pratica, configurare un agente di coding in un certo modo piuttosto che in un altro.

È il punto in cui si è spostata la domanda rilevante per chi gestisce un team tecnico. Per molte organizzazioni la fase “adottare un agente di coding, sì o no” è già chiusa. Quella ancora aperta riguarda come è configurato l’agente che già si usa, quali strumenti gli sono concessi, e quanto quella scelta pesa sul budget prima ancora che sulla qualità del lavoro prodotto.

Un paper recente (Yang, Yu, Desell, arXiv:2607.10569) prova a rispondere con un esperimento controllato: cosa succede, in termini di costo e di tasso di successo, quando si restringe deliberatamente il numero di strumenti a disposizione di un agente di coding. Le sezioni che seguono ricostruiscono metodologia e risultati, spiegano il meccanismo che li produce, e li trasformano in un framework operativo per chi deve decidere come configurare i propri agenti.

2. Cosa dice il paper

Il paper di riferimento (Yang, Yu, Desell, arXiv:2607.10569) è un preprint accettato a un workshop non-archival, non una pubblicazione in sede peer-reviewed piena: lo si dichiara qui esplicitamente perché cambia il peso corretto da attribuire ai risultati, che restano circoscritti al perimetro sperimentale descritto in questa sezione. Codice e dati dello studio sono pubblici.

Gli autori confrontano tre configurazioni di strumenti sullo stesso compito:

• toolset nativo completo: l’insieme di strumenti standard messo a disposizione dall’agente (lettura file, editing strutturato, ricerca, shell, e altro);
• bash_only: solo primitive di lettura e una shell, senza gli strumenti nativi di modifica (niente Edit/Write strutturati);
• code_only: un solo strumento MCP, execute_code, che espone un REPL persistente Python+Bash, l’agente scrive codice che legge, trasforma e scrive, invece di invocare tool separati.

L’ablazione viene ripetuta su due regimi di task molto diversi tra loro. Artifact è un benchmark sintetico di task di calcolo, Python/Linux, pensato per isolare l’effetto della tool surface su lavoro prevalentemente analitico. SWE-bench Mini è un sottoinsieme di issue reali su repository open source, quindi modifiche di codice esistente, non calcolo puro. Ogni regime viene testato con due agenti, Claude Code e Codex CLI, per un totale di quattro celle regime × agente.

Per la metrica di costo, gli autori vanno oltre il conteggio grezzo dei token: applicano un aggiustamento basato sui prezzi differenziati per i token letti dalla cache (cache-adjusted cost), pur ammettendo di non poter isolare completamente il caching lato server per le API Anthropic e OpenAI. Ogni run ha un limite di 60 minuti, senza una strategia adattiva di interruzione anticipata dei tentativi improduttivi.

3. I risultati nel dettaglio

Il primo dato è la costanza del tasso di successo: tra le tre configurazioni, il pass rate varia per meno di tre punti percentuali in ogni cella, senza differenze statisticamente significative. Le tre configurazioni completano lo stesso lavoro con un tasso di riuscita sostanzialmente equivalente. A cambiare è quanto costa arrivarci.

Regime	Agente	Δ costo di code_only vs. alternativa più economica	Significatività
Artifact	Claude Code	−24,6%	Significativo
Artifact	Codex CLI	−6,7%	Non significativo (direzionale)
SWE-bench Mini	Codex CLI	−19,9%	Significativo
SWE-bench Mini	Claude Code	+14,4%	Non significativo

Tre celle su quattro favoriscono code_only: il vantaggio è statisticamente significativo in due casi (Artifact/Claude, SWE-bench/Codex) e solo direzionale nel terzo (Artifact/Codex). Nella quarta cella il segno si inverte: code_only costa il 14,4% in più su SWE-bench Mini con Claude Code, ma senza significatività statistica.

Il dato più utile, però, è dove si concentra quel sovracosto: si addensa sulle traiettorie destinate comunque a fallire, molto più che sulle modifiche portate a termine con successo. Isolando i soli task superati da tutte le configurazioni, il sovracosto si riduce fortemente. Riprendo questo punto per esteso nella sezione 5, perché è anche il più facile da fraintendere.

4. Perché succede: tool surface e path-cost

La tool surface è l’insieme di azioni che un agente può invocare in un dato momento: lettura, ricerca, editing strutturato, shell, patch, un ambiente di esecuzione programmabile. È una scelta che determina la granularità delle azioni, il numero di round-trip tra modello e strumenti, e la quantità di contesto che rientra nel prompt a ogni passaggio.

execute_code cambia questa superficie in modo specifico: invece di chiamare ogni funzione come tool separato, l’agente scrive codice che combina più operazioni, applica filtri e decide autonomamente cosa restituire al modello. Con Codex CLI questo si traduce in batching concreto: uno script può accorpare più ricerche o operazioni nello stesso passaggio e limitare programmaticamente l’output che torna indietro, invece di generare una chiamata tool per ogni singola azione. Anthropic descrive lo stesso meccanismo, in un caso diverso, nel post “Code execution with MCP: building more efficient agents”, dove riducono il consumo di un workflow MCP esterno da 150.000 a 2.000 token.

Con Claude Code il quadro si inverte parzialmente, ed è qui che entra un effetto che chiamo path-cost: il costo imposto dal modo in cui l’agente deve esprimere un’azione, un termine descrittivo usato in questo articolo, non terminologia originale del paper. Claude Code dispone di strumenti nativi di editing (Edit, Write) già ottimizzati per la modifica puntuale di file. Quando lo stesso lavoro deve passare attraverso uno script Python che legge, sostituisce e riscrive il file, il costo in token di output cresce con il volume delle modifiche. Più il task è ricco di edit, più lo scarto tra le due strade si allarga a sfavore di code_only.

Questo spiega anche perché bash_only non sia il compromesso intermedio che ci si aspetterebbe: su SWE-bench Mini con Codex CLI risulta la configurazione più costosa delle tre. Ridurre il numero di strumenti disponibili non basta: conta come le operazioni vengono aggregate e quanto output intermedio deve transitare nel contesto del modello.

5. Il contro-esempio onesto

Un articolo che raccontasse solo le tre celle favorevoli sarebbe incompleto. Su SWE-bench Mini con Claude Code, restringere il toolset a execute_code costa il 14,4% in più, non meno. Il risultato non è statisticamente significativo: merita comunque una spiegazione più ampia della semplice nota a margine “non significativo, quindi ignorabile”.

Il sovracosto in questa cella non è distribuito uniformemente sui task. Si concentra nelle traiettorie che non arrivano comunque a una soluzione corretta: l’agente insiste, itera, produce output senza convergere, e lo fa più a lungo quando deve esprimere ogni modifica come script invece che come edit nativo. Quando gli autori isolano i soli task risolti con successo da tutte e tre le configurazioni, il sovracosto di code_only in questa cella si riduce fortemente.

Attribuire il sovracosto semplicemente al fatto che “Claude Code peggiora quando gli si tolgono gli strumenti nativi” sarebbe una lettura incompleta: il costo delle run destinate a fallire pesa più del costo delle run che arrivano al risultato, e questo effetto emerge con più forza proprio dove l’agente ha un editor nativo forte da cui viene privato. Per chi gestisce agenti in produzione questa è un’informazione operativa più utile della media aggregata: interrompere prima i tentativi improduttivi può valere quanto ottimizzare i token delle run riuscite, un punto su cui il paper non sviluppa una strategia (si limita a un limite fisso di 60 minuti per run).

6. La tesi centrale: l’unità di misura è l’harness, non il singolo tool

Il contributo concettuale più solido del paper sta nella spiegazione che ne danno gli autori, più che nella tabella dei risultati stessa. Il vantaggio o lo svantaggio di execute_code dipende dall’interazione tra modello, agente, strumenti concessi, modo in cui il lavoro viene aggregato in ogni passaggio, e gestione della cache, più che da un singolo tool isolato. Cambiare uno solo di questi elementi sposta il conto economico, spesso senza toccare il tasso di successo finale.

Questo mette in discussione un modo comune di inquadrare la scelta: confrontare “Claude contro Codex” o “questo tool contro quell’altro” come se fossero variabili indipendenti. Il paper mostra celle in cui lo stesso strumento produce un risparmio marcato con un agente e un sovracosto con un altro, sullo stesso regime di task. Per chi deve decidere, la domanda utile riguarda quale configurazione completa, harness incluso, si comporta meglio per la classe di lavoro da svolgere, più che quale agente o quale tool sia superiore in astratto.

Il campione resta limitato, due agenti e due regimi non bastano per generalizzare a ogni modello o stack, e gli autori lo ammettono esplicitamente. Il paper sposta comunque correttamente il livello della domanda, dal singolo componente alla configurazione nel suo insieme: un criterio che resta valido a prescindere da quali agenti specifici saranno rilevanti tra un anno.

7. Cosa significa per una PMI: framework decisionale

Prima di scegliere un tool, il primo passo pratico è classificare il proprio lavoro. I risultati del paper si comportano diversamente a seconda che il task assomigli di più a lavoro di calcolo isolato (il regime Artifact) o a modifiche estese su un repository esistente (il regime SWE-bench Mini). Trattare le due categorie come un problema unico da risolvere con un solo standard aziendale è l’errore più comune, e il paper offre un motivo tecnico preciso per non farlo: il path-cost di code_only cresce con il volume di edit, quindi penalizza proprio il lavoro di modifica estesa che in una PMI di sviluppo software è spesso la maggioranza del carico.

Il secondo passo è smettere di guardare solo al pass rate. Dai dati e dalle metriche di costo usate nel paper si possono ricavare almeno quattro indicatori, utili anche fuori dal contesto sperimentale:

Indicatore	Cosa misura	Quando usarlo
Costo medio per tentativo	Spesa media di ogni run, riuscita o no	Monitoraggio giornaliero, allarme su deviazioni
Costo per task completato	Spesa divisa solo per i task portati a termine	Confronto tra configurazioni a parità di risultato
Costo delle run fallite	Spesa “persa” su task non risolti	Individuare dove serve una stop condition, non un tool diverso
Distribuzione e coda dei costi	Non solo la media, anche il percentile alto	Individuare i task anomali che da soli gonfiano il budget

Guardare solo il primo indicatore, il più comune nei dashboard di consumo, nasconde esattamente il tipo di problema che ha colpito Uber: budget bruciato soprattutto da un uso non governato, alimentato da una leaderboard interna sull’utilizzo di Claude Code che premiava il consumo, un caso di governance che ha reso la crescita dei costi più rapida delle proiezioni finanziarie.

La conclusione operativa è costruire profili multipli, uno per classe di lavoro, ciascuno con la propria tool surface, il proprio budget massimo per task e la propria stop condition per interrompere run che non stanno convergendo, piuttosto che imporre un’unica regola di restrizione a tutto il parco task. La disciplina che sta emergendo per governare questo, a volte chiamata Agentic FinOps, lavora esattamente su queste leve: budget per team, applicazione, modello e utente, con blocchi o escalation automatiche oltre soglia.

8. Sicurezza e total cost of ownership

Meno strumenti concessi al modello non equivale automaticamente a più sicurezza. Concentrare la capacità dell’agente in un unico strumento come execute_code significa affidare a un ambiente di esecuzione programmabile una superficie di azione ampia: il modello scrive ed esegue codice arbitrario, un’azione più ampia della semplice compilazione di parametri per funzioni predefinite. Quell’ambiente va isolato con la stessa serietà con cui si isolerebbe qualunque processo capace di leggere file, aprire connessioni di rete o gestire credenziali.

Anthropic descrive questo lato del problema nel post “Beyond permission prompts: making Claude Code more secure and autonomous”, costruito su due confini principali: isolamento del filesystem, l’agente accede e modifica solo directory definite, per evitare che un prompt injection alteri file di sistema sensibili; isolamento di rete, l’agente si connette solo a host approvati, per evitare che dati riservati escano o che vengano scaricati eseguibili non controllati. Il meccanismo si appoggia su primitive del sistema operativo, come bubblewrap su Linux, non su un livello applicativo aggiuntivo facile da aggirare.

Il risparmio in token che rende attraente code_only va quindi confrontato con quello che serve per governarlo: sandboxing dell’ambiente di esecuzione, limiti su filesystem e rete, gestione dei secret che l’agente non deve mai vedere in chiaro, audit delle azioni compiute, tempo umano per revisionare configurazioni e log. Nessuna di queste voci compare nel conto dei token: tutte compaiono nel budget reale di un’organizzazione che gestisce agenti in produzione.

La domanda corretta per una PMI riguarda il total cost of ownership completo, non i soli token: costo API, infrastruttura di esecuzione, osservabilità, manutenzione dell’harness, sicurezza, tempo di revisione umana. Un profilo code_only più economico in token può risultare più costoso in totale se l’organizzazione non ha già l’infrastruttura di sandboxing e audit per sostenerlo; un toolset nativo più caro in token può essere la scelta più economica in totale se evita di dover costruire quell’infrastruttura da zero per un volume di lavoro che non la giustifica.

9. Validità esterna per stack enterprise reali

I due regimi testati nel paper hanno un perimetro preciso, da dichiarare prima di trasferirne le conclusioni altrove. Artifact è un benchmark di task di calcolo sintetici, Python e Linux. SWE-bench Mini è un campione di issue reali su repository open source, ben diverso da un monorepo aziendale con anni di debito tecnico, dipendenze private, pipeline CI/CD strutturate e vincoli di sicurezza locali. Nessuno dei due regimi replica uno stack PHP/Laravel o Adobe Commerce con integrazioni legacy, database condivisi tra servizi, o processi di deploy con approvazioni multiple.

Questo circoscrive l’uso corretto del paper, senza sminuirne il valore. Le percentuali di risparmio riportate, dal −24,6% al +14,4% a seconda della cella, non sono una previsione applicabile al proprio stack: dipendono da benchmark, agente, modello, pricing e meccanismo di caching specifici dell’esperimento. Prenderle come cifra di budgeting diretta per un contesto enterprise differente è un trasferimento non supportato dai dati.

Il modo corretto di usare questi risultati è replicare lo stesso tipo di ablazione su un campione interno di task realistici: bug circoscritti, refactoring multi-file, aggiunta di test, migrazioni di schema, analisi di log, manutenzione di codice legacy, modifiche soggette a vincoli di sicurezza specifici. Misurare le stesse quattro metriche di costo della sezione 7 su quel campione, con la propria combinazione di modello, agente e toolset, produce un dato specifico per l’organizzazione, al posto di una percentuale presa in prestito da un esperimento con un perimetro diverso.

Resta un filone aperto quanto pesi, in un monorepo di grandi dimensioni, il tempo speso in ricerca e lettura del contesto rispetto alla computazione pura: è una variabile che il paper non isola esplicitamente, e che potrebbe spostare l’equilibrio tra code_only e strumenti nativi di navigazione ed editing in modi diversi rispetto ai due regimi testati.

10. Conclusione: dichiarazione di metodo

Il risultato più utile di questo paper sta nel cambio di domanda che suggerisce, più che in una percentuale di risparmio da replicare. Quando configuro un agente di coding per un team, la domanda decisiva è se il tipo di lavoro che quel team svolge giustifica il costo, in token e in infrastruttura di governo, di concedergli un determinato strumento: la sua semplice disponibilità è un prerequisito superato da tempo.

Questo articolo nasce da un post pubblicato su LinkedIn il 19 luglio 2026, la prima traccia pubblica di questo ragionamento applicato al paper di Yang, Yu e Desell. Qui il ragionamento si allarga: dalla singola osservazione sul pass rate invariato al framework decisionale delle sezioni 7-9, dal caso Uber alla domanda su cosa cambi per uno stack PHP/Laravel che nessun benchmark pubblico replica ancora.

Il campione del paper resta limitato a due agenti e due regimi, la validità esterna per stack enterprise reali resta da verificare internamente, e il costo delle run fallite resta un problema di stop condition più che di scelta del tool: restano più domande aperte di quante l’esperimento ne chiuda. La direzione che indica, però, dal singolo strumento all’intero harness, resta quella su cui vale la pena costruire la prossima configurazione, prima che un altro budget si esaurisca prima del previsto.