A-CODE-LLM Bench: Benchmark di Codifica Agentica

Abbiamo confrontato i migliori Large Language Models (LLMs) su 10 attività di sviluppo software utilizzando uno strumento CLI agentico. Abbiamo eseguito circa 3.500 fasi di validazione automatizzata per modello su entrambi i livelli API e UI.

Risultati del benchmark A-CODE-LLM

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 il flagship Opus. Entrambe le versioni di Sonnet superano ogni Opus, incluso Opus 4.8 (0,702). Il livello più costoso di Anthropic non è il suo miglior programmatore.
• La vetta non è più solo Anthropic: Grok 4.5 (0,732) batte ogni variante di 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 maggiore calcolo si posizionano per lo più sotto le proprie versioni base (Sol Pro 0,543, Terra Pro 0,568; solo Luna Pro migliora, 0,603 vs 0,579).
• Gli specialisti del 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 di OpenAI, GPT 5.4 Mini (0,594). Kimi K2.7 Code di Moonshot è lo specialista più forte con 0,611.
• Kimi K3, un modello generale, conquista la leadership open-weights superando lo specialista del codice di Moonshot: 0,725, sesto in assoluto, 0,114 sopra K2.7 Code. Il suo backend da 0,632 si classifica quinto, sopra ogni alias di Opus e GPT.
• Inkling, il primo modello di Thinking Machines, debutta a 0,575, terzo tra i modelli open-weights. Il suo frontend da 0,747 batte ogni alias di GPT 5.6; il backend da 0,501 limita la sua classifica.
• Nessun modello è affidabile sul backend: il tetto massimo è 0,701 (Sonnet 5), quindi anche il vincitore fallisce circa un terzo dei controlli di logica di business e contratto. 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, ed è ciò che determina la classifica. Claude Haiku 4.5 renderizza bene (0,731), ma un backend da 0,277 lo limita 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 sul frontend; la famiglia GPT 5.6 alza quel valore a 0,63-0,71, ancora molto sotto la soglia di 0,91 e oltre della linea Sonnet.

Confronto costi e 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 sovrapprezzo per un guadagno minimo: Sonnet 5 ottiene 0,024 sopra Sonnet 4.6 con un costo per cella superiore del 70%.
• Grok 4.5 è il nuovo miglior rapporto qualità-prezzo: 0,732, entro 0,040 dal vincitore, a $0,46 per cella, contro i $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 ottiene il suo sesto posto a un prezzo di fascia media: $1,47 per cella, vicino ai $1,33 di Sonnet 4.6 ma con 0,007 in più nel punteggio, e ben sotto i $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 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 offre quasi lo stesso punteggio in un terzo del tempo.
• Un'esecuzione lunga di solito segnala un modello bloccato, non meticoloso: i peggiori per punteggio, entrambe le varianti Qwen, GLM 5.1 base e Deepseek V4 Pro, hanno ciascuno superato i 1.700 secondi per eccesso di iterazioni, con punteggi sotto 0,45.
• Grok 4.3 è stato veloce perché ha abbandonato presto: 142 secondi e 18 chiamate strumento per 0,431. Grok 4.5 mantiene la velocità e smette di abbandonare: circa 9 minuti per attività, meno di un terzo del tempo di Sonnet 5, per 0,732.
• Kimi K3 si trova all'angolo opposto: punteggio di vertice, velocità peggiore. Ha una media di circa 55 minuti per attività, il più lento in campo e circa il doppio di Sonnet 5, per un sesto posto con 0,725. La sua accuratezza è reale, ma è il modo meno pratico per entrare nella fascia alta.

Chiamate strumento per attività

• Il numero di chiamate strumento non misura né la capacità né lo sforzo confrontabile. Sonnet 5 ha effettuato il maggior numero di chiamate (125) e ha ottenuto il punteggio più alto; MiniMax M3 ne ha effettuate 108 per un 0,583 a metà classifica; Grok 4.5 ha raggiunto 0,732 con 40; il basso numero di OpenAI, da 16 a 36, deriva da 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 loro versioni base e ottengono meno: 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), distanti 0,024.

Prestazioni degli LLM su un singolo task riuscito

Nessun modello ha superato ogni fase del benchmark completo sopra descritto. Per confrontare costi e velocità a parità di condizioni, abbiamo eseguito un semplice task di base che ogni modello può completare: quattro endpoint CRUD, validazione di base, nessuna autenticazione e nessun database.

Confronto costi e linee di codice

• I task semplici non possono classificare i modelli, quindi le valutazioni giocattolo traggono in inganno. Sul task di base che ogni modello supera, il codice converge a 40-64 linee, e il costo scende a centesimi; le differenze emergono solo su lavori lunghi e multi-file.
• Il livello "veloce e leggero" è stato il più costoso qui: Gemini 3.5 Flash base ha scritto 131 linee per il task banale, da due a tre volte il resto, rendendolo il più costoso sul task di base, contro il suo stesso posizionamento.
• L'iterazione pesante di Sonnet 5 è guidata dal task, non è un'abitudine: 9 chiamate e $0,09 qui contro 125 chiamate sul benchmark.

Vedi maggiori dettagli nell'articolo sui Prezzi degli LLM.

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 ritmo 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 una variazione di quasi 10x per lo stesso task (da 787 a 7.508 token), alimentando direttamente il 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 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 task.

Questo è importante perché le applicazioni reali non sono file singoli. Hanno backend con route e modelli di database, frontend con componenti e chiamate API, file di configurazione, dipendenze e test. Far funzionare tutto questo insieme richiede test e perfezionamenti 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 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? In base a quel feedback, il modello decide cosa scrivere o correggere successivamente.

Questo differisce fondamentalmente dalla generazione a colpo singolo. 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 capacità da sola non è sufficiente. Il modello ha ancora bisogno di un forte ragionamento per implementare correttamente la logica di business, che è dove emergono realmente le differenze di prestazione.

Scopri altri nostri benchmark e approfondimenti basati sui dati nella Ricerca Google.

Aggiungi come fonte preferita

Metodologia del benchmark degli LLM agentici

Abbiamo utilizzato Opencode come harness agente per tutti i modelli e li abbiamo connessi tramite OpenRouter, con due eccezioni: Claude Fable 5 è stato eseguito sulla CLI di Claude Code con l'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 attività di sviluppo software (da T-1 a T-10), che spaziano dai sistemi di prenotazione ai cruscotti interattivi. Queste attività richiedono agli agenti di gestire progetti multi-file e fornire 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 impostazioni predefinite API, come ogni modello qui presente; i numeri di lancio di OpenAI per Sol utilizzano modalità a calcolo più elevato.¹ Quattro celle di Sol Pro e una cella di Terra Pro si sono concluse con ripetuti fallimenti silenziosi dello stream API anziché errori del modello e sono state conteggiate come fallimenti.

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 dei costi di Inkling utilizza i prezzi di listino di Thinking Machines di $3,74 per milione di token in input e $9,36 per milione di token in output; il fornitore ha fatturato circa la metà in virtù di uno sconto di lancio a tempo limitato.² Entrambi i modelli sono stati eseguiti con un limite di 150 minuti per cella invece dei precedenti 45 minuti, perché il flusso di token di Kimi K3 è abbastanza lento da raggiungere il limite più breve durante la compilazione; il tempo di completamento è riportato separatamente nel grafico temporale. La capacità upstream condivisa di Kimi K3 ha restituito frequenti errori di limite di velocità e timeout durante la finestra di esecuzione; le celle interessate sono state rieseguite una volta con lo stesso limite, la stessa politica applicata ai fallimenti dello stream di Sol Pro e Terra Pro di cui sopra.

Esecuzione e orchestrazione

Ogni agente e attività inizia 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'utilizzo dei token in tempo reale nelle categorie input, output e cache.

Validazione backend: Distribuiamo i progetti generati in ambienti isolati per testarli rispetto a 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 route diversi, mentre la modalità Strict richiede l'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; lo Strict aggiunge una penalità per la deriva dal contratto (route rinominate, 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 divide otto passaggi in due gruppi. I passaggi infrastrutturali (preflight backend, render frontend, modulo di login visibile, invio login, login 2xx, nessun crash runtime) misurano se l'app funziona. I passaggi comportamentali (segnale di autenticazione post-login, segnale di comportamento post-login) valutano se l'app esegue la sua 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 doppiamente penalizzata quando l'app non riesce a caricarsi.

Calcolo dei token

Il conteggio dei token viene estratto dalla risposta API dell'LLM. Sottraiamo i token di input in cache dai token di input totali per ottenere l'input effettivo, che riflette solo i token appena elaborati. I token di output non vengono mai messi in cache, quindi rimangono invariati.

Aggregazione finale

Il punteggio finale del benchmark viene 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 assistenza clienti. L'obiettivo principale è costruire una piattaforma che medii la comunicazione tra clienti e agenti 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 threaded in un ambiente full-stack.

Il task richiedeva la costruzione di un sistema helpdesk con le seguenti caratteristiche:

• Permessi distinti per Clienti (emissione/risposta) e Agenti (gestione/risoluzione).
• Un flusso di lavoro a 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 risposta cronologica per un'interazione fluida agente-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  = jul,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Consultato il 23 Luglio 2026}
}

Collegamenti di riferimento

1.

GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI

2.

Inkling: Our Open-Weights Model - Thinking Machines Lab

Berk Kalelioğlu

Ricercatore AI

Segui

Berk è un Ricercatore AI presso AIMultiple, concentrandosi su sistemi di IA agentica e modelli linguistici.

Visualizza il profilo completo

Revisionato tecnicamente da

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre 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 zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

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.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento