AIM-Code Bench: Benchmark di codifica agentica

Valutare gli LLM senza i loro harness di agenti di codifica non riflette pienamente come vengono utilizzati nella pratica. Lo sviluppo reale comporta anche l'estensione di lavoro esistente, l'assunzione di codice non familiare e il lasciare implementazioni su cui altri possano costruire. Introduciamo AIM-Code Bench per valutare i modelli insieme ai loro harness di agenti di codifica in attività software in evoluzione. Oltre alla correttezza, il benchmark misura le prestazioni in fase di esecuzione, l'adattamento ai requisiti mutevoli e gli esiti quando gli agenti costruiscono sul codice gli uni degli altri.

Risultati

Opus 5 ha mostrato la latenza osservata più bassa nelle fasi 1 e 3; Fable 5.1 ha guidato le fasi 2 e 4. Questi sono i leader della valutazione di sviluppo originale.

La tabella mostra la latenza p95 in millisecondi; più bassa è meglio. Ogni valore è la mediana di tre misurazioni replicate del programma salvato. Le classifiche sono calcolate all'interno di ciascuna fase, utilizzando la piena precisione. Le misurazioni successive di passaggio di consegne usano i propri controlli rimisurati e sono presentate separatamente.

Parte 1: sviluppare e migliorare le proprie implementazioni

Ogni agente ha mantenuto il proprio codice e la propria conversazione durante 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 ottenibili preservando il comportamento richiesto.

L'esperimento ha coperto dodici configurazioni modello-prodotto: tre in Claude Code, tre in Codex, quattro in OpenCode, una in Grok Build e una in Devin CLI. Lo sforzo è stato 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 codifica insieme.

Abbiamo cercato di riflettere il più fedelmente possibile il modo in cui le persone usano realmente i prodotti di codifica basati sull'IA negli scenari reali. Molte persone usano i modelli all'interno dei propri harness; pertanto, sebbene abbiamo utilizzato i modelli disponibili nei rispettivi harness, abbiamo usato modelli a pesi aperti tramite opencode.

Quattro fasi del progetto

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

La latenza misurata del batch di MiniMax M3 è passata da 12.053 ms nella fase iniziale a 2.526 ms nella fase di capacità. Si tratta di una riduzione osservata del 79,0% man mano che l'implementazione cambiava e l'evizione diventava un requisito. La sua implementazione HTTP originale della fase 4 si è poi classificata 2nd, a 0.908 ms.

La latenza misurata del batch di Qwen 3.8 Max è passata da 2.496 a 2.096 ms tra le prime due fasi, una riduzione osservata del 16,1%. Il suo risultato della fase 3 si è classificato 3rd. 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 accelerazioni di ottimizzazione controllate. Ogni fase modifica il comportamento richiesto o il carico di lavoro. In particolare, la latenza della fase 4 non può essere sottratta dalla latenza della fase 3: l'interfaccia e le operazioni per richiesta differiscono. 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 coprono 48 diff verificati delle fasi originali attraverso le dodici 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 forniti di task/test e la diagnostica JSON sono esclusi. Misurano la differenza finale rispetto allo snapshot iniziale di ogni fase. Modifiche più grandi possono includere test utili o ottimizzazioni; modifiche più piccole non sono automaticamente migliori. Il report dei diff collegato contiene le modifiche al sorgente per ciascuna fase.

Parte 2: rilevare l'implementazione di un altro agente

Dopo aver misurato le traiettorie originali, ci siamo posti due domande diverse: quale codice offre agli altri agenti un punto di partenza utile 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 dodici configurazioni ha ricevuto il codice delle altre undici configurazioni, creando 132 coppie ordinate donatore-destinatario. Non ci sono state nuove auto-acquisizioni. 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 sono state rimisurate come controlli del proprio codice. Quei controlli erano stati sviluppati con la cronologia di conversazione originale, mentre i rilevamenti 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 undici benefici percentuali. Un valore positivo significa che i suoi successori hanno generalmente 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 massimo beneficio mediano del successore con +13,16%, seguito da Fable 5.1 con +11,19% e SWE-2 con +5,78%. Questi esiti possono riflettere sia le prestazioni dell'implementazione ereditata sia la facilità con cui i successori potevano estenderla. Le percentuali normalizzano la scala, ma non eliminano le differenze nella qualità di partenza o nei margini di ottimizzazione.

Vista B: prestazioni come successore

Per ogni donatore, calcoliamo la latenza mediana ottenuta dai suoi undici 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 su undici donatori. Un valore positivo significa che era generalmente 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 questo riepilogo esplorativo dei successori con +3,81%, seguito da GLM 5.3 con +3,34% e SWE-2 con +2,93%. Essere il donatore più forte ed essere il successore più forte sono esiti diversi in questo esperimento. La formula basata sulla mediana può produrre esattamente pari zero, come accade per MiniMax M3 e Qwen 3.8 Max; questi non sono raggruppamenti basati sulla tolleranza di valori di latenza vicini.

I successori hanno costruito sul sorgente ereditato?

Riportiamo la variazione del sorgente separatamente dalle prestazioni: (added lines + deleted lines) / inherited source lines. Contiamo anche i passaggi di consegne che eliminano più del 50% del sorgente ereditato. Si tratta di un tasso di eliminazione elevato, non la prova di una riscrittura da zero: rinomine, 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 o Qwen 3.8 Max. Tutti e undici hanno superato quella soglia per Kimi K3, GPT-5.6 Luna, MiniMax M3 e Claude Sonnet 5. Si tratta di osservazioni sulle modifiche alle righe fisiche, non di una classifica di manutenibilità. I programmi dei donatori contenevano solo 75–668 righe di sorgente, incluso il codice ausiliario, e la scelta di includere test/strumenti influisce sulle percentuali di eliminazione.

Metodo di misurazione, ripetizioni e ambito

Ogni punteggio di prestazione riportato utilizza tre riesecuzioni dello stesso programma salvato. La tempistica del passaggio di consegne ha usato 240 richieste HTTP per riesecuzione a 20 richieste al secondo, con una CPU, 128 MiB di memoria e un limite di 64 processi/thread per ciascun candidato.

Tutte le 132 consegne selezionate del passaggio di consegne hanno risultati validi superati, e tutti i dodici controlli del proprio codice sono passati. L'ultimo lotto completo di tempistiche ha fornito 129 misurazioni incrociate e tutti i controlli. Tre misurazioni incrociate non valide sono state recuperate in lotti successivi di sole tempistiche utilizzando codice e impostazioni invariati; una ha richiesto un ulteriore recupero dopo un picco di dispacciamento. Ogni risultato valido del lotto completo è stato mantenuto. Non è stato utilizzato alcun punteggio parziale non valido.

Attraverso le 103.680 richieste HTTP misurate finali, il ritardo di invio massimo mantenuto è stato di 16.111 ms; 13 ritardi hanno superato i 5 ms e nessuno ha superato il limite di validità originale di 25 ms. Il ritardo rimane incluso nella latenza. Il rumore temporale può modificare classifiche ravvicinate, in particolare tra lotti.

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 della fase 3. Quattro build pilota completate del passaggio di consegne sono state riutilizzate, quindici coppie Claude hanno ricevuto tentativi di ripristino dell'infrastruttura e sette passaggi di consegne falliti hanno ricevuto un nuovo tentativo di codifica dai loro donatori originali. Tutti e sette i tentativi di codifica sono passati. I nuovi tentativi sono stati selezionati indipendentemente dall'esito; i tentativi precedenti rimangono archiviati. Questi risultati confrontano build selezionate, non l'affidabilità al primo tentativo.

La pipeline di misurazione ha ricevuto anche una correzione temporale prima della valutazione originale riportata e una correzione della classificazione degli errori di avvio prima dell'ultima valutazione completa del passaggio di consegne. Quest'ultima distingue un'uscita confermata del candidato dall'errore DNS di Docker che la segue. I requisiti originali di correttezza e i limiti delle risorse sono stati mantenuti; la pista di controllo è collegata di seguito.

Si tratta di un progetto e di una traiettoria selezionata per configurazione. Le quattro fasi sono correlate e le 132 coppie di passaggio di consegne condividono donatori e destinatari. I risultati descrivono questi artefatti sotto questi carichi di lavoro, piuttosto che una classifica generale della capacità di codifica, 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

Quali sono i prossimi passi?

I prossimi esperimenti aggiungeranno più progetti e traiettorie di codifica indipendenti, aumenteranno la difficoltà delle fasi che raggiungono il tetto del carico offerto e misureranno le versioni applicabili prima/dopo sotto lo stesso carico di lavoro. I 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