AIM-Code Bench: Benchmark de codage agentique

Évaluer les LLM sans leurs harnais d'agent de codage ne reflète pas pleinement leur utilisation réelle. Le développement réel implique aussi d'étendre un travail existant, de reprendre du code inconnu et de laisser des implémentations sur lesquelles d'autres pourront s'appuyer. Nous présentons AIM-Code Bench pour évaluer les modèles avec leurs harnais d'agent de codage sur des tâches logicielles en évolution. Au-delà de la justesse, le benchmark mesure les performances d'exécution, l'adaptation à des exigences changeantes et les résultats lorsque les agents s'appuient mutuellement sur leur code.

Résultats

Fable 5.1 a affiché la latence observée la plus faible aux étapes 1 et 2 ; Opus 5 a dominé les étapes 3 et 4.

Le tableau présente la latence p95 (le 95 centile) en millisecondes ; plus elle est basse, mieux c'est. Chaque valeur est la médiane de dix mesures rejouées du programme enregistré. Les classements reposent sur une précision complète au sein de chaque étape. Les mêmes mesures de l'étape 4 servent de témoins sur code propre dans la comparaison de reprise. Des classements numériques proches n'indiquent pas nécessairement des performances distinguables.

Partie 1 : développement et amélioration de leurs propres implémentations

Chaque agent a conservé son code et sa conversation entre les étapes. Nous avons mis à jour la spécification de la tâche à mesure que de nouvelles exigences arrivaient et avons accordé jusqu'à 20 minutes pour chaque étape. Les prompts décrivaient un travail de développement ordinaire et demandaient aux agents de viser les meilleures performances possibles tout en préservant le comportement requis.

L'expérience couvrait treize configurations modèle-produit : quatre dans Claude Code, trois dans Codex, quatre dans OpenCode, une dans Grok Build et une dans Devin CLI. L'effort était moyen lorsqu'il était pris en charge, élevé pour Kimi K3 et GLM 5.3, et la valeur par défaut du fournisseur pour MiniMax M3. Chaque résultat appartient donc à la fois au modèle et au produit de codage.

Nous avons cherché à refléter aussi fidèlement que possible la manière dont les gens utilisent réellement les produits de codage IA dans des scénarios réels. De nombreuses personnes utilisent des modèles dans leurs propres harnais ; c'est pourquoi, bien que nous ayons utilisé les modèles disponibles dans leurs harnais respectifs, nous avons utilisé les modèles open-weights via opencode.

Quatre étapes du projet

Les étapes 1 à 3 utilisaient 5 000 opérations par lot. L'étape 4 utilisait des requêtes HTTP indépendantes de 1 000 opérations chacune, avec un CPU et 128 Mio de mémoire alloués au service candidat.

La latence par lot mesurée de MiniMax M3 est passée de 37.833 ms à l'étape initiale à 12.254 ms à l'étape de capacité. Il s'agit d'une réduction observée de 67,6 % à mesure que l'implémentation a changé et que l'éviction est devenue une exigence. Son implémentation HTTP initiale de l'étape 4 s'est ensuite classée 4, à 3.009 ms.

La latence par lot mesurée de Qwen 3.8 Max est passée de 11.638 à 8.023 ms entre les deux premières étapes, soit une réduction observée de 31,1 %. Son résultat à l'étape 3 s'est classé 4. Ces trajectoires montrent pourquoi un seul résultat initial ne rend pas compte des changements qui apparaissent lorsqu'un agent continue de développer un projet.

Ces pourcentages décrivent les trajectoires enregistrées, et non des accélérations d'optimisation contrôlées. Chaque étape modifie le comportement ou la charge de travail requis. En particulier, la latence de l'étape 4 ne peut pas être soustraite de celle de l'étape 3 : l'interface et le nombre d'opérations par requête diffèrent. Une affirmation directe d'optimisation avant/après exigerait de rejouer les deux versions sous la même charge de travail applicable.

Dans quelle mesure le code a-t-il changé en cours de route ?

Les quatre étapes couvrent 52 diffs vérifiés de l'étape d'origine sur les treize configurations. L'étape 4 illustre la variation de la taille de l'implémentation et du style d'édition :

Ces comptages incluent les tests et outils source écrits par l'agent, les commentaires et les lignes vides ; les mises à jour de tâche/test fournies et les diagnostics JSON sont exclus. Ils mesurent la différence finale par rapport à l'instantané de départ de chaque étape. Des modifications plus importantes peuvent inclure des tests ou des optimisations utiles ; des modifications plus petites ne sont pas automatiquement meilleures. Le rapport de diff lié contient les modifications source par étape.

Partie 2 : reprendre l'implémentation d'un autre agent

Après avoir mesuré les trajectoires d'origine, nous avons posé deux questions différentes : quel code donne aux autres agents un point de départ utile, et quel agent obtient les meilleurs résultats lorsqu'il étend le code de quelqu'un d'autre ?

Nous avons créé des branches à partir des implémentations enregistrées de l'étape 3 et avons demandé aux destinataires d'effectuer l'étape 4. Chacune des treize configurations a reçu le code des douze autres configurations, soit 156 paires donneur–destinataire ordonnées. Il n'y a pas eu de nouvelle auto-reprise. Chaque destinataire a démarré une session isolée nouvelle avec le code du donneur et les mêmes exigences de l'étape 4 ; il ne pouvait pas voir le harnais ni les sessions des autres agents.

Les soumissions originales de l'étape 4 servent de témoins sur code propre, en utilisant les mêmes mesures que la partie 1. Ces témoins ont été développés avec l'historique de conversation d'origine, tandis que les reprises commençaient de zéro. La comparaison combine donc les effets du code de départ et de la conversation. Cette transition demande aux successeurs d'étendre un cache existant en service HTTP tout en optimisant la latence des requêtes.

Vue A : bénéfice fourni par le code d'un donneur

Pour chaque paire, nous comparons la latence HTTP du successeur à la latence originale de l'étape 4 de ce même successeur :

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

Le score d'un donneur est la médiane de ces douze bénéfices en pourcentage. Une valeur positive signifie que ses successeurs ont généralement atteint une latence plus faible que leurs propres continuations d'origine. Il s'agit d'une vue basée sur la performance de l'utilité d'une implémentation de départ ; elle ne mesure pas directement la qualité de la documentation ni la facilité de compréhension.

Opus 5 a fourni le bénéfice médian le plus élevé pour les successeurs, à +17,30 %, suivi d'Opus 5.5 à +15,70 % et de Fable 5.1 à +11,34 %. Ces résultats peuvent refléter à la fois la performance de l'implémentation héritée et la facilité avec laquelle les successeurs ont pu l'étendre. Les pourcentages normalisent l'échelle, mais n'éliminent pas les différences de qualité de départ ni de marge d'optimisation.

Vue B : performance en tant que successeur

Pour chaque donneur, nous calculons la latence médiane atteinte par ses douze destinataires. Chaque destinataire de ce donneur est ensuite comparé à cette référence commune :

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

Le score du destinataire est son avantage médian sur douze donneurs. Une valeur positive signifie qu'il a généralement été plus rapide que le destinataire médian du même code de départ. Cela évite de récompenser un destinataire simplement parce que sa propre implémentation d'origine était lente.

GPT-6 Astra a mené ce résumé exploratoire des successeurs à +2,68 %, suivi d'Opus 5 à +2,33 % et de Grok 4.6 à +0,88 %. L'avance d'Astra sur Opus 5 n'était pas distinguable compte tenu de l'incertitude mesurée. Être le donneur le plus fort et être le successeur le plus fort sont des résultats différents dans cette expérience.

Les successeurs ont-ils construit sur le code source hérité ?

Nous rapportons le churn du code source séparément de la performance : (added lines + deleted lines) / inherited source lines. Nous comptons également les reprises qui suppriment plus de 50 % du code source hérité. Il s'agit d'un taux de suppression importante, et non d'une preuve de réécriture à partir de zéro : les renommages, le reformatage et la suppression de code auxiliaire peuvent franchir le seuil.

Aucun des successeurs sélectionnés n'a supprimé plus de la moitié du code source hérité total de GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, Claude Opus 5.5 ou Qwen 3.8 Max. Tous les douze ont franchi ce seuil pour Kimi K3, GPT-5.6 Luna, MiniMax M3 et Claude Sonnet 5. Ce sont des observations sur les changements de lignes physiques, pas un classement de maintenabilité. Les programmes donneurs ne contenaient que 75–668 lignes source, code auxiliaire compris, et le choix d'inclure des tests/outils affecte les pourcentages de suppression.

Méthode de mesure, reprises et périmètre

Chaque score de performance rapporté utilise dix reprises du même programme enregistré. Les étapes 1 à 3 utilisaient 40 lots mesurés par reprise. L'étape 4 et la mesure des reprises utilisaient 1 200 requêtes HTTP par reprise, à 20 requêtes par seconde pendant 60 secondes, avec un CPU, 128 Mio de mémoire et une limite de 64 processus/threads pour chaque candidat.

Nous avons mesuré les programmes en série sur un serveur Linux dédié Intel i7-7700. Le pilote et le candidat s'exécutaient sur des cœurs physiques distincts, avec des threads frères inutilisés, une politique de CPU fixe à 2 GHz et le turbo désactivé.

Les 156 soumissions de reprise sélectionnées et les 52 builds d'étape d'origine ont toutes réussi chaque reprise. L'évaluation complète contient 2 080 mesures, y compris les treize témoins sur code propre. Nous avons vérifié les réponses brutes, recalculé la latence p95, vérifié les empreintes source et les limites de ressources, et conservé chaque mesure planifiée.

Nous calculons des intervalles de 95 % à partir de 10 000 rééchantillonnages des dix séries de mesures, en utilisant les mêmes séries échantillonnées pour tous les programmes. Une comparaison est non résolue lorsque son intervalle de différence inclut zéro. Ces intervalles exploratoires ne sont pas ajustés pour les comparaisons multiples. Les comptages de successeurs plus rapides comparent les scores mesurés et n'impliquent pas de différences statistiquement distinguables.

Sur 13 builds d'étape 4 d'origine et 156 reprises, les 2 028 000 réponses HTTP mesurées étaient toutes correctes. Le délai d'expédition maximal était de 0.607 ms. Chaque reprise respectait les limites du pilote d'un délai d'expédition p95 inférieur à 0.05 ms et d'un délai maximal inférieur à 1 ms. Le délai reste inclus dans la latence.

La sélection publiée inclut des tentatives supplémentaires. GLM 5.3 et Qwen 3.8 Max utilisent leurs deuxièmes trajectoires originales complètes après des échecs initiaux à l'étape 3. Quatre builds pilotes de reprise menés à terme ont été réutilisés, quinze paires Claude ont reçu des tentatives de récupération d'infrastructure, et sept reprises échouées ont reçu une nouvelle tentative de codage de leurs donneurs d'origine. Les sept nouvelles tentatives de codage ont réussi. De nouvelles tentatives ont été sélectionnées quel que soit le résultat ; les tentatives antérieures restent archivées. Ces résultats comparent des builds sélectionnés, pas la fiabilité au premier essai.

L'évaluateur distingue les échecs des candidats des mesures invalidées par l'infrastructure. L'exactitude HTTP exige qu'au moins 99 % des requêtes soient servies, que les échauffements soient corrects et qu'aucune réponse incorrecte ne soit présente. Chaque build classé doit disposer de dix reprises valides. Aucun code n'a changé pendant l'évaluation de la latence.

Il s'agit d'un seul projet et d'une seule trajectoire sélectionnée par configuration. Les quatre étapes sont liées, et les 156 paires de reprise partagent des donneurs et des destinataires. Les intervalles décrivent la variation des reprises sur cet hôte ; ils ne couvrent pas d'autres tâches, machines ou exécutions de codage indépendantes. Les résultats décrivent ces artefacts sous ces charges de travail, plutôt qu'un classement général de la capacité de codage, de la compréhension du code ou de la maintenabilité en production.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Quelle est la suite ?

Les prochaines expériences ajouteront davantage de projets et de trajectoires de codage indépendantes, augmenteront la difficulté des étapes qui atteignent le plafond de charge proposé, et mesureront des versions avant/après applicables sous la même charge de travail. Des témoins de continuation personnelle en session fraîche aideraient à séparer les effets de l'historique de conversation du fait de commencer avec le code d'un autre agent.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{alper2026,
  author = {Alper, Şevval},
  title  = {{AIM-Code Bench: Benchmark de codage agentique}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Consulté le 22 septembre 2026}
}

Journal des modifications

13 mises à jour

Toutes13Général9Méthodologie4

2026

1. 23 juil

   Ajout des résultats des modèles Kimi K3 et Inkling au classement du benchmark.

2. 23 juil

   Ajout de Kimi K3 et Inkling au benchmark de codage agentique.

3. 10 juil

   Ajout de Grok 4.5 et de la famille de modèles GPT 5.6 à la comparaison du benchmark de code.

4. 10 juil

   Ajout de sept modèles au benchmark : Grok 4.5 et la famille GPT-5.6 (Sol, Terra, Luna).

5. 2 juil

   Ajout d'une comparaison des modèles spécialisés en code GPT 5.3 Codex et Kimi K2.7 Code à la section de notation backend.

6. 1 juil

   Ajout de Claude Sonnet 5 au classement du benchmark avec un score global de 0,772.

7. 15 juin

   Ajout de Kimi K2.7 Code et Claude Fable 5 aux résultats du benchmark et aux sections de comparaison des coûts.

8. 15 juin

   Mise à jour de la méthodologie du harnais : Claude Fable 5 a fonctionné sur l'abonnement Claude Code CLI au lieu d'Opencode via OpenRouter.

9. 3 juin

   Ajout de Claude Opus 4.8, Gemini 3.5 Flash et MiniMax M3 au classement du benchmark et aux comparaisons de coûts.

10. 20 mai

    Remplacé la liste des modèles évalués et tous les résultats de réussite, de coût et de latence par de nouvelles valeurs.

11. 20 mai

    Aider remplacé par opencode comme harnais d'agent, et trois exécutions par cellule ajoutées pour mesurer la variance.

12. 3 avr

    Remplacé Gemini 3 Pro par Gemini 3.1 Pro Preview dans le résumé des résultats du benchmark.

13. 24 fév

    Ajout de Gemini 3.1 Pro Preview aux résultats du benchmark Agentic LLM.

Şevval Alper

Chercheuse en IA

Suivre

Şevval est chercheuse en IA chez AIMultiple. Elle a une expérience de recherche préalable dans la génération de nombres pseudo-aléatoires à l’aide de systèmes chaotiques.
Şevval se concentre sur les outils de codage IA, les agents IA et les technologies quantiques.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire