La moitié du code écrit par l'IA qui réussit un test industriel serait rejetée par de vrais développeurs, selon une nouvelle étude

La moitié du code écrit par l'IA qui réussit un test industriel serait rejetée par de vrais développeurs, selon une nouvelle étude

L'organisation de recherche METR a analysé le benchmark de codage largement utilisé SWE-bench Verified et a conclu qu'il exagère considérablement les performances réelles des agents d'IA dans le développement logiciel.

Quatre développeurs expérimentés en open-source ont examiné 296 contributions de code générées par l'IA et ont découvert qu'environ la moitié des solutions qui ont réussi les tests automatisés seraient rejetées dans de véritables projets logiciels.

De nombreux rejets ne proviennent pas de problèmes stylistiques, mais d'erreurs fonctionnelles fondamentales. Les agents d'IA échouent à corriger le problème sous-jacent, même lorsqu'ils parviennent à passer la suite de tests automatisés.

Une remise en question de la validité du benchmark

Une nouvelle étude de METR suggère que le benchmark populaire SWE-bench Verified surestime considérablement la performance réelle des agents d'IA. Environ la moitié des solutions notées comme "acceptées" seraient rejetées par les mainteneurs de projets réels.

SWE-bench Verified est (ou était) l'un des benchmarks les plus importants pour l'ingénierie logicielle assistée par IA. Il mesure si les agents d'IA peuvent résoudre de réels problèmes de programmation issus de projets open-source, avec un testeur automatisé vérifiant si les modifications de code soumises passent les tests associés. Des entreprises comme Anthropic et OpenAI citent régulièrement ces résultats pour mettre en avant les progrès de leurs modèles.

Une enquête menée par METR soulève maintenant de sérieuses questions sur la validité de ce benchmark. L'équipe de recherche, composée de Parker Whitfill, Cheryl Wu, Joel Becker et Nate Rush, a fait examiner un total de 296 contributions de code générées par l'IA par quatre développeurs expérimentés qui maintiennent activement trois projets SWE-bench (scikit-learn, Sphinx et pytest). Environ la moitié des solutions ayant passé le test automatisé ne seraient jamais intégrées dans la base de code réelle par les mainteneurs de projet.

Les tests automatisés ne capturent qu'une partie de la qualité du code

L'étude a utilisé des solutions générées par l'IA provenant de cinq modèles : Claude 3.5 Sonnet (Old), Claude 3.7 Sonnet, Claude 4 Opus, Claude 4.5 Sonnet, et GPT-5. Les tests provenaient du Benchmarking Hub d'Epoch AI. Les mainteneurs ne savaient pas si une solution donnée provenait d'un humain ou d'une IA.

Pour tenir compte du bruit dans la prise de décision humaine, les chercheurs ont également demandé aux mainteneurs d'évaluer des solutions humaines originales qui avaient effectivement été intégrées dans les projets. Seulement 68 % de ces solutions de référence ont été réapprouvées pour adoption. Tous les résultats ont été normalisés par rapport à cette référence.

En moyenne, le taux d'adoption des mainteneurs se situe environ 24 points de pourcentage en dessous du score SWE-bench. METR affirme que cette différence est statistiquement significative. Le taux d'amélioration au fil du temps est également d'environ 9,6 points de pourcentage inférieur par an lorsqu'il est mesuré par des évaluations humaines, bien que les chercheurs eux-mêmes notent que ce résultat est statistiquement plus faible.

Les raisons des rejets : erreurs fonctionnelles basiques

Les mainteneurs ont classé leurs rejets en trois catégories :

• Mauvaise qualité de code (mauvais style ou non-respect des normes du projet)
• Dommages au code existant
• Erreurs fonctionnelles basiques

Selon le rapport de METR, "une part significative" des rejets était due à des erreurs fonctionnelles basiques, ce qui signifie que les agents d'IA n'ont pas réellement corrigé le problème sous-jacent, même si les tests automatisés ont réussi.

Le passage de Claude 3.5 Sonnet à Claude 3.7 Sonnet a produit des taux de réussite significativement plus élevés, mais a également conduit à plus de cas où les mainteneurs ont signalé des erreurs fonctionnelles basiques. De Claude 3.7 à Claude 4 Opus, les problèmes ont évolué de "test échoué" à "simplement mauvaise qualité de code". Claude 4.5 Sonnet a principalement amélioré la qualité du code. GPT-5 a obtenu des performances significativement inférieures à celles des modèles d'Anthropic dans cette étude.

Analyse de l'horizon temporel révélant une surestimation septuple

Les chercheurs ont également réalisé une analyse de l'horizon temporel qui convertit les scores de benchmark en temps de réalisation humaine à partir duquel un modèle atteint un taux de réussite de 50 %. L'écart est frappant : Claude 4.5 Sonnet atteint un horizon temporel d'environ 50 minutes selon le vérificateur automatisé, mais seulement environ 8 minutes lorsque noté par les mainteneurs. L'étude note que ces estimations sont moins stables car SWE-bench Verified a une plage de durée de tâche relativement étroite, nécessitant une extrapolation pour estimer le seuil de 50 %.

Ce que METR décrit ici est quelque chose que le domaine sait déjà : les benchmarks sont, au mieux, un proxy pour la performance réelle de l'IA. Les retours pratiques sont plus importants. Les deux côtés de l'argument existent ; de nombreux développeurs affirment que les agents d'IA aident réellement à coder, tandis que d'autres soulignent de sérieuses préoccupations concernant la qualité du code généré par l'IA.

L'engouement pour le codage par IA des quatre derniers mois tourne également autour de nouveaux modèles comme GPT-5.2-Thinking et Claude Opus 4.5. Ces modèles n'ont pas fait partie du test ; l'étude n'a examiné que des prédécesseurs plus faibles.

Cela dit, si les résultats se confirment, l'écart reste remarquablement large. SWE-bench Verified est considéré comme la référence en matière d'évaluation des agents de codage IA. Si la moitié des solutions qu'il marque comme "acceptées" ne peuvent pas survivre à une véritable révision humaine, cela remet en question les comparaisons entre modèles et érode les fondements sur lesquels investisseurs, entreprises et développeurs construisent leurs attentes pour le développement logiciel assisté par IA.

Conclusions importantes, mais avec des limites claires

Les chercheurs reconnaissent que l'étude ne prouve pas un plafond de capacité fondamental pour ces modèles. Ils affirment qu'il est "plausible" que de meilleures stratégies de formulation et des instructions plus ciblées pourraient réduire l'écart entre l'évaluation automatisée et le jugement humain.

La comparaison n'était pas non plus équitable. Les développeurs humains peuvent généralement répondre aux retours et réviser leur code, mais les agents d'IA n'ont eu qu'une seule chance. La configuration de l'examen n'était pas entièrement réaliste non plus : les mainteneurs n'avaient pas d'outils de test automatisés à leur disposition, les problèmes provenaient d'états de projet plus anciens, et les exigences de test ont été délibérément assouplies pour donner aux agents d'IA une meilleure chance.

Ainsi, l'étude ne concerne pas la capacité maximale de ces modèles. Ce qu'elle montre, c'est que prendre les scores de benchmark pour argent comptant surestime l'utilité réelle des agents d'IA sans ajustements supplémentaires et retours humains. Les chercheurs soupçonnent que des distorsions similaires apparaissent également dans d'autres benchmarks.

Joel Becker, co-auteur et chercheur chez METR, met également ses propres résultats en perspective sur X. Son principal enseignement n'est pas que les agents d'IA sont fondamentalement inutiles. Avec des capacités d'IA doublant tous les trois à six mois, même des écarts de performance de deux à dix fois se comblent rapidement.