Parametro di riferimento di Agentic LLM: confronto tra i 13 migliori LLM.
Abbiamo effettuato un benchmark di 13 modelli LLM su 10 attività di sviluppo software utilizzando uno strumento CLI agentico . Abbiamo eseguito circa 300 passaggi di validazione automatizzati per modello per misurare le prestazioni sia a livello di API che di interfaccia utente.
Risultati del benchmark LLM Agentico
Tasso di successo
Claude 4.5 Sonnet e GPT-5.2 hanno ottenuto i punteggi complessivi più alti con i risultati più coerenti sia nella logica API che nell'integrazione dell'interfaccia utente. Gemini 3.1 Pro Preview e GPT-5.2 Codex si sono classificati al secondo posto, con una logica di backend funzionale ma un output frontend più debole.
Claude Sonnet 4.5
Raggiungendo il più alto tasso di UI tra tutti i modelli testati, Claude Sonnet 4.5 ha prodotto costantemente frontend funzionanti con logica di backend funzionale. Ha implementato con successo operazioni CRUD, convalida dell'input, raccolte di risorse, flussi di lavoro a più fasi e cicli di vita di stato a più stadi. Tuttavia, alcune attività avevano l'autenticazione configurata correttamente ma mancavano la creazione di risorse, l'applicazione dei vincoli o il controllo degli accessi basato sui ruoli negli endpoint specifici del dominio.
Anteprima di Gemini 3.1 Pro
Codice backend tecnicamente preciso, ma infrastruttura fragile. Autenticazione di base e passaggi di elenco superati in alcune attività, ma generalmente falliti in:
- Inizializzazione del frontend
- Validazione rigorosa dello schema
- Vincoli di validazione basati sul tempo
- Transizioni di stato complesse
- Creazione di risorse a cascata
GPT-5.2
La maggior parte delle attività gestite da GPT-5.2 erano caratterizzate da backend funzionali e frontend funzionanti, con ottime prestazioni in operazioni CRUD, convalida dell'input, controllo degli accessi basato sui ruoli e flussi di lavoro a più fasi. Dove invece ha mostrato delle carenze:
- Logica della macchina a stati: implementata l'autenticazione e l'elenco delle risorse, ma saltate le transizioni di stato amministrativo e l'applicazione irreversibile dello stato.
- Applicazione dei ruoli o creazione di risorse vincolate in alcune attività
GPT-5.2 Codex
I flussi di base come la registrazione, l'elenco delle risorse e la gestione delle collezioni sono stati gestiti bene da GPT-5.2 Codex. I suoi principali punti deboli:
- Endpoint di recupero dei dettagli mancanti
- Nessuna transizione di stato amministrativo
- La metà delle sue interfacce utente si è bloccata con errori di runtime (5 su 10)
Rispetto a GPT-5.2, Codex ha generato backend più affidabili ma frontend significativamente meno stabili.
Esempio di registro:
Gemini 3 Pro
Nelle attività più semplici a ruolo singolo, Gemini 3 Pro ha implementato correttamente le operazioni CRUD, la ricerca, l'accesso basato sui ruoli e il recupero dei dati. Le applicazioni multi-ruolo rappresentavano invece il suo punto debole:
- Controllo di integrità e autorizzazione superati, ma fallimento nella creazione delle risorse, nella gestione delle associazioni, nell'applicazione dei ruoli e nei flussi di lavoro amministrativi.
- Ho fallito 13 passaggi su 16 in due attività multiruolo.
- I frontend non sono riusciti a eseguire il rendering in 4 attività
Claude Sonnet 4.6
Con due errori totali del backend e punteggi API bassi nella maggior parte delle attività, Claude Sonnet 4.6 ha mostrato prestazioni incoerenti. Un'eccezione: ha ottenuto un punteggio API di 0,92 in una singola attività con CRUD, autenticazione, applicazione dei ruoli e gestione delle risorse quasi completi (fallendo solo durante la cancellazione). In altre attività, ha generato la struttura di base del progetto e livelli di autenticazione funzionanti, ma ha lasciato incompiuta la logica di business specifica del dominio. Implementazioni mancanti:
- Creazione, elenco e recupero dei dettagli delle risorse
- Transizioni di stato, applicazione dei ruoli, convalida degli input
- Flussi di lavoro del dominio: carrello/pagamento, gestione dei biglietti, appuntamenti, sondaggi, conferma di partecipazione agli eventi, tracciamento delle transazioni
Claude Opus 4.6
Dalla versione 4.6 di Claude Opus sono emersi frontend quasi completi, ma con una logica di backend minima. Ha superato i controlli di integrità, la registrazione e il login, ma in generale ha fallito nelle seguenti fasi:
- Creazione di risorse
- transizioni di stato
- Accesso basato sui ruoli
- Validazione dell'input
- Flussi di lavoro amministrativi
Esempio di registro:
Kimi K2.5
Le implementazioni complete per alcune tipologie di attività contrastano con i backend falliti per altre, suggerendo che Kimi K2.5 gestisce bene le attività CRUD più semplici ma ha difficoltà con applicazioni complesse multi-ruolo o a più fasi.
GLM 4.7
Risultati limitati hanno caratterizzato le prestazioni complessive di GLM 4.7. Le attività con il punteggio più alto avevano frontend caricati parzialmente, ma gli endpoint di autenticazione restituivano codici di stato errati. La maggior parte delle attività presentava codice backend o frontend danneggiato.
Grok 4
Il codice backend minimo derivato da Grok 4 implementava in genere solo endpoint per il controllo dello stato di salute e l'autenticazione. Ha completato un'attività in modo corretto, ma per il resto ha fallito nelle seguenti:
- Elenco dei servizi
- Creazione di risorse
- Operazioni amministrative
- transizioni di stato
Devstral 2 2512
Devstral ha generato una parte della logica di backend, ma in nessuna attività è apparso un codice frontend valido a causa di file mancanti o riferimenti a moduli non funzionanti.
Qwen3 Coder Avanti
Il codice backend che non è stato possibile eseguire ha caratterizzato la maggior parte delle attività tentate da Qwen3 Coder Next. Dove il backend ha iniziato, il frontend ha fallito a causa di punti di ingresso mancanti o componenti danneggiati.
Anteprima grande di Trinity
Trinity Large Preview ha prodotto i punteggi più bassi in assoluto, generando strutture di progetto con errori che impedivano l'esecuzione delle applicazioni. La maggior parte dei backend non disponeva di implementazioni di routing funzionanti e i frontend presentavano componenti mancanti o danneggiati.
Confronto tra costi e successo
Claude Opus 4.6 è stato il modello più costoso per esecuzione, ma si è posizionato a metà classifica, mentre Devstral ha avuto un costo simile a Claude 4.5 Sonnet ma ha ottenuto punteggi significativamente inferiori. GPT-5.2 e GPT-5.2 Codex hanno ottenuto punteggi elevati a un costo relativamente basso.
Token di completamento e tempo di completamento dell'attività
Devstral ha consumato un'elevata quantità di token su tutti i modelli, ma non ha prodotto alcun frontend funzionante, il che significa che gran parte del suo output era costituito da codice non funzionante o ridondante.
Kimi K2.5 e GLM 4.7 hanno registrato le latenze più elevate, impiegando molto più tempo per ogni attività senza un corrispondente miglioramento dei risultati.
Grok-4 si è dimostrato altrettanto lento nonostante la generazione di un numero relativamente basso di token, il che indica lunghe pause tra le generazioni piuttosto che un'elevata produzione. Tra i più veloci, Gemini 3 Pro Preview e GPT-5.2 Codex hanno completato le attività rapidamente con un utilizzo moderato di token, posizionandosi entrambi nella metà superiore della classifica generale.
Prestazioni LLM su un singolo compito completato con successo
Dopo aver condotto il nostro benchmark con 10 attività, abbiamo scoperto che non c'era alcuna attività che tutti gli LLM completassero correttamente e che in molti passaggi fallivano. Pertanto, volevamo vedere come si sarebbero comportati i token e la latenza in un'attività che tutti potevano completare facilmente con successo.
A tal fine, abbiamo progettato un'attività di base minima: una semplice API Notes in memoria con quattro endpoint CRUD, convalida di base e nessuna autenticazione o database. Ogni LLM ha completato questa attività con un tasso di successo del 100%, confermando che tutti i modelli sono in grado di gestire la generazione di API semplici quando la complessità viene eliminata.
Ciò ci ha permesso di confrontare l'utilizzo dei token, il costo e la latenza su una singola attività completata con successo.
Confronto tra costi e righe di codice
Nel benchmark completo, Claude 4.5 Sonnet è risultato il modello con il punteggio più alto, con un costo medio di 0,29 dollari per attività; qui ha completato il benchmark di base con un costo di soli 0,012 dollari, eguagliando i modelli più economici.
Qwen3 Coder ($0,012) e Trinity (gratuito), che si sono classificati rispettivamente ultimo e penultimo nel benchmark completo, hanno offerto prezzi competitivi rispetto ai modelli Sonnet con il punteggio più alto. Ciò significa che, in un'attività che tutti possono completare, il divario di costo tra i migliori e i peggiori si riduce notevolmente, ad eccezione di Opus che rimane costoso indipendentemente dalla difficoltà dell'attività.
Gemini 3.1 Pro Preview, al prezzo di $0,016, ha dimostrato un'efficienza in termini di costi per questo compito di base, sebbene il suo costo fosse leggermente superiore a quello dei modelli più economici. Ciò lo ha posizionato in modo competitivo tra i prodotti di fascia media, mostrando una ragionevole efficienza in termini di costi quando la complessità del compito si riduce.
Devstral 2 2512 ha mostrato la riduzione di costo più drastica, passando da 0,31 dollari per attività a 0,021 dollari. Dato che ha ottenuto solo 0,07 nel benchmark completo, questo rivela un aspetto importante della determinazione dei prezzi nei modelli LLM : i costi elevati non sempre riflettono tariffe per token elevate, ma possono derivare da ripetuti tentativi falliti piuttosto che dalla struttura di prezzo di base del modello.
Claude Opus 4.6 è rimasto il più costoso a $0,086, in linea con la sua media di $1,17 nell'intero benchmark, confermando che il suo prezzo per token lo rende costoso a prescindere dalla difficoltà del compito.
Grok-4 ha prodotto il minor numero di righe di codice, in linea con il suo basso utilizzo di token nel benchmark completo. GPT-5.2 Codex e GPT-5.2 hanno avuto costi simili, ma GPT-5.2 è stato più veloce ed efficiente. Ciò rispecchia il benchmark completo in cui GPT-5.2 ha ottenuto un punteggio più alto allo stesso costo, dimostrando che raggiunge le soluzioni in modo più diretto.
Confronto tra token di completamento e completamento delle attività
Kimi K2.5 ha impiegato 135 secondi per un'attività che la maggior parte dei modelli ha completato in meno di 30 secondi, confermando che l'elevata latenza osservata nel benchmark completo è un limite a livello di modello, non dovuto alla complessità dell'attività.
GLM 4.7, il modello più lento del benchmark completo, ha completato questo compito in 24 secondi, una riduzione di 25 volte, il che suggerisce che la sua latenza aumenta con la difficoltà.
Qwen3 Coder è stato il più veloce con 10 secondi nonostante si sia classificato ultimo nel benchmark completo. GPT-5.2 ha utilizzato meno token di GPT-5.2 Codex e ha terminato più velocemente, in linea con il benchmark completo in cui GPT-5.2 ha ottenuto un punteggio più alto pur essendo più conciso.
Che cosa sono i sistemi LLM agentici?
Lo sviluppo di software è un processo iterativo: scrivere il codice, eseguirlo, leggere gli errori, correggerli e ripetere. I sistemi di intelligenza artificiale agentica consentono ai modelli lineari di apprendimento (LLM) di seguire lo stesso ciclo. Il modello opera all'interno di un ambiente di sviluppo in cui può scrivere file, eseguire comandi, leggere gli output e apportare modifiche in base a ciò che osserva, continuando fino al completamento dell'attività.
Questo è importante perché le applicazioni reali non sono costituite da singoli file. Hanno backend con percorsi e modelli di database, frontend con componenti e chiamate API, file di configurazione, dipendenze e test. Far funzionare insieme questi elementi richiede test e perfezionamenti iterativi, che è esattamente ciò che l'architettura agentica consente.
Come funziona
Il modello risiede all'interno di un sistema di controllo che gli consente di accedere a una shell, al file system e all'output di esecuzione. Quando gli viene richiesto di compilare un'applicazione, scrive i file in modo incrementale. Dopo ogni passaggio, il sistema di controllo mostra al modello cosa è successo: il server si è avviato? I test sono stati superati? Il linter ha rilevato errori? In base a questo feedback, il modello decide cosa scrivere o correggere successivamente.
Questo si differenzia fondamentalmente dalla generazione a singolo tentativo. Nelle configurazioni a singolo tentativo, il modello genera un intero codebase alla cieca, senza alcun modo di verificarne il funzionamento. Nei sistemi LLM agentici, il modello osserva le conseguenze di ogni azione e corregge la rotta. Tuttavia, questa capacità da sola non è sufficiente. Il modello necessita comunque di un solido ragionamento per implementare correttamente la logica di business, ed è qui che emergono le reali differenze di prestazioni.
Metodologia di benchmarking LLM per agenti
Abbiamo utilizzato Aider per tutti gli agenti e ci siamo connessi ai modelli tramite OpenRouter. Abbiamo valutato la loro capacità di lavorare in autonomia su 10 attività di sviluppo software (da T-1 a T-10) che spaziavano da semplici sistemi di prenotazione a complesse dashboard interattive. Queste attività richiedevano agli agenti di gestire progetti multi-file e di fornire prodotti funzionanti.
Esecuzione e orchestrazione
Ogni agente e ogni attività inizia in un ambiente pulito. Le istruzioni sono fornite in un 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 di backend e frontend sono stati creati. Monitoriamo inoltre l'utilizzo dei token in tempo reale per le categorie di input, output e cache.
Validazione del backend : Distribuiamo i progetti generati in ambienti isolati per testarli rispetto a un contratto YAML canonico. La validazione copre scenari di funzionamento ottimali, gestione degli errori (400/403/409) e coerenza dei dati.
Verifichiamo i risultati in due modalità:
La modalità adattiva convalida la funzionalità anche con nomi di percorso diversi, mentre la modalità rigorosa richiede l'esatta osservanza del contratto.
Il punteggio complessivo del backend viene calcolato come segue: backend_overall = (attività_pronte / attività_totali) × Media (tassi di successo adattivi + rigorosi)
Test dell'interfaccia utente e degli scenari utente
Utilizziamo l'automazione del browser per simulare flussi utente reali, inclusi i controlli preliminari, il rendering e l'autenticazione. Verifichiamo passaggi funzionali come l'invio del login e il comportamento successivo al login per garantire che l'applicazione funzioni senza arresti anomali.
Le prestazioni dell'interfaccia utente vengono misurate in base alla percentuale di superamento dei passaggi: percentuale_di_superamento_dei_passaggi = superati / (superati + falliti + bloccati)
Calcolo dei token
Il numero di token viene estratto dalla risposta dell'API LLM. Sottraiamo i token di input memorizzati nella cache dal totale dei token di input per ottenere l'input effettivo, che riflette solo i token elaborati di recente. I token di output non vengono mai memorizzati nella cache, quindi rimangono invariati.
Aggregazione finale
Il punteggio finale del benchmark viene calcolato combinando i risultati delle fasi precedenti: Punteggio finale = (0,7 × backend_overall) + (0,3 × ui_overall) Assegniamo un peso maggiore al backend perché i guasti logici a livello di API spesso invalidano qualsiasi successo nel frontend.
Esempio di attività
Attività 6: Sistema di ticket di assistenza
Il compito 6 si concentra sullo sviluppo di un complesso ecosistema di assistenza clienti. L'obiettivo principale è costruire una piattaforma che funga da intermediario per la comunicazione tra clienti e addetti all'assistenza, garantendo al contempo il rigoroso rispetto delle regole aziendali e dei limiti di sicurezza. Questo compito valuta la capacità di un agente di gestire macchine a stati multiutente, isolamento dei dati e comunicazione multithread all'interno di un ambiente full-stack.
Il compito richiedeva la creazione di un sistema di help desk dotato delle seguenti caratteristiche:
- Autorizzazioni distinte per i Clienti (emissione/risposta) e per 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 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 responsivo basato su Vite (React/Vue/Svelte).
- Configurazione riproducibile tramite specifici comandi shell per l'attivazione immediata del sistema.
È possibile consultare la documentazione relativa all'Attività 6 su GitHub .
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.