A-CODE-LLM Bench: Benchmark de codage agentique

Nous avons évalué les meilleurs grands modèles de langage (LLMs) sur 10 tâches de développement logiciel à l'aide d'un outil CLI agentique. Nous avons exécuté ~3,500 étapes de validation automatisées par modèle sur les couches API et UI.

A-CODE-LLM Bench résultats

Chaque alias a été exécuté 3 fois sur 10 tâches (30 échantillons par alias, 300 cellules par itération). Voir plus de détails sur la méthodologie.

• Sonnet obtient des scores supérieurs à Opus en codage agentique. Sonnet 5 (0.772) et Sonnet 4.6 (0.748) surpassent toutes les variantes d'Opus, y compris Opus 4.8 (0.702). Le meilleur modèle de codage d'Anthropic est le Sonnet de milieu de gamme, pas l'Opus phare.
• L'avance de Sonnet 5 augmente avec la longueur des tâches. Il domine le benchmark de construction en 10 tâches avec le meilleur backend de tous les modèles (0.701) et 125 appels d'outils, mais sur la ligne de base triviale, il n'utilise que 9 appels. L'avantage se manifeste sur les constructions longues et autonomes, pas sur les tâches courtes.
• Les scores frontend sont élevés et peu dispersés, donc le backend détermine le classement. Les huit meilleurs obtiennent tous entre 0.79 et 0.96 au frontend. Claude Haiku 4.5 a un frontend fonctionnel (0.731) mais un backend de 0.277, ce qui le limite à 0.413 ; GPT 5.5 thinking a un bon backend (0.620) mais un frontend de 0.542.
• Le niveau du modèle ne prédit pas sa capacité de codage. Le Sonnet de milieu de gamme surpasse l'Opus phare dans toutes les variantes, donc le réglage d'un modèle pour le travail agentique compte plus que sa taille ou son niveau de prix.
• La logique backend est la partie difficile pour les LLM actuels, pas l'interface utilisateur. Parmi les leaders, le frontend est presque résolu (les huit premiers entre 0.79 et 0.96) et le classement est déterminé presque entièrement par le backend, où les scores s'échelonnent de 0.70 à 0.23.

Comparaison coût et succès

• Le coût et le score ne sont pas liés. Le modèle le plus cher, Opus 4.7 à $3.08 par cellule, obtient un score de 0.610, inférieur à Sonnet 4.6 à $1.33. Dépenser plus n'augmente pas le score.
• Sonnet 4.6 coûte moins cher que Sonnet 5 pour un score presque identique : 0.748 à $1.33 contre 0.772 à $2.23. Le gain de 0.024 coûte $0.90 de plus par cellule.
• Chaque variante d'Opus coûte plus cher que Sonnet pour un score inférieur ou égal.
• Meilleur rapport qualité-prix : Kimi K2.7 Code est le modèle le moins cher au-dessus de 0.60 à $0.70. Gemini 3.5 Flash thinking obtient 0.625 à $1.30, correspondant au prix de Sonnet tout en surpassant tous les Opus.
• Le prix n'est pas un indicateur de qualité pour le codage agentique. Le coût reflète le positionnement des fournisseurs, pas le score qu'un modèle obtient sur ce benchmark, donc un prix plus élevé n'indique pas un meilleur modèle agentique.

Comparaison du temps d'exécution des tâches et du succès

• Le temps d'exécution et le score ne sont pas liés. Le modèle le plus rapide, Grok 4.3 à 142 secondes, obtient 0.431 ; le plus lent, Qwen 3.6 Plus à 1,948 secondes, obtient 0.333.
• Sonnet 5 est le plus lent des six premiers. À 1,763 secondes, il prend environ 3x plus de temps que Sonnet 4.6 (612 secondes) pour 0.024 de plus.
• Sonnet 4.6 est le plus rapide parmi les meilleurs, atteignant 0.748 en un tiers du temps de Sonnet 5.
• Les exécutions de plus de 1,600 secondes résultaient d'une sur-itération, pas de tâches plus difficiles : MiniMax M3, les deux variantes de Qwen, GLM 5.1 base et Deepseek V4 Pro ont tous obtenu un score inférieur à 0.55.
• Deux causes distinctes influencent le temps d'exécution. Au sein d'un même modèle, des exécutions plus longues peuvent signifier une itération plus approfondie qui améliore le score (Sonnet 5). D'un modèle à l'autre, les exécutions les plus longues proviennent d'une sur-itération improductive (tous les modèles au-dessus de 1,600 secondes ont obtenu un score inférieur à 0.55). Le temps seul ne permet pas de distinguer les deux.

Appels d'outils par tâche

• Le nombre d'appels d'outils est une empreinte comportementale, pas une mesure de capacité, et il n'est pas comparable d'un harnais à l'autre. OpenAI apply_patch réduit une modification de fichier complet en un seul appel, donc ses faibles comptes reflètent la conception de l'outil, pas moins de travail.
• Le nombre d'appels d'outils ne prédit pas le score. Les comptes vont de 18 (Grok 4.3) à 125 (Sonnet 5), sans corrélation entre le nombre et le score.
• Sonnet 5 effectue le plus d'appels de tous les modèles (125) et obtient le meilleur score ; Sonnet 4.6 atteint presque le même score avec environ 50. Les deux fonctionnent, aux extrémités opposées de la plage.
• MiniMax M3 a effectué 108 appels pour un score médian de 0.583, donc un nombre élevé à lui seul ne suffit pas.

LLM performance sur une tâche unique réussie

Aucun modèle n'a réussi toutes les étapes du benchmark complet ci-dessus. Pour comparer le coût et la vitesse à conditions égales, nous avons exécuté une tâche de base simple que chaque modèle peut accomplir : quatre points de terminaison CRUD, validation de base, pas d'authentification ni de base de données.

Comparaison du coût et des lignes de code

• Les tâches triviales ne différencient pas les modèles, ce qui est la raison d'être du benchmark complet. Sur la ligne de base, le coût, la longueur du code et le taux de réussite convergent : chaque modèle l'achève, les lignes se situent entre 40 et 64, et le coût tombe à quelques centimes. Les différences entre modèles n'apparaissent que sur le travail agentique long et multi-fichiers.
• La longueur du code n'est pas une caractéristique du modèle sur les tâches simples (40 à 64 lignes), sauf pour un modèle qui génère trop, Gemini 3.5 Flash base, qui a produit 131 lignes et est devenu le plus cher de la ligne de base.
• Sonnet 5 adapte l'effort à la tâche : 9 appels, 46 lignes, $0.09 sur la ligne de base contre 125 appels sur le benchmark complet. Sonnet 4.6 a exécuté la ligne de base à environ 15% de son coût par cellule du benchmark complet ($0.20 base, $0.15 thinking). Opus 4.8 a également réduit à $0.16 et 6 appels. Consultez l'article LLM Pricing pour les tarifs par token.

Temps d'exécution et utilisation des tokens

• Les modèles se répartissent en deux types de rythme. Les modèles adaptatifs ajustent l'effort à la difficulté (Opus 4.8 : 34 secondes sur la ligne de base, 1,072 sur le benchmark) ; les modèles à rythme fixe restent lents quel que soit le contexte (MiniMax M3 : 475 contre 1,684).
• La production pour la même tâche varie de 8x, allant de 787 tokens (Qwen 3.6 Plus thinking) à 6,643 (GPT 5.4 Mini), donc la verbosité est une disposition stable du modèle, pas un effet de la tâche.

Qu'est-ce que les systèmes LLM agentiques ?

La construction de logiciels est itérative : écrire du code, l'exécuter, lire les erreurs, les corriger, répéter. Les systèmes d'IA agentique permettent aux LLM de suivre ce même cycle. Le modèle fonctionne dans un environnement de développement où il peut écrire des fichiers, exécuter des commandes, lire les sorties et apporter des modifications en fonction de ce qu'il voit, en continuant jusqu'à ce que la tâche soit terminée.

Cela importe parce que les applications réelles ne sont pas des fichiers uniques. Elles ont des backends avec des routes et des modèles de base de données, des frontends avec des composants et des appels API, des fichiers de configuration, des dépendances et des tests. Faire fonctionner tout cela ensemble nécessite des tests et des raffinements itératifs, ce que permet précisément l'architecture agentique.

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

Comment cela fonctionne

Le modèle est placé dans un harnais avec accès à un shell, au système de fichiers et à la sortie d'exécution. Lorsqu'on lui demande de construire une application, il écrit des fichiers de manière incrémentale. Après chaque étape, le harnais montre au modèle ce qui s'est passé : le serveur a-t-il démarré, les tests ont-ils réussi, le linter a-t-il signalé des erreurs ? Sur la base de ce retour, le modèle décide quoi écrire ou corriger ensuite.

Cela diffère fondamentalement de la génération en une seule fois. Dans les configurations à une passe, le modèle génère une base de code entière à l'aveugle, sans moyen de vérifier si elle fonctionne. Dans les systèmes LLM agentiques, le modèle voit les conséquences de chaque action et corrige le cap. Cependant, cette capacité à elle seule ne suffit pas. Le modèle a encore besoin d'un raisonnement solide pour implémenter correctement la logique métier, et c'est là que les différences de performance se manifestent vraiment.

Méthodologie du benchmark LLM agentique

Nous avons utilisé Opencode comme harnais agentique pour tous les modèles et les avons connectés via OpenRouter, à une exception près : Claude Fable 5 a été exécuté sur la CLI Claude Code avec l'abonnement Claude. Chaque cellule a été exécutée 3 fois pour mesurer la variance par cellule et stabiliser le classement. Nous avons évalué leur capacité à travailler de manière autonome sur 10 tâches de développement logiciel (T-1 à T-10), allant de systèmes de réservation à des tableaux de bord interactifs. Ces tâches exigent que les agents gèrent des projets multi-fichiers et livrent des produits fonctionnels.

Exécution et orchestration

Chaque agent et chaque tâche démarrent dans un environnement propre. Les instructions sont fournies dans un fichier TASK.md, et nous utilisons un chien de garde de 20 minutes pour les scripts de lancement. Durant cette phase, nous enregistrons les codes de sortie, le temps d'exécution et si les fichiers backend et frontend ont été créés. Nous suivons également l'utilisation des tokens en temps réel pour les catégories d'entrée, de sortie et de cache.

Validation backend : Nous déployons les projets générés dans des environnements isolés pour les tester par rapport à un contrat YAML canonique. La validation couvre les scénarios de chemin nominal, la gestion des erreurs (400/403/409) et la cohérence des données.

Nous testons les résultats en deux modes :

Le mode adaptatif valide la fonctionnalité même avec des noms de routes différents, tandis que le mode strict exige une adhésion exacte au contrat.

Le score global du backend est calculé par cellule comme suit :

backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)

où has_backend vaut 1 si la cellule a produit un projet backend, 0 sinon. L'adaptatif est pondéré plus fortement car il mesure l'exactitude comportementale ; le strict ajoute une pénalité pour la dérive du contrat (routes renommées, codes de statut substitués, champs de réponse restructurés).

Tests de l'interface utilisateur et des scénarios utilisateur

Nous utilisons l'automatisation du navigateur pour simuler des flux utilisateur réels, y compris les pré-vérifications, le rendu et l'authentification. Nous vérifions les étapes fonctionnelles telles que la soumission de connexion et le comportement après connexion pour garantir que l'application fonctionne sans plantage.

La notation de l'interface utilisateur répartit huit étapes en deux groupes. Les étapes d'infrastructure (pré-vérification backend, rendu frontend, formulaire de connexion visible, soumission de connexion, réponse 2xx à la connexion, pas de plantage à l'exécution) mesurent si l'application fonctionne tout court. Les étapes de comportement (signal d'authentification après connexion, signal de comportement après connexion) évaluent si l'application remplit sa fonction prévue une fois en marche.

ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)

Les étapes de comportement bloquées sont exclues du dénominateur de comportement, de sorte qu'une cellule n'est pas doublement pénalisée si l'application ne parvient pas à se charger.

Calcul des tokens

Les comptes de tokens sont extraits de la réponse de l'API LLM. Nous soustrayons les tokens d'entrée mis en cache du total des tokens d'entrée pour obtenir l'entrée effective, qui reflète uniquement les tokens nouvellement traités. Les tokens de sortie ne sont jamais mis en cache, ils restent donc inchangés.

Agrégation finale

Le score final du benchmark est calculé en combinant les résultats des phases précédentes : Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Nous attribuons un poids plus élevé au backend car les défaillances logiques au niveau de l'API invalident souvent tout succès du frontend.

Exemple de tâche

Tâche 6 : Système de tickets d'assistance

La tâche 6 porte sur le développement d'un écosystème complexe de support client. L'objectif principal est de construire une plateforme qui assure la médiation de la communication entre les clients et les agents de support tout en appliquant strictement les règles métier et les limites de sécurité. Cette tâche évalue la capacité d'un agent à gérer des machines d'état multi-utilisateurs, l'isolation des données et la communication par fils de discussion dans un environnement full-stack.

La tâche nécessitait de construire un système d'assistance comprenant :

• Permissions distinctes pour les clients (émission/réponse) et les agents (gestion/résolution).
• Un flux de statuts rigide qui empêche les transitions illégales et impose des actions spécifiques au rôle.
• Isolation avancée des données où les requêtes de ressources non autorisées renvoient 404 au lieu de 403 pour protéger l'intégrité du système.
• Un système de réponse chronologique pour une interaction fluide entre agent et client.
• Un backend FastAPI combiné à un frontend réactif alimenté par Vite (React/Vue/Svelte).
• Configuration reproductible via des commandes shell spécifiques pour une activation immédiate du système.

Vous pouvez consulter la documentation de la tâche 6 sur GitHub.

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{kaleliolu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-LLM Bench: Benchmark de codage agentique}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Consulté le 2 Juillet 2026}
}

Berk Kalelioğlu

Chercheur en IA

SuivreVoir le profil complet

Examiné techniquement par

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe chaque mois des centaines de milliers d'entreprises (selon similarWeb), dont 55 % des entreprises du classement Fortune 500. Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes et le Washington Post, ainsi que par des entreprises mondiales comme Deloitte et HPE, des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne. Vous trouverez d'autres entreprises et ressources réputées ayant fait référence à AIMultiple. Tout au long de sa carrière, Cem a exercé les fonctions de consultant, d'acheteur et d'entrepreneur dans le secteur des technologies. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la numérisation. Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité directe du PDG. Il a également piloté la croissance commerciale de la société de deep tech Hypatos, qui a atteint un chiffre d'affaires annuel récurrent à sept chiffres et une valorisation à neuf chiffres en seulement deux ans. Les travaux de Cem chez Hypatos ont été présentés dans des publications technologiques de référence telles que TechCrunch et Business Insider. Cem intervient régulièrement lors de conférences internationales sur les technologies. Diplômé en génie informatique de l'université de Bogazici, il est également titulaire d'un MBA de la Columbia Business School.

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