Le benchmark Claude Code révèle un angle mort des juges IA : les bugs de pipeline attribués à tort aux capacités du modèle.

Configuration du benchmark et résultats initiaux

Un développeur a exécuté un benchmark contrôlé sur trois piles d'agents de codage en utilisant Claude Code (Opus 4.6) comme évaluateur autonome. Le benchmark a testé : OpenCode + MiniMax-M2.7, Gemini CLI + Gemini 3.1 Pro, et Codex CLI + GPT-5.4. Chaque nouveau test était une session fraîche sans mémoire inter-sessions, utilisant l'invite : "exécutez le plan du benchmark, collectez les artefacts, rédigez un rapport."

Lors des deux premières exécutions, OpenCode + MiniMax a obtenu respectivement 15/60 et 16/60. Les rapports générés automatiquement indiquaient : "Consistant avec les résultats précédents : exécution rapide mais aucune sortie de code significative" et "Consistant : MiniMax ne peut pas exécuter la tâche. Le modèle pourrait manquer de la capacité à lire des fichiers externes et à produire des modifications de code dans cette base de code Rust."

La découverte du bug

Après deux sessions produisant des verdicts identiques blâmant le modèle, le développeur a envoyé une instruction à une nouvelle session : "allez plus loin, vérifiez les journaux du démon avant de réessayer." La nouvelle session a retracé le problème jusqu'à un fichier de déversement à ~/.orchestratord/logs/<task_id>.txt. L'étape du plan produisait 50 Ko de contexte utile, mais le sandbox d'OpenCode n'autorisait par défaut que les lectures à l'intérieur du répertoire de travail. Comme le fichier de déversement était en dehors de l'espace de travail, l'étape d'implémentation recevait une chaîne vide au lieu du plan.

La session a proposé un correctif de configuration d'une ligne (déplacer le chemin du déversement à l'intérieur de l'espace de travail) et a relancé le benchmark. Après le correctif, MiniMax a produit 219 lignes de code incluant une structure RetryConfig et une fonction utilitaire connect_with_retry, obtenant un score de 18/60. Les problèmes restants étaient de réelles faiblesses du modèle : quatre erreurs de compilation de type incompatible dans les tests unitaires.

Implications pour l'évaluation par IA

Cet incident révèle un angle mort critique chez les juges IA autonomes : ils ne se demandent pas "ma chaîne de traitement est-elle cassée ?" même lorsque leur propre analyse identifie des symptômes comme "pourrait manquer de la capacité à lire des fichiers externes". Les deux premières sessions ont exécuté le benchmark complet de bout en bout et ont produit des rapports complets, mais n'ont jamais vérifié les journaux du démon par elles-mêmes. Ce n'est que lorsqu'on leur a explicitement demandé d'enquêter que la troisième session a découvert le bug de configuration.

Ce mode d'échec est particulièrement pertinent car le LLM-comme-juge est devenu la méthodologie d'évaluation par défaut pour de nombreux benchmarks d'agents, y compris le scoring automatique de type arène, les systèmes de test A/B internes et la modélisation de récompense. Le développeur note : "J'étais à une frappe humaine près de publier un benchmark qui attribuait à tort, avec confiance, un bug de sandbox à un modèle."

Autres résultats du benchmark

Codex + GPT-5.4 a pris la première place avec 50/60, bien qu'il ait eu un taux de réussite step_finished de seulement 25 % (trois des quatre étapes de l'orchestrateur ont signalé un échec). Le développeur note cette bizarrerie sans autre explication dans le texte source fourni.