AIM-Code Bench: benchmark di codifica agentica

Valutare gli LLM senza i loro harness di coding agent non riflette pienamente come vengono utilizzati nella pratica. Lo sviluppo reale comporta anche estendere il lavoro esistente, prendere in carico codice non familiare e lasciare implementazioni su cui altri possano costruire. Introduciamo AIM-Code Bench per valutare i modelli insieme ai loro harness di coding agent in attività software in evoluzione. Oltre alla correttezza, il benchmark misura le prestazioni a runtime, l'adattamento ai requisiti che cambiano e i risultati quando gli agenti costruiscono sul codice l'uno dell'altro.

Risultati

Fable 5.1 ha registrato la latenza osservata più bassa nelle fasi 1 e 2; Opus 5 ha guidato le fasi 3 e 4.

La tabella mostra la latenza p95 (il 95 percentile) in millisecondi; più bassa è meglio. Ogni valore è la mediana di dieci misurazioni replay del programma salvato. Le classifiche utilizzano la piena precisione all'interno di ciascuna fase. Le stesse misurazioni della fase 4 fungono da controlli sul proprio codice nel confronto di consegna. Classifiche numeriche vicine non indicano necessariamente prestazioni distinguibili.

Parte 1: sviluppare e migliorare le proprie implementazioni

Ogni agente ha mantenuto il proprio codice e la conversazione tra le fasi. Abbiamo aggiornato la specifica del compito man mano che arrivavano nuovi requisiti e abbiamo concesso fino a 20 minuti per ogni fase. I prompt descrivevano un normale lavoro di sviluppo e chiedevano agli agenti di puntare alle migliori prestazioni possibili preservando il comportamento richiesto.

L'esperimento ha coperto tredici configurazioni modello-prodotto: quattro in Claude Code, tre in Codex, quattro in OpenCode, una in Grok Build e una in Devin CLI. L'impegno era medio dove supportato, alto per Kimi K3 e GLM 5.3, e il valore predefinito del provider per MiniMax M3. Ogni risultato appartiene quindi al modello e al prodotto di coding insieme.

Abbiamo cercato di riflettere il più fedelmente possibile il modo in cui le persone usano realmente i prodotti di coding IA negli scenari reali. Molte persone usano i modelli all'interno dei propri harness; pertanto, mentre abbiamo utilizzato i modelli disponibili nei rispettivi harness, abbiamo usato modelli open-weight tramite opencode.

Le quattro fasi del progetto

Le fasi 1–3 hanno utilizzato 5.000 operazioni per batch. La fase 4 ha utilizzato richieste HTTP indipendenti con 1.000 operazioni ciascuna, con una CPU e 128 MiB di memoria allocati al servizio candidato.

La latenza batch misurata di MiniMax M3 è passata da 37.833 ms nella fase iniziale a 12.254 ms nella fase di capacità. Si tratta di una riduzione osservata del 67,6% man mano che l'implementazione cambiava e l'evizione diventava un requisito. La sua implementazione HTTP originale della fase 4 si è in seguito classificata 4, a 3.009 ms.

La latenza batch misurata di Qwen 3.8 Max è passata da 11.638 a 8.023 ms tra le prime due fasi, una riduzione osservata del 31,1%. Il suo risultato nella fase 3 si è classificato 4. Queste traiettorie mostrano perché un singolo risultato iniziale non coglie i cambiamenti che emergono quando un agente continua a sviluppare un progetto.

Queste percentuali descrivono le traiettorie registrate, non miglioramenti di ottimizzazione controllati. Ogni fase modifica il comportamento o il carico di lavoro richiesto. In particolare, la latenza della fase 4 non può essere sottratta dalla latenza della fase 3: l'interfaccia e le operazioni per richiesta sono diverse. Un'affermazione diretta di ottimizzazione prima/dopo richiederebbe di rieseguire entrambe le versioni sotto lo stesso carico di lavoro applicabile.

Quanto codice è cambiato lungo il percorso?

Le quattro fasi comprendono 52 diff verificati delle fasi originali nelle tredici configurazioni. La fase 4 illustra la variazione nella dimensione dell'implementazione e nello stile di modifica:

Questi conteggi includono test e strumenti sorgente scritti dagli agenti, commenti e righe vuote; gli aggiornamenti di attività/test forniti e la diagnostica JSON sono esclusi. Misurano la differenza finale rispetto allo snapshot iniziale di ciascuna fase. Modifiche più grandi possono includere test o ottimizzazioni utili; modifiche più piccole non sono automaticamente migliori. Il report dei diff collegato contiene le modifiche sorgente per ciascuna fase.

Parte 2: subentrare nell'implementazione di un altro agente

Dopo aver misurato le traiettorie originali, ci siamo posti due domande diverse: quale codice fornisce agli altri agenti un utile punto di partenza, e quale agente ottiene le migliori prestazioni quando estende il codice di qualcun altro?

Siamo partiti dalle implementazioni salvate della fase 3 e abbiamo chiesto ai destinatari di eseguire la fase 4. Ognuna delle tredici configurazioni ha ricevuto il codice delle altre dodici configurazioni, generando 156 coppie ordinate donatore–destinatario. Non ci sono stati nuovi subentri su se stessi. Ogni destinatario ha avviato una sessione isolata fresca con il codice del donatore e gli stessi requisiti della fase 4; non poteva vedere l'harness o le sessioni degli altri agenti.

Le consegne originali della fase 4 fungono da controlli sul proprio codice, usando le stesse misurazioni della Parte 1. Quei controlli erano stati sviluppati con la cronologia di conversazione originale, mentre i subentri iniziavano da zero. Il confronto combina quindi gli effetti del codice di partenza e della conversazione. Questa transizione chiede ai successori di estendere una cache esistente in un servizio HTTP ottimizzando la latenza delle richieste.

Vista A: beneficio fornito dal codice di un donatore

Per ogni coppia, confrontiamo la latenza HTTP del successore con la latenza originale della fase 4 dello stesso successore:

successor benefit = (recipient own latency − inherited-code latency) / recipient own latency

Il punteggio di un donatore è la mediana di questi dodici benefici percentuali. Un valore positivo significa che i suoi successori hanno tipicamente ottenuto una latenza inferiore rispetto alle proprie continuazioni originali. Questa è una visione basata sulle prestazioni dell'utilità di un'implementazione di partenza; non misura direttamente la qualità della documentazione o la facilità di comprensione.

Opus 5 ha fornito il più grande beneficio mediano per i successori, con +17,30%, seguito da Opus 5.5 con +15,70% e Fable 5.1 con +11,34%. Questi esiti possono riflettere sia le prestazioni dell'implementazione ereditata, sia la facilità con cui i successori hanno potuto estenderla. Le percentuali normalizzano la scala, ma non eliminano le differenze di qualità iniziale o di margine di ottimizzazione.

Vista B: prestazioni come successore

Per ogni donatore, calcoliamo la latenza mediana ottenuta dai suoi dodici destinatari. Ogni destinatario di quel donatore viene quindi confrontato con questo riferimento condiviso:

successor advantage = (same-donor median latency − recipient latency) / same-donor median latency

Il punteggio del destinatario è il suo vantaggio mediano tra dodici donatori. Un valore positivo significa che è stato tipicamente più veloce del destinatario mediano dello stesso codice di partenza. Questo evita di premiare un destinatario semplicemente perché la sua implementazione originale era lenta.

GPT-6 Astra ha guidato questa sintesi esplorativa sui successori con +2,68%, seguito da Opus 5 con +2,33% e Grok 4.6 con +0,88%. Il vantaggio di Astra su Opus 5 non era distinguibile entro l'incertezza misurata. Essere il donatore più forte ed essere il successore più forte sono esiti diversi in questo esperimento.

I successori hanno costruito sul sorgente ereditato?

Riportiamo il churn del sorgente separatamente dalle prestazioni: (added lines + deleted lines) / inherited source lines. Contiamo anche i subentri che eliminano più del 50% del sorgente ereditato. Si tratta di un tasso di grande eliminazione, non della prova di una riscrittura da zero: ridenominazioni, riformattazione e rimozione di codice ausiliario possono superare la soglia.

Nessuno dei successori selezionati ha eliminato più della metà del sorgente ereditato totale da GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, Claude Opus 5.5 o Qwen 3.8 Max. Tutti e dodici hanno superato tale soglia per Kimi K3, GPT-5.6 Luna, MiniMax M3 e Claude Sonnet 5. Si tratta di osservazioni relative alle modifiche delle righe fisiche, non di una classifica di manutenibilità. I programmi dei donatori contenevano solo 75–668 righe sorgente includendo il codice ausiliario, e la scelta di includere test/strumenti influisce sulle percentuali di eliminazione.

Metodo di misurazione, nuovi tentativi e ambito

Ogni punteggio di prestazione riportato utilizza dieci riesecuzioni dello stesso programma salvato. Le fasi 1–3 hanno utilizzato 40 batch misurati per riesecuzione. La fase 4 e la misurazione temporale dei subentri hanno utilizzato 1.200 richieste HTTP per riesecuzione a 20 richieste al secondo per 60 secondi, con una CPU, 128 MiB di memoria e un limite di 64 processi/thread per ciascun candidato.

Abbiamo misurato i programmi in serie su un server Linux dedicato Intel i7-7700. Il driver e il candidato giravano su core fisici separati con thread fratelli inutilizzati, una politica fissa di 2 GHz per la CPU e turbo disattivato.

Tutte le 156 consegne di subentro selezionate e tutte le 52 build delle fasi originali hanno superato ogni riesecuzione. La valutazione completa contiene 2.080 misurazioni, inclusi tutti i tredici controlli sul proprio codice. Abbiamo verificato le risposte grezze, ricalcolato la latenza p95, verificato gli hash del sorgente e i limiti delle risorse e conservato ogni misurazione pianificata.

Calcoliamo intervalli al 95% da 10.000 ricampionamenti dei dieci round di misurazione, usando gli stessi round campionati tra i programmi. Un confronto è irrisolto quando il suo intervallo di differenza include lo zero. Questi intervalli esplorativi non sono corretti per confronti multipli. I conteggi dei successori più veloci confrontano i punteggi misurati e non implicano differenze statisticamente distinguibili.

Tra 13 build originali della fase 4 e 156 subentri, tutte le 2.028.000 risposte HTTP misurate sono risultate corrette. Il ritardo massimo di dispatch è stato di 0.607 ms. Ogni riesecuzione ha rispettato i limiti del driver di un ritardo di dispatch p95 inferiore a 0.05 ms e un ritardo massimo inferiore a 1 ms. Il ritardo rimane incluso nella latenza.

La selezione pubblicata include tentativi aggiuntivi. GLM 5.3 e Qwen 3.8 Max usano le loro seconde traiettorie originali complete dopo i fallimenti iniziali nella fase 3. Quattro build pilota di subentro completate sono state riutilizzate, quindici coppie Claude hanno ricevuto tentativi di ripristino dell'infrastruttura e sette subentri falliti hanno ricevuto un nuovo tentativo di coding dai loro donatori originali. Tutti e sette i nuovi tentativi di coding hanno avuto successo. I nuovi tentativi sono stati selezionati indipendentemente dall'esito; i tentativi precedenti restano archiviati. Questi risultati confrontano build selezionate, non l'affidabilità al primo tentativo.

Il valutatore distingue i fallimenti dei candidati dalle misurazioni non valide per motivi di infrastruttura. La correttezza HTTP richiede almeno il 99% delle richieste servite, warmup corretti e nessuna risposta errata. Ogni build classificata deve avere dieci riesecuzioni valide. Nessun codice è stato modificato durante la valutazione temporale.

Si tratta di un unico progetto e di una traiettoria selezionata per configurazione. Le quattro fasi sono correlate e le 156 coppie di subentro condividono donatori e destinatari. Gli intervalli descrivono la variazione delle riesecuzioni su questo host; non coprono altri compiti, macchine o esecuzioni di coding indipendenti. I risultati descrivono questi artefatti sotto questi carichi di lavoro, piuttosto che una classifica generale delle capacità di coding, della comprensione del codice o della manutenibilità in produzione.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Cosa viene dopo?

I prossimi esperimenti aggiungeranno più progetti e traiettorie di coding indipendenti, aumenteranno la difficoltà delle fasi che raggiungono il tetto del carico offerto e misureranno versioni prima/dopo applicabili sotto lo stesso carico di lavoro. Controlli di auto-continuazione in sessione fresca aiuterebbero a separare gli effetti della cronologia di conversazione dal partire con il codice di un altro agente.

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{alper2026,
  author = {Alper, Şevval},
  title  = {{AIM-Code Bench: benchmark di codifica agentica}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Consultato il 22 settembre 2026}
}

Registro delle modifiche

13 aggiornamenti

Tutte13Generale9Metodologia4

2026

1. 23 lug

   Aggiunti i risultati dei modelli Kimi K3 e Inkling alla classifica del benchmark.

2. 23 lug

   Aggiunti Kimi K3 e Inkling al benchmark di coding agentico.

3. 10 lug

   Aggiunti Grok 4.5 e la famiglia di modelli GPT 5.6 al confronto del benchmark di coding.

4. 10 lug

   Aggiunti sette modelli al benchmark: Grok 4.5 e la famiglia GPT-5.6 (Sol, Terra, Luna).

5. 2 lug

   Aggiunto un confronto dei modelli specializzati nel codice GPT 5.3 Codex e Kimi K2.7 Code alla sezione di valutazione backend.

6. 1 lug

   Aggiunto Claude Sonnet 5 alla classifica del benchmark con un punteggio complessivo di 0,772.

7. 15 giu

   Aggiunti Kimi K2.7 Code e Claude Fable 5 ai risultati del benchmark e alle sezioni di confronto dei costi.

8. 15 giu

   Aggiornata la metodologia dell'harness: Claude Fable 5 ha girato sull'abbonamento Claude Code CLI invece che su Opencode tramite OpenRouter.

9. 3 giu

   Aggiunti Claude Opus 4.8, Gemini 3.5 Flash e MiniMax M3 alla classifica del benchmark e ai confronti di costo.

10. 20 mag

    Sostituito l'elenco dei modelli testati e tutti i risultati di successo, costo e latenza con nuovi valori.

11. 20 mag

    Sostituito Aider con opencode come harness degli agenti e aggiunte tre esecuzioni per cella per misurare la varianza.

12. 3 apr

    Sostituito Gemini 3 Pro con Gemini 3.1 Pro Preview nel riepilogo dei risultati del benchmark.

13. 24 feb

    Aggiunto Gemini 3.1 Pro Preview ai risultati del benchmark Agentic LLM.

Şevval Alper

Ricercatrice di IA

Segui

Şevval è una ricercatrice di IA presso AIMultiple. Ha precedenti esperienze di ricerca nella generazione di numeri pseudocasuali utilizzando sistemi caotici.
Şevval si concentra su strumenti di programmazione IA, agenti IA e tecnologie quantistiche.

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