Databricks ha pubblicato metodologia e risultati del benchmark interno con cui valuta i coding agent. Non su task pubblici, ma sulle pull request realmente mergiate dai suoi ingegneri su una codebase da milioni di righe che copre Scala, Go, Rust, Java, Python, TypeScript, Bazel e Protobuf. La domanda di partenza era operativa: quale combinazione di modello e harness dà la qualità migliore a un dato costo.
La scelta di non usare SWE-Bench o TerminalBench è motivata: i task pubblici col tempo finiscono nei dati di training, e comunque non rappresentano una codebase poliglotta. Il benchmark parte invece dalle PR interne, filtrate per recency, scrittura umana, presenza di un test suite di qualità e modifiche contenute in pochi moduli. Dalla PR si ricava il prompt tenendo l’intento e rimuovendo la descrizione della soluzione; i test vengono messi da parte e riapplicati alla fine per decidere pass o fail. Nessun LLM judge: secondo gli autori premia il “sembrare giusto” più dell’essere giusto.
Cosa è emerso
Il frontier di Pareto qualità/costo include modelli OpenAI, Anthropic e open source insieme: nessun fornitore singolo copre tutta la curva. GLM 5.2 entra nella fascia di capability più alta, statisticamente pari a Opus 4.8 sulla qualità ma a 1,28 $/task contro 1,94 $.
Il punto più utile per chi porta questi strumenti in produzione è però un altro: il prezzo per token è un pessimo indicatore del costo reale. Sonnet 5 costa circa 1,7 volte meno per token di Opus 4.8, ma sui task Databricks è arrivato a 2,09 $/task contro 1,94 $, con un tasso di completamento dell’81% contro l’87%, perché ha lavorato più a lungo, letto di più e consumato 1,9 volte più token.
Anche l’harness pesa. Stesso modello, stesso thinking effort, harness diversi: costo per task oltre due volte più alto in alcuni casi, a parità di qualità. La differenza sta nel contesto inviato a ogni turno — Pi ne manda circa 3 volte meno di Claude Code/Codex e chiude i task in meno run.
Perché conta per il tuo team
L’analisi dei log di utilizzo mostra che circa un quarto dei task è a bassa complessità e circa il 60% a complessità media, mentre il default degli ingegneri restava il modello più caro. La conclusione pratica di Databricks è spostare il lavoro ordinario su modelli di fascia media.
C’è poi un dettaglio metodologico che chiunque voglia replicare l’esperimento dovrebbe conoscere: nei primi run alcuni punteggi erano troppo buoni, perché gli agent, avendo accesso alla shell, ritrovavano l’implementazione corretta nella git history del worktree. È stato necessario isolare la copia di lavoro dal repository per tutta la durata della run.
Il messaggio finale è replicabile senza budget di ricerca: se hai un backlog di PR mergiate e test scritti dal tuo team, hai già un benchmark che nessun modello ha visto in training, con criteri di correttezza definiti da te.
In sintesi
- Il costo per token non predice il costo per task: serve misurare end-to-end, sui propri task.
- L’harness incide su costo ed efficienza quanto la scelta del modello.
- Le pull request già mergiate del tuo repository sono un benchmark gratuito e non contaminato.
Fonte: Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase — https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase
Hai qualcosa da aggiungere? Unisciti alla discussione.