A-CODE-LLM Bench: Benchmark di codifica agentic
Abbiamo confrontato i migliori modelli linguistici di grandi dimensioni (LLMs) su 10 attività di sviluppo software utilizzando uno strumento CLI agentic. Abbiamo eseguito ~3.500 passaggi di convalida automatizzata per modello attraverso entrambi i livelli API e UI.
A-CODE-LLM Risultati del benchmark
Ogni alias è stato eseguito 3 volte su 10 attività (30 campioni per alias, 300 celle per iterazione). Per maggiori dettagli consultare la metodologia.
- Sonnet ottiene punteggi più alti di Opus nella codifica agentic. Sonnet 5 (0.772) e Sonnet 4.6 (0.748) superano tutte le varianti di Opus, inclusa Opus 4.8 (0.702). Il miglior modello di codifica di Anthropic è il mid-tier Sonnet, non l'ammiraglia Opus.
- Il vantaggio di Sonnet 5 cresce con la lunghezza del task. È in cima al benchmark di build su 10 task con il backend più alto di qualsiasi modello (0.701) e 125 chiamate strumento, ma sul baseline banale usa solo 9 chiamate. Il vantaggio emerge su build lunghe e autonome, non su task brevi.
- I punteggi frontend si concentrano in alto, quindi il backend determina la classifica. I primi otto ottengono tutti punteggi tra 0.79 e 0.96 nel frontend. Claude Haiku 4.5 ha un frontend funzionante (0.731) ma un backend di 0.277, limitandolo a 0.413; GPT 5.5 thinking ha un backend forte (0.620) ma un frontend di 0.542.
- Il livello del modello non predice la capacità di codifica. Il mid-tier Sonnet supera l'ammiraglia Opus in ogni variante, quindi ottimizzare un modello per il lavoro agentic conta più della sua dimensione o fascia di prezzo.
- La logica backend è la parte difficile per gli attuali LLM, non l'interfaccia. Tra i leader, il frontend è quasi risolto (primi otto tra 0.79 e 0.96) e la classifica è decisa quasi interamente dal backend, dove i punteggi vanno da 0.70 fino a 0.23.
Confronto costi e successo
- Costo e punteggio non sono correlati. Il modello più costoso, Opus 4.7 a $3.08 per cella, totalizza 0.610, sotto Sonnet 4.6 a $1.33. Spendere di più non aumenta il punteggio.
- Sonnet 4.6 costa meno di Sonnet 5 per un punteggio quasi identico: 0.748 a $1.33 contro 0.772 a $2.23. I 0.024 extra costano $0.90 in più per cella.
- Ogni variante Opus costa più di Sonnet per un punteggio inferiore o uguale.
- Miglior rapporto qualità-prezzo: Kimi K2.7 Code è il modello più economico sopra 0.60 a $0.70. Gemini 3.5 Flash thinking totalizza 0.625 a $1.30, eguagliando il prezzo di Sonnet superando ogni Opus.
- Il prezzo non è un indicatore di qualità per la codifica agentic. Il costo riflette il posizionamento del fornitore, non il punteggio che un modello ottiene in questo benchmark; un prezzo più alto non indica un modello agentic migliore.
Tempo di completamento task e confronto del successo
- Tempo di completamento e punteggio non sono correlati. Il modello più veloce, Grok 4 span>.3 a 142 secondi, totalizza 0.431; il più lento, Qwen 3.6 Plus a 1.948 secondi, totalizza 0.333.
- Sonnet 5 è il più lento tra i primi sei. A 1.763 secondi impiega circa 3x il tempo di Sonnet 4.6 (612 secondi) per 0.024 in più.
- Sonnet 4.6 è il più veloce tra i punteggi alti, raggiungendo 0.748 in un terzo del tempo di Sonnet 5.
- Le esecuzioni oltre 1.600 secondi sono dovute a eccesso di iterazioni, non a task più difficili: MiniMax M3, entrambe le varianti di Qwen, GLM 5.1 base e Deepseek V4 Pro hanno tutti totalizzato meno di 0.55.
- Due cause indipendenti determinano la durata dell'esecuzione. All'interno di un modello, esecuzioni più lunghe possono significare iterazioni più profonde che aumentano il punteggio (Sonnet 5). Tra i modelli, le esecuzioni più lunghe derivano da un'eccessiva iterazione improduttiva (tutti i modelli sopra 1.600 secondi hanno totalizzato meno di 0.55). Il solo tempo non può distinguere i due casi.
Chiamate strumento per task
- Il conteggio delle chiamate strumento è un'impronta comportamentale, non una misura di capacità, e non è confrontabile tra diversi harness. L'OpenAI di
apply_patchcomprime una modifica dell'intero file in una sola chiamata, quindi i suoi conteggi bassi riflettono la progettazione dello strumento, non un minor lavoro. - Il conteggio delle chiamate non predice il punteggio. I conteggi vanno da 18 (Grok 4.3) a 125 (Sonnet 5), senza alcuna correlazione tra conteggio e punteggio.
- Sonnet 5 effettua il maggior numero di chiamate di ogni modello (125) e totalizza il punteggio più alto; Sonnet 4.6 raggiunge quasi lo stesso punteggio con circa 50. Entrambi funzionano, agli estremi opposti della gamma.
- MiniMax M3 ha effettuato 108 chiamate per un 0.583 medio, quindi un conteggio alto da solo non aiuta.
Prestazioni LLM su un singolo task riuscito
Nessun modello ha superato ogni passaggio del benchmark completo di cui sopra. Per confrontare costi e velocità a parità di condizioni, abbiamo eseguito un semplice task baseline che ogni modello può completare: quattro endpoint CRUD, validazione di base, nessuna autenticazione e nessun database.
Confronto costi e righe di codice
- I task banali non distinguono i modelli, ed è questo il motivo principale per cui esiste il benchmark completo. Sul baseline, costo, lunghezza del codice e tasso di successo convergono: ogni modello lo completa, le righe si raggruppano tra 40 e 64 e il costo scende a centesimi. Le differenze tra i modelli compaiono solo su lavori agentic lunghi e multi-file.
- La lunghezza del codice non è una caratteristica del modello nei task semplici (40 a 64 righe), tranne per un sovra-generatore, Gemini 3.5 Flash base, che ha prodotto 131 righe diventando il baseline più costoso.
- Sonnet 5 adatta lo sforzo al task: 9 chiamate, 46 righe, $0.09 sul baseline contro 125 chiamate sul benchmark completo. Sonnet 4.6 ha eseguito il baseline a circa il 15% del suo costo per cella sul benchmark completo ($0.20 base, $0.15 thinking). Anche Opus 4.8 ha ridotto a $0.16 e 6 chiamate. Consulta l'articolo LLM Pricing per le tariffe per token.
Tempo di completamento e utilizzo dei token
- I modelli si dividono in due tipi di andatura. I modelli adattivi scalano lo sforzo in base alla difficoltà (Opus 4.8: 34 secondi sul baseline, 1.072 sul benchmark); i modelli a ritmo fisso rimangono lenti a prescindere (MiniMax M3: 475 contro 1.684).
- L'output per lo stesso task varia di 8x, da 787 token (Qwen 3.6 Plus thinking) a 6.643 (GPT 5.4 Mini), quindi la verbosità è una disposizione stabile del modello, non un effetto del task.
Cosa sono i sistemi LLM agentic?
Costruire software è iterativo: scrivi codice, lo esegui, leggi gli errori, li correggi, ripeti. I sistemi di IA agentic permettono 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, proseguendo fino al completamento del task.
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. Farli funzionare insieme richiede test e perfezionamenti iterativi, esattamente ciò che l'architettura agentic consente.
Aggiungi come fonte preferitaCome funziona
Il modello risiede 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 file in modo incrementale. Dopo ogni passaggio, l'harness mostra al modello cosa è successo: il server si è avviato? I test sono passati? Il linter ha segnalato errori? Sulla base di questo feedback, il modello decide cosa scrivere o correggere successivamente.
Questo differisce fondamentalmente dalla generazione in un unico colpo. Nelle configurazioni one-shot, il modello genera un'intera base di codice alla cieca, senza alcun modo di verificare se funzioni. Nei sistemi LLM agentic, il modello vede le conseguenze di ogni azione e corregge la rotta. Tuttavia, questa capacità da sola non è sufficiente. Il modello ha ancora bisogno di un forte ragionamento per implementare correttamente la logica di business, ed è qui che emergono realmente le differenze di prestazioni.
Metodologia del benchmark LLM agentic
Abbiamo utilizzato Opencode come harness agente per tutti i modelli e li abbiamo connessi tramite OpenRouter, con un'eccezione: Claude Fable 5 ha funzionato su Claude Code CLI con l'abbonamento 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 dashboard interattivi. Questi task richiedono agli agenti di gestire progetti multi-file e consegnare prodotti funzionali.
Esecuzione e orchestrazione
Ogni agente e task parte in un ambiente pulito. Le istruzioni vengono 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 dei token in tempo reale nelle categorie input, output e cached.
Validazione backend: Distribuiamo i progetti generati in ambienti isolati per testarli rispetto a 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 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. La modalità adattiva ha un peso maggiore perché misura la correttezza comportamentale; la modalità strict aggiunge una penalità per la deriva dal contratto (percorsi rinominati, codici di stato sostituiti, campi di risposta ristrutturati).
Test UI e 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 UI suddivide otto passaggi in due gruppi. I passaggi infrastrutturali (preflight backend, rendering frontend, modulo di login visibile, invio login, login 2xx, nessun crash runtime) misurano se l'app viene eseguita. I passaggi comportamentali (segnale di autenticazione post-login, segnale di comportamento post-login) valutano se l'app svolge 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 comportamentale, quindi una cella non viene penalizzata due volte quando l'app non si carica.
Calcolo dei token
I conteggi dei token vengono estratti dalla risposta dell'LLM API. Sottraiamo i token di input memorizzati nella cache dai token di input totali per ottenere l'input effettivo, che riflette solo i token appena elaborati. I token di output non sono 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 ticket helpdesk
Il Task 6 si concentra sullo sviluppo di un ecosistema complesso di supporto clienti. L'obiettivo primario è costruire una piattaforma che medii la comunicazione tra clienti e agenti di supporto, applicando rigorosamente regole aziendali e confini di sicurezza. Questo task valuta la capacità di un agente di gestire macchine a stati multi-utente, isolamento dei dati e comunicazione threadizzata in un ambiente full-stack.
Il task richiedeva la costruzione di un sistema helpdesk con:
- Permessi distinti per Clienti (emissione/risposta) e Agenti (gestione/risoluzione).
- Un workflow di stato 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 anziché 403 per proteggere l'integrità del sistema.
- Un sistema di risposta cronologico per un'interazione fluida tra agente 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{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Benchmark di codifica agentic}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Consultato il 2 Luglio 2026}
}Risultati e timestamp di 341 punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente 2 file CSV e un README.
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.