A-CODE-LLM Bench: Benchmark di Coding Agentico
Abbiamo confrontato i migliori Modelli Linguistici di Grandi Dimensioni (LLMs) in 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 di interfaccia utente.
Risultati del Benchmark A-CODE-LLM
Ogni alias è stato eseguito 3 volte su 10 attività (30 campioni per alias, 380 celle per iterazione su 38 alias). Vedi maggiori dettagli sulla metodologia.
- Sonnet di fascia media batte l'Opus di punta. Entrambe le versioni di Sonnet superano tutti gli Opus, incluso Opus 4.8 (0.702). Il livello più costoso di Anthropic non è il suo miglior programmatore.
- Il vertice non è più appannaggio esclusivo di Anthropic: Grok 4.5 (0.732) supera ogni variante di Opus. Il nuovo di punta 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 calcolo più elevato per lo più restano al di sotto delle loro basi (Sol Pro 0.543, Terra Pro 0.568; solo Luna Pro migliora, 0.603 contro 0.579).
- I modelli specializzati nel codice non hanno vinto il benchmark di coding. GPT 5.3 Codex, la variante ottimizzata per il codice di OpenAI, ottiene 0.572, a metà classifica e sotto il modello generico di OpenAI GPT 5.4 Mini (0.594). Kimi K2.7 Code di Moonshot è lo specialista più forte con 0.611.
- Nessun modello è affidabile nel backend: il tetto è 0.701 (Sonnet 5), quindi anche il vincitore fallisce circa un terzo dei controlli di logica di business e di contratto. Grok 4.5 si avvicina di più tra le aggiunte di luglio con 0.663. Il frontend è quasi risolto tra i leader (0.79 a 0.96), quindi il backend è il problema aperto, ed è ciò che determina la classifica. Claude Haiku 4.5 renderizza 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 nel backend (circa 0.6) ma ottengono 0.53 a 0.55 nel frontend; la famiglia GPT 5.6 alza quel valore a 0.63 a 0.71, ancora ben al di sotto del livello di oltre 0.91 della linea Sonnet.
Confronto costi e successo
- I modelli al prezzo di punta sono il peggior rapporto qualità-prezzo. Opus 4.7 è il più costoso ($3.08/cella) e ottiene 0.610, al di sotto di Sonnet 4.6 a $1.33.
- Il top applica un forte sovrapprezzo per un guadagno minimo: Sonnet 5 ottiene 0.024 in più di Sonnet 4.6 con un costo per cella più alto del 70%.
- Grok 4.5 è il nuovo miglior rapporto qualità-prezzo: 0.732, a 0.040 dal vincitore, a $0.46 per cella, rispetto ai $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.
Confronto tempo di completamento attività e successo
- Il punteggio più alto è tra i più lenti. Sonnet 5 impiega circa 30 minuti per attività, 3 volte Sonnet 4.6 per 0.024 in più; Sonnet 4.6 offre quasi lo stesso punteggio in un terzo del tempo.
- Una lunga esecuzione di solito indica un modello bloccato, non uno approfondito: i peggiori classificati, entrambe le varianti Qwen, GLM 5.1 base 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 arrendeva presto: 142 secondi e 18 chiamate a strumenti per 0.431. Grok 4.5 mantiene la velocità ed elimina l'abbandono: circa 9 minuti per attività, meno di un terzo del tempo di Sonnet 5, per 0.732.
Chiamate a strumenti per attività
- Il numero di chiamate a strumenti non misura né la capacità né lo sforzo che puoi confrontare. Sonnet 5 ha effettuato il maggior numero di chiamate (125) e ha ottenuto il punteggio più alto; MiniMax M3 ne ha fatte 108 per un punteggio di metà classifica 0.583; Grok 4.5 ha raggiunto 0.732 con 40; i bassi valori di OpenAI da 16 a 36 derivano dal fatto che apply_patch raggruppa un intero file in una chiamata. Sol Pro e Terra Pro chiamano da un quarto a un terzo meno strumenti delle loro basi e ottengono punteggi inferiori: più ragionamento, meno esecuzione. Non classificare gli agenti in base al volume di strumenti.
- Due percorsi raggiungono lo stesso punteggio: Sonnet 5 itera pesantemente (125 chiamate), Sonnet 4.6 a malapena (circa 50), a 0.024 di distanza.
Prestazioni degli LLM in un singolo compito riuscito
Nessun modello ha superato ogni fase dell'intero benchmark sopra. Per confrontare costi e velocità a parità di condizioni, abbiamo eseguito una semplice attività di base che ogni modello può completare: quattro endpoint CRUD, validazione di base, nessuna autenticazione e nessun database.
Confronto costo e righe di codice
- Compiti semplici non possono classificare i modelli, quindi le valutazioni giocattolo sono fuorvianti. Sulla linea di base che ogni modello supera, il codice converge a 40 a 64 righe, e il costo scende a centesimi; le differenze compaiono solo in lavori lunghi e su più file.
- Il livello "veloce e leggero" era il più costoso qui: Gemini 3.5 Flash base ha scritto 131 righe per il compito banale, da due a tre volte gli altri, rendendolo il più costoso della linea di base, contro il suo stesso posizionamento.
- L'iterazione pesante di Sonnet 5 è guidata dal compito, non è un'abitudine: 9 chiamate e $0.09 qui contro 125 chiamate sul benchmark.
Vedi maggiori dettagli nell'articolo LLM Pricing.
Tempo di completamento e consumo di token
- La prevedibilità dei costi divide i modelli in due. I modelli adattivi spendono solo quando necessario (Opus 4.8: 34s linea di base, 1.072s benchmark); i modelli a ritmo fisso girano lenti e costosi anche su lavori banali (MiniMax M3: 475 vs 1.684s).
- La lunghezza dell'output è una caratteristica fissa del modello, che varia di quasi 10 volte per lo stesso compito (787 a 7.508 token), incidendo direttamente sul costo.
Cosa sono i sistemi LLM agentici?
Costruire software è iterativo: scrivi codice, lo esegui, leggi gli errori, li correggi, ripeti. I sistemi di IA Agentica consentono agli LLM di seguire questo stesso ciclo. Il modello opera all'interno di un ambiente di sviluppo dove può scrivere file, eseguire comandi, leggere output e apportare modifiche in base a ciò che vede, continuando fino al completamento del compito.
Questo è importante perché le applicazioni reali non sono file singoli. Hanno backend con percorsi e modelli di database, frontend con componenti e chiamate API, file di configurazione, dipendenze e test. Far funzionare tutto questo insieme richiede test e perfezionamento iterativi, che è esattamente ciò che l'architettura agentica consente.
Come funziona
Il modello si trova all'interno di un harness con accesso a una shell, al file system e all'output di esecuzione. Quando gli viene chiesto di costruire un'applicazione, scrive i file incrementalmente. Dopo ogni passo, l'harness mostra al modello cosa è successo: il server è partito, i test sono passati, il linter ha segnalato errori? Basandosi su quel feedback, il modello decide cosa scrivere o correggere dopo.
Questo differisce fondamentalmente dalla generazione a colpo singolo. Nelle configurazioni a colpo singolo, 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 capacità da sola non è sufficiente. Il modello necessita ancora di un forte ragionamento per implementare correttamente la logica di business, ed è qui che emergono realmente le differenze di prestazioni.
Aggiungi come fonte preferitaMetodologia del benchmark agentico degli LLM
Abbiamo utilizzato Opencode come harness agente per tutti i modelli e li abbiamo collegati tramite OpenRouter, con un'eccezione: Claude Fable 5 è stato eseguito sulla CLI Claude Code con l'abbonamento a Claude. 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 attività di sviluppo software (T-1 a T-10), che vanno dai sistemi di prenotazione ai cruscotti interattivi. Queste attività richiedono che gli agenti gestiscano progetti multi-file e forniscano prodotti funzionali. 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 le impostazioni predefinite dell'API, come ogni modello qui; i numeri di lancio di OpenAI per Sol utilizzano modalità a calcolo più elevato.1 Quattro celle Sol Pro e una cella Terra Pro si sono concluse con ripetuti fallimenti silenziosi dello stream API anziché con errori del modello e sono valutate come fallimenti.
Esecuzione e orchestrazione
Ogni agente e compito partono in un ambiente pulito. Le istruzioni sono fornite come file TASK.md, e utilizziamo un watchdog heartbeat di 20 minuti per gli script di lancio. Durante questa fase, registriamo i codici di uscita, il tempo di esecuzione e se i file backend e frontend sono stati creati. Tracciamo anche l'uso di token in tempo reale nelle categorie input, output e cache.
Validazione del backend: Distribuiamo i progetti generati in ambienti isolati per testarli contro un contratto YAML canonico. La validazione copre scenari happy path, 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 percorso diversi, mentre la modalità Strict 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; strict aggiunge una penalità per la deriva del contratto (percorsi rinominati, codici di stato sostituiti, campi di risposta ristrutturati).
Test dell'interfaccia utente e degli scenari utente
Utilizziamo 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 funzioni senza crash.
Il punteggio dell'interfaccia utente divide otto passaggi in due gruppi. I passaggi di infrastruttura (preflight backend, render frontend, modulo di login visibile, invio login, login 2xx, nessun crash runtime) misurano se l'app funziona del tutto. I passaggi di comportamento (segnale di autenticazione post-login, segnale di comportamento post-login) valutano se l'app svolge la sua funzione prevista una volta in esecuzione.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
I passaggi di comportamento bloccati sono esclusi dal denominatore del comportamento, quindi una cella non viene penalizzata due volte quando l'app non riesce a caricarsi.
Calcolo dei token
I conteggi dei token sono estratti dalla risposta dell'LLM API. Sottraiamo i token di input in cache dal totale dei token di input per ottenere l'input effettivo, che riflette solo i token appena elaborati. I token di output non sono mai in 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 di logica a livello di API spesso invalidano qualsiasi successo nel frontend.
Esempio di compito
Compito 6: Sistema di ticket per helpdesk
Il Compito 6 si concentra sullo sviluppo di un complesso ecosistema di assistenza clienti. L'obiettivo principale è costruire una piattaforma che medi la comunicazione tra clienti e agenti di supporto, applicando rigorosamente regole di business e confini di sicurezza. Questo compito valuta la capacità di un agente di gestire macchine a stati multiutente, isolamento dei dati e comunicazione a thread in un ambiente full-stack.
Il compito richiedeva la costruzione di un sistema di helpdesk con:
- Permessi distinti per i Clienti (emissione/risposta) e gli Agenti (gestione/risoluzione).
- Un flusso di lavoro di stato rigido che impedisce transizioni illegali e impone 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 risposta cronologico per un'interazione senza soluzione di continuità tra agente e cliente.
- Un backend FastAPI combinato con un frontend reattivo alimentato da Vite (React/Vue/Svelte).
- Configurazione riproducibile tramite comandi shell specifici per l'attivazione immediata del sistema.
Puoi visualizzare la documentazione del Compito 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{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Benchmark di Coding Agentico}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Consultato il 10 Luglio 2026}
}Risultati e timestamp di 418 punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente 2 file CSV e un README.
Collegamenti di riferimento
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.