A-CODE-LLM Bench: Benchmark di Codifica Agentica
Abbiamo testato i migliori Large Language Models (LLM) su 10 attività di sviluppo software utilizzando uno strumento CLI agentico. Abbiamo eseguito circa 3.500 passaggi di validazione automatizzati per modello sia a livello API che UI.
Risultati di A-CODE-LLM Bench
Ogni alias è stato eseguito 3 volte su 10 attività (30 campioni per alias, 400 celle per iterazione su 40 alias). Vedi maggiori dettagli sulla metodologia.
- Sonnet di fascia media batte l'Opus di punta. Entrambe le versioni di Sonnet superano ogni Opus, incluso Opus 4.8 (0.702). Il tier più costoso di Anthropic non è il suo miglior programmatore.
- La vetta non è più solo Anthropic: Grok 4.5 (0.732) batte ogni variante Opus. Il nuovo flagship di OpenAI, GPT 5.6 Sol, registra il miglior punteggio dell'azienda (0.615), ancora 0.157 sotto Sonnet 5, e le sue varianti pro a maggior calcolo finiscono per lo più sotto le rispettive versioni base (Sol Pro 0.543, Terra Pro 0.568; solo Luna Pro migliora, 0.603 vs 0.579).
- I modelli specializzati in codice non hanno vinto il benchmark di codifica. GPT 5.3 Codex, la variante ottimizzata per il codice di OpenAI, ottiene 0.572, a metà classifica e sotto il modello generale GPT 5.4 Mini di OpenAI (0.594). Kimi K2.7 Code di Moonshot è lo specialista più forte con 0.611.
- Kimi K3, un modello generale, prende il comando tra i modelli a pesi aperti scavalcando lo stesso specialista di codice di Moonshot: 0.725, sesto assoluto, 0.114 sopra K2.7 Code. Il suo backend 0.632 si classifica quinto, sopra ogni alias Opus e GPT.
- Inkling, il primo modello di Thinking Machines, debutta con 0.575, terzo tra i modelli a pesi aperti. Il suo frontend 0.747 batte ogni alias GPT 5.6; il backend 0.501 ne limita la classifica.
- Nessun modello è affidabile sul backend: il tetto è 0.701 (Sonnet 5), quindi anche il vincitore fallisce circa un terzo dei controlli di logica di business e contrattuali. Grok 4.5 si avvicina di più tra le aggiunte di luglio con 0.663. Il frontend è quasi risolto tra i leader (da 0.79 a 0.96), quindi il backend è il problema aperto e determina la classifica. Claude Haiku 4.5 rende bene (0.731), ma un backend di 0.277 lo tiene a 0.413.
- Il punto debole di GPT è il frontend. GPT 5.4 e 5.5 eguagliano Opus 4.8 sul backend (circa 0.6) ma ottengono da 0.53 a 0.55 nel frontend; la famiglia GPT 5.6 lo porta da 0.63 a 0.71, ancora ben sotto la linea Sonnet sopra 0.91.
Confronto costo e tasso di successo
- I modelli al prezzo flagship sono il peggior rapporto qualità-prezzo. Opus 4.7 è il più costoso ($3.08/cella) e ottiene 0.610, sotto Sonnet 4.6 a $1.33.
- La vetta impone un forte premium per un guadagno minimo: Sonnet 5 ottiene 0.024 in più di Sonnet 4.6 per il 70% in più di costo per cella.
- Grok 4.5 è il nuovo miglior rapporto qualità-prezzo: 0.732, entro 0.040 dal vincitore, a $0.46 per cella, contro $2.23 di Sonnet 5. All'interno della famiglia GPT 5.6 il prezzo non compra nulla: da $0.18 (Luna) a $2.76 (Sol Pro) per cella per punteggi tra 0.543 e 0.615, con l'alias più economico che supera il più costoso.
- Kimi K3 si compra il sesto posto a un prezzo di fascia media: $1.47 per cella, vicino a $1.33 di Sonnet 4.6 ma con un punteggio superiore di 0.007, e ben sotto $2.23 di Sonnet 5. Inkling costa $1.64 per cella a prezzo di listino per 0.575, sopra Sonnet 4.6 per un punteggio inferiore.
Confronto tempi di completamento e tasso di successo
- Il punteggio più alto è tra i più lenti. Sonnet 5 impiega circa 30 minuti per attività, 3x Sonnet 4.6 per 0.024 in più; Sonnet 4.6 dà quasi lo stesso punteggio in un terzo del tempo.
- Una lunga esecuzione di solito indica un modello bloccato, non uno accurato: i peggiori punteggi, entrambe le varianti Qwen, il modello base GLM 5.1 e Deepseek V4 Pro, hanno ciascuno superato i 1.700 secondi per eccesso di iterazione, con punteggi inferiori a 0.45.
- Grok 4.3 era veloce perché si fermava presto: 142 secondi e 18 chiamate tool per 0.431. Grok 4.5 mantiene la velocità e abbandona la resa anticipata: circa 9 minuti per attività, meno di un terzo del tempo di Sonnet 5, per 0.732.
- Kimi K3 si colloca all'angolo opposto: punteggio di vertice, velocità peggiore. Registra in media circa 55 minuti per attività, il più lento in campo e circa il doppio di Sonnet 5, per un sesto posto di 0.725. La sua accuratezza è reale, ma è la via meno pratica per la fascia alta.
Chiamate tool per attività
- Il numero di chiamate tool non misura né la capacità né lo sforzo confrontabile. Sonnet 5 ha fatto il maggior numero di chiamate (125) e ha ottenuto il punteggio più alto; MiniMax M3 ne ha fatte 108 per un 0.583 di metà classifica; Grok 4.5 ha raggiunto 0.732 con 40; i bassi valori di OpenAI (da 16 a 36) derivano dall'apply_patch che raggruppa un intero file in una chiamata. Sol Pro e Terra Pro chiamano da un quarto a un terzo in meno di strumenti rispetto alle rispettive basi e ottengono meno: più ragionamento, meno esecuzione. Non classificare gli agenti in base al volume di tool.
- Due percorsi raggiungono lo stesso punteggio: Sonnet 5 itera pesantemente (125 chiamate), Sonnet 4.6 a malapena (circa 50), con una differenza di 0.024.
Prestazioni LLM su un singolo task completato con successo
Nessun modello ha superato ogni passaggio del benchmark completo sopra descritto. Per confrontare costo e velocità in condizioni omogenee, abbiamo eseguito un task di base semplice che ogni modello è in grado di completare: quattro endpoint CRUD, validazione di base, nessuna autenticazione e nessun database.
Confronto costo e righe di codice
- Task semplici non possono classificare i modelli, quindi le valutazioni giocattolo sono fuorvianti. Sul task di base che tutti i modelli superano, il codice converge a 40–64 righe, e il costo scende a centesimi; le differenze compaiono solo su lavori lunghi e multi-file.
- Il tier “veloce e leggero” è stato il più costoso qui: Gemini 3.5 Flash base ha scritto 131 righe per il task banale, da due a tre volte il resto, diventando il più costoso sul task di base, contro la sua propria collocazione.
- L'iterazione pesante di Sonnet 5 dipende dal task, non è un'abitudine: 9 chiamate e $0.09 qui contro 125 chiamate nel benchmark.
Vedi maggiori dettagli nell'articolo LLM Pricing.
Tempo di completamento e utilizzo dei token
- La prevedibilità dei costi divide i modelli in due. I modelli adattivi spendono solo quando necessario (Opus 4.8: 34s baseline, 1.072s benchmark); i modelli a passo fisso sono lenti e costosi anche su lavori banali (MiniMax M3: 475 vs 1.684s).
- La lunghezza dell'output è un tratto fisso del modello, con un divario di quasi 10x per lo stesso task (da 787 a 7.508 token), che incide direttamente sul costo.
Cosa sono i sistemi LLM agentici?
Costruire software è iterativo: scrivere codice, eseguirlo, leggere gli errori, correggerli, ripetere. I sistemi di IA agentica consentono agli LLM di seguire lo stesso ciclo. Il modello opera all'interno di un ambiente di sviluppo dove può scrivere file, eseguire comandi, leggere gli output e apportare modifiche in base a ciò che vede, continuando fino al completamento del task.
Questo è importante perché le applicazioni reali non sono singoli file. Hanno backend con route e modelli di database, frontend con componenti e chiamate API, file di configurazione, dipendenze e test. Farli funzionare insieme richiede test e perfezionamenti iterativi, esattamente ciò che l'architettura agentica abilita.
Come funziona
Il modello si trova all'interno di un harness con accesso a una shell, al file system e all'output dell'esecuzione. Quando gli viene chiesto di costruire un'applicazione, scrive i file in modo incrementale. Dopo ogni passo, l'harness mostra al modello cosa è successo: il server si è avviato, i test sono passati, il linter ha segnalato errori? Sulla base di quel feedback, il modello decide cosa scrivere o correggere dopo.
Questo differisce fondamentalmente dalla generazione one-shot. Nelle configurazioni one-shot, il modello genera un'intera codebase alla cieca, senza modo di verificare se funziona. Nei sistemi LLM agentici, il modello vede le conseguenze di ogni azione e corregge la rotta. Tuttavia, questa sola capacità non è sufficiente. Il modello ha ancora bisogno di un forte ragionamento per implementare correttamente la logica di business, ed è qui che emergono veramente le differenze di prestazione.
Aggiungi come fonte preferitaMetodologia del benchmark di LLM agentico
Abbiamo usato Opencode come harness agente per tutti i modelli e li abbiamo connessi tramite OpenRouter, con due eccezioni: Claude Fable 5 è stato eseguito sulla CLI Claude Code con abbonamento Claude, e Inkling è stato eseguito tramite l'API compatibile con OpenAI di Thinking Machines perché il modello non è disponibile su OpenRouter. Ogni cella è stata eseguita 3 volte per misurare la varianza per cella e stabilizzare la classifica. Abbiamo valutato la loro capacità di lavorare autonomamente su 10 task di sviluppo software (da T-1 a T-10), che spaziano da sistemi di prenotazione a cruscotti interattivi. Questi task richiedono agli agenti di gestire progetti multi-file e fornire prodotti funzionanti. I sette alias aggiunti a luglio 2026 (Grok 4.5 e la famiglia GPT 5.6: Sol, Terra, Luna, ciascuno in modalità base e pro) sono stati eseguiti su Opencode 1.15.13 con impostazioni predefinite API, come ogni modello qui; i numeri di lancio di OpenAI per Sol utilizzano modalità a calcolo superiore.1 Quattro celle di Sol Pro e una cella di Terra Pro si sono concluse con ripetuti fallimenti silenziosi del flusso API anziché con errori del modello e sono considerate fallite.
Kimi K3 e Inkling sono stati aggiunti il 18 luglio con impostazioni predefinite API; Inkling è stato eseguito con il suo sforzo di pensiero predefinito di 0.9. La colonna del costo di Inkling usa i prezzi di listino di Thinking Machines: $3.74 per milione di token di input e $9.36 per milione di token di output; il fornitore ha fatturato circa la metà in base a uno sconto di lancio a tempo limitato.2 Entrambi i modelli sono stati eseguiti con un limite di 150 minuti per cella anziché i precedenti 45 minuti, perché il flusso di token di Kimi K3 è abbastanza lento da raggiungere il limite più breve durante la build; il tempo di completamento è riportato separatamente nel grafico temporale. La capacità condivisa del fornitore di Kimi K3 ha restituito frequenti errori di rate-limit e timeout durante la finestra di esecuzione; le celle interessate sono state rieseguite una volta contro lo stesso limite, la stessa politica applicata ai fallimenti di flusso di Sol Pro e Terra Pro sopra citati.
Esecuzione e orchestrazione
Ogni agente e ogni task partono in un ambiente pulito. Le istruzioni vengono fornite come file TASK.md e utilizziamo un watchdog heartbeat di 20 minuti per gli script di avvio. Durante questa fase registriamo i codici di uscita, il tempo di esecuzione e se i file del backend e del frontend sono stati creati. Tracciamo anche l'uso dei token in tempo reale nelle categorie input, output e memorizzati nella cache.
Validazione del backend: Distribuiamo i progetti generati in ambienti isolati per testarli contro un contratto YAML canonico. La validazione copre scenari di percorso felice, gestione degli errori (400/403/409) e coerenza dei dati.
Testiamo i risultati in due modalità:
La modalità adattiva convalida la funzionalità anche con nomi di route diversi, mentre la modalità rigorosa richiede un'aderenza esatta al contratto.
Il punteggio complessivo del backend è calcolato per cella come:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
dove has_backend è 1 se la cella ha prodotto un progetto backend, 0 altrimenti. L'adattivo ha un peso maggiore perché misura la correttezza comportamentale; il rigoroso aggiunge una penalità per la deriva contrattuale (route rinominate, codici di stato sostituiti, campi di risposta ristrutturati).
Test dell'interfaccia utente e degli scenari d'uso
Usiamo l'automazione del browser per simulare flussi utente reali, inclusi preflight, rendering e autenticazione. Verifichiamo passaggi funzionali come l'invio del login e il comportamento post-login per garantire che l'applicazione venga eseguita senza crash.
Il punteggio dell'UI divide otto passaggi in due gruppi. I passaggi infrastrutturali (preflight del backend, rendering del frontend, modulo di login visibile, invio del login, 2xx del login, nessun crash di runtime) misurano se l'app viene eseguita. I passaggi comportamentali (segnale di autenticazione post-login, segnale di comportamento post-login) valutano se l'app esegue la funzione prevista una volta in esecuzione.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
I passaggi comportamentali bloccati sono esclusi dal denominatore del comportamento, quindi una cella non viene penalizzata due volte quando l'app non si carica.
Calcolo dei token
I conteggi dei token sono estratti dalla risposta dell'LLM API. Sottraiamo i token di input memorizzati nella cache dal totale dei token di input per ottenere l'input effettivo, che riflette solo i token appena elaborati. I token di output non vengono mai memorizzati nella cache, quindi rimangono invariati.
Aggregazione finale
Il punteggio finale del benchmark è calcolato combinando i risultati delle fasi precedenti: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Assegniamo un peso maggiore al backend perché i fallimenti logici a livello API spesso invalidano qualsiasi successo nel frontend.
Esempio di task
Task 6: Sistema di ticketing per helpdesk
Il task 6 si concentra sullo sviluppo di un ecosistema complesso di assistenza clienti. L'obiettivo principale è costruire una piattaforma che faccia da mediatore tra clienti e operatori di supporto, applicando rigorosamente regole di business e confini di sicurezza. Questo task valuta la capacità di un agente di gestire macchine a stati multi-utente, isolamento dei dati e comunicazione basata su thread in un ambiente full-stack.
Il task richiedeva la costruzione di un sistema helpdesk con le seguenti caratteristiche:
- Permessi distinti per i Clienti (emissione/risposta) e gli Agenti (gestione/risoluzione).
- Un flusso di stati rigido che impedisce transizioni illegali e applica azioni specifiche per ruolo.
- Isolamento avanzato dei dati, in cui le richieste di risorse non autorizzate restituiscono 404 invece di 403 per proteggere l'integrità del sistema.
- Un sistema di risposte cronologiche per un'interazione fluida tra operatore e cliente.
- Un backend FastAPI combinato con un frontend reattivo basato su Vite (React/Vue/Svelte).
- Configurazione riproducibile tramite comandi shell specifici per l'attivazione immediata del sistema.
Puoi consultare la documentazione del Task 6 su GitHub.
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Benchmark di Codifica Agentica}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Consultato il 12 Agosto 2026}
}Risultati e timestamp di 429 punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente 2 file CSV e un README.
Collegamenti di riferimento
Il lavoro di Cem è stato citato da importanti pubblicazioni globali tra cui Business Insider, Forbes, Washington Post, aziende globali come Deloitte, HPE e ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione europea.
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente di tecnologia e imprenditore tecnologico. Ha consigliato aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un rapporto McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha anche guidato la crescita commerciale dell'azienda deep tech Hypatos che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da 0 in 2 anni. Il lavoro di Cem in Hypatos è stato trattato da importanti pubblicazioni tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato in ingegneria informatica all'Università Bogazici e ha conseguito un MBA presso la Columbia Business School.
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.