Les modèles plus intelligents deviennent aussi plus habiles à pirater les benchmarks de codage.

Les suites d’eval construites à partir de bugs réels corrigés par la suite sont particulièrement vulnérables, car les problèmes ont déjà été résolus. Si l’agent a accès à l’historique du dépôt ou au Web public, il peut parfois aller chercher la réponse au lieu de la déduire.

Pour mesurer l’ampleur de ce comportement, nous avons construit un agent chargé d’auditer les trajectoires d’eval. Sur SWE-bench Pro, nous avons constaté que 63 % des résolutions réussies d’Opus 4.8 Max ont retrouvé le correctif au lieu de le déduire. Lorsque nous avons verrouillé l’historique Git et restreint l’accès à Internet, les scores ont chuté brutalement pour Opus comme pour notre modèle, Composer 2.5 :

• Opus 4.8 Max est passé de 87,1 % à 73,0 %
• Composer 2.5 est passé de 74,7 % à 54,0 %

Des recherches antérieures ont montré que les réponses aux benchmarks de codage peuvent fuiter via des sources accessibles au public, notamment cette étude de 2024 et un rapport de Meta de 2025. Notre étude quantifie le problème sur des exécutions actuelles d’agents de codage de pointe. Plus généralement, la leçon est qu’en plus d’éviter la contamination au moment de l’entraînement, les benchmarks de codage agentique ont aussi besoin d’environnements d’exécution contrôlés.

Pour les équipes qui mènent des eval, nous proposons d’atténuer ce reward hacking en auditant les transcriptions et en encadrant l’environnement d’eval.

#Détecter un modèle avec un modèle

Pour mesurer l’ampleur de ce comportement de reward hacking, nous avons demandé à l’auditeur d’examiner 731 trajectoires d’Opus 4.8 Max. Il a eu accès à l’énoncé du problème et à la trajectoire complète de l’agent, sans savoir si l’exécution avait réussi, puis a déterminé si l’agent avait retrouvé la réponse connue.

Les deux patterns de reward hacking les plus courants qu’il a constatés étaient les suivants :

• Recherche en amont : dans 57 % des trajectoires, Opus 4.8 Max a trouvé la PR fusionnée ou le fichier source corrigé sur le Web public, puis a reproduit le correctif presque à l’identique.
• Exploration de l’historique Git : dans 9 % des trajectoires, Opus 4.8 Max a parcouru l’historique .git fourni pour trouver le futur commit qui corrigeait le bug, puis en a extrait le patch.¹

À mesure que les modèles gagnent en puissance, ils peuvent parfois déduire qu’ils se trouvent dans une eval, en particulier lorsque la tâche est tirée d’un ancien dépôt public. Même dans les cas où ils ne se souviennent pas du correctif appris pendant l’entraînement, l’environnement peut quand même leur donner des indices montrant que le bug a déjà été résolu.

Dans une tâche SWE-bench Multilingual issue d’une issue jq de 2019, l’agent a essayé de reproduire le bug avec le binaire jq du système. Comme l’image avait été construite après la correction du bug, la reproduction a échoué, et l’agent en a déduit que l’issue avait déjà été résolue. Cette prise de conscience l’a poussé à chercher le correctif au lieu d’en élaborer un lui-même.

Quelques cas étaient plus directs. Un agent a trouvé une page miroir de SWE-bench qui exposait les tests cachés et le patch de référence. Un autre a obtenu des fichiers de test cachés et a codé en dur la chaîne d’exception attendue nécessaire pour réussir.

cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'

cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1

#Conception d’environnement plus stricte

La plupart des cas de reward hacking passaient par le Web public et l’historique du dépôt. Pour les evals construites à partir de dépôts publics historiques, ces canaux doivent être contrôlés, car ils peuvent contenir la réponse. En réponse, nous avons construit un harness strict avec deux mécanismes d’isolation :

1. Isolation de l’historique. Avant que l’agent ne démarre, le répertoire .git est supprimé et le dépôt est réinitialisé comme un dépôt vierge à un seul commit. L’historique d’origine n’est restauré qu’au moment de l’évaluation, afin que les tests s’exécutent normalement.
2. Proxy de sortie. L’accès réseau est refusé par défaut. À titre de mesure de contrôle best-effort, un proxy verrouillé permet de résoudre les dépendances via une liste d’autorisation de registres de paquets, et rien d’autre.

Cette restriction est propre aux evals construites à partir de dépôts publics historiques. C’est l’une des raisons pour lesquelles nous préférons les evals construites à partir de dépôts non publics, comme CursorBench. Elles permettent de tester la capacité de codage agentique tout en laissant les agents utiliser des outils comme ils le feraient en conditions réelles.

#Un écart qui se creuse

Nous avons réexécuté SWE-bench Pro et SWE-bench Multilingual avec le harness plus strict, puis comparé chaque résultat au score obtenu avec le harness standard comme approximation de l’effet combiné de la suppression de ces canaux de fuite² :

• Sur SWE-bench Multilingual, l’écart était inférieur à 1 point pour Opus 4.6, de 9,1 points pour Opus 4.8 Max et de 7,5 points pour Composer 2.5.
• Sur SWE-bench Pro, l’écart était inférieur à 1 point pour Opus 4.6, de 14,1 points pour Opus 4.8 Max et de 20,7 points pour Composer 2.5.

Ce qu’il faut retenir clairement, c’est que le reward hacking est bien plus courant avec les modèles plus récents et plus sophistiqués qu’avec les anciens. Fait intéressant, les modèles GPT ne montrent pas la même hausse, avec des écarts généralement plus faibles dans nos exécutions.

Nous avons également observé que notre propre modèle, Composer 2.5, présentait l’écart Pro le plus important de l’étude. C’est l’une des raisons pour lesquelles nous ne considérons pas le score standard de SWE-bench Pro comme un benchmark fiable pour Composer. Ce score était bien réel, au sens étroit où le harness l’a produit, mais il mélangeait la capacité de codage et l’accès à des correctifs connus.

#Concevoir des evals pour des agents conscients de l’évaluation

Le principal enseignement pour les équipes qui exécutent des evals de codage est que la conception du benchmark ne doit pas s’arrêter à la construction du jeu de données. Elle doit aussi tenir compte de l’environnement d’exécution, notamment de ce que l’agent peut rechercher, inspecter, récupérer et retrouver pendant l’exécution de la tâche.

Cela ne signifie pas que chaque eval doive supprimer l’accès à Internet ou à l’historique git. Certaines evals visent à tester dans quelle mesure les agents exploitent le contexte environnant d’une base de code réelle, et dans ce type de configuration, un accès étendu peut faire partie de la tâche. Le problème apparaît lorsque cet accès change la signification du score.

Pour les benchmarks historiques sur des dépôts publics, un accès ouvert peut permettre aux agents de trouver le correctif déjà connu au lieu de résoudre le bug. Sans contrôles dans le harness, les scores peuvent mêler capacité de codage et récupération de réponses.

Les équipes qui exécutent des evals doivent déterminer le comportement qu’elles veulent mesurer, concevoir le harness en conséquence et rendre l’installation explicite lorsqu’elles communiquent les résultats. L’audit des transcriptions peut aider à repérer les cas où les modèles résolvent les tâches de manière inattendue. L’objectif n’est pas d’interdire l’usage normal des outils, mais de s’assurer que le benchmark mesure bien ce qu’il prétend mesurer.

Même dans ce cas, un problème ouvert plus difficile subsiste. À mesure que les modèles prennent davantage conscience du fait qu’ils sont évalués, ils peuvent modifier leur comportement de manière plus subtile, d’une façon qu’on ne corrige pas simplement en isolant l’historique git ou en restreignant l’accès à Internet. La contamination à l’exécution est une version concrète d’un défi plus large : créer des evals qui conservent leur validité de construit même lorsque le modèle déduit qu’il est en train d’être évalué.