SWE-Duel : des agents de code s'écrivent mutuellement des bugs, GPT-5.5 en corrige 98,3%

Les benchmarks statiques de programmation vieillissent vite : leurs tâches finissent dans les jeux de données d'entraînement, et les agents les plus performants atteignent le plafond. Les auteurs du preprint SWE-Duel (arXiv cs.CL) proposent une autre approche : une évaluation sans contenu préparé à l'avance. Deux agents créent à tour de rôle des tâches l'un pour l'autre et se vérifient mutuellement. Le tournoi de 1500 tours a réuni 11 couples « modèle + harnais » sur 15 dépôts dans cinq langages. GPT-5.5 avec Codex CLI prend la première place : il corrige 98,3% des défauts qui lui parviennent en revue.

Comment se déroule un tour de duel

À chaque tour, l'agent Red travaille sur un dépôt réel au sein de trois sessions isolées sur le plan du contexte. Il commence par imaginer et implémenter une nouvelle fonctionnalité, accompagnée de ses tests. Il y glisse ensuite un bug subtil et écrit des tests scellés qui détectent ce bug. Le résultat prend la forme d'une pull request.

Elle n'entre dans le jeu de tâches que si deux conditions sont réunies. Premièrement, la PR doit passer les tests de la fonctionnalité et les tests existants du dépôt, tout en échouant exactement sur les tests du bug. Deuxièmement, une session neuve du même agent doit parvenir à corriger le bug à l'aveugle. Cette seconde condition écarte les tâches insolubles : si l'auteur ne sait pas corriger lui-même le bug qu'il a implanté, la tâche n'est pas comptabilisée.

C'est ensuite au tour de Blue. On ne lui dit pas que la PR contient un bug : il se contente de la relire. Sa victoire n'est validée que si son correctif passe les trois jeux de tests. Les agents échangent ensuite leurs rôles. La difficulté n'est donc pas figée à la sortie du benchmark : elle progresse avec le niveau des participants.

Qui gagne, et comment

Les meilleurs participants l'emportent de façons différentes. Les auteurs distinguent deux profils : le meilleur solveur et le meilleur créateur de tâches.

• GPT-5.5 + Codex CLI : première place, meilleur solveur, corrige 98,3% des défauts vérifiables.
• Claude Opus 4.8 + mini-swe-agent : deuxième place, meilleur créateur de tâches, taux de victoire de Red de 27,3%.
• Ampleur du tournoi : 11 participants, 15 dépôts, cinq langages, 1500 tours.
• Au sein d'une même famille de modèles, les tâches de la version la plus récente battent un solveur de référence fixe dans 42,9% des cas, contre 4,0% pour celles des versions plus anciennes.

Ce dernier chiffre est sans doute le plus intéressant. Il indique, à titre préliminaire, que la difficulté des tâches augmente avec la capacité du modèle à les concevoir. Pour un benchmark censé « grandir tout seul », c'est la propriété essentielle. Si elle se confirme sur un plus grand nombre de familles, le plafond de saturation cessera d'être un problème : des auteurs plus forts prépareront automatiquement des examens plus difficiles.

Il faut aussi garder à l'esprit que les participants sont ici des couples « modèle + harnais ». Le classement mesure la qualité de l'ensemble de la combinaison, et pas seulement celle des poids du modèle. Les auteurs eux-mêmes qualifient de préliminaire le résultat sur la hausse de la difficulté, une réserve honnête : les données proviennent d'un seul tournoi.

Ce que l'on peut en tirer en pratique

L'idée est applicable même sans une arène de 11 participants. Pour une équipe qui choisit un agent de code, il est utile de le tester sur son propre dépôt selon le schéma du duel. L'agent écrit une fonctionnalité avec ses tests et cache un bug, puis un second agent ou une session neuve tente de le trouver et de le corriger. Un classement public ne montrera pas cela : sur vos tâches, il se peut que le modèle ait déjà été « câblé » dans l'entraînement.

Les enseignements pratiques sont les suivants. Séparez les métriques : la capacité à corriger le code d'autrui et celle à concevoir des tâches difficiles mesurent des compétences différentes, et les leaders ne sont pas les mêmes. Le filtre d'admission des tâches (elles passent tous les tests sauf celui du bug, et se résolvent à l'aveugle) mérite d'être repris comme modèle distinct de contrôle qualité pour toute évaluation synthétique. Enfin, lorsque vous comparez des produits, regardez la combinaison précise de modèle et de harnais, et pas seulement le nom du modèle.