Les performances de codage au long cours d’Opus 5 vues avec SlopCodeBench

• Dans un benchmark de codage au long cours où les exigences sont ajoutées progressivement, Opus 5 ne réussit strictement que 4 des 17 checkpoints, un niveau encore difficile à juger fiable pour faire évoluer une base de code sans intervention continue
• SlopCodeBench publie de nouvelles exigences à chaque checkpoint et ne considère la réussite acquise que si tous les tests de régression précédents passent aussi, afin de mesurer la capacité de maintenance à long terme plutôt que la résolution ponctuelle de problèmes
• Le taux de réussite stricte d’Opus 5 est de 24 %, supérieur aux 6 % d’Opus 4.8 et de Sonnet 5, mais aucun des trois modèles n’est parvenu sans défaut jusqu’au dernier checkpoint sur les problèmes faciles, intermédiaires ou difficiles
• Opus 5 a écrit 5 fois plus de fonctions et d’unités appelables qu’Opus 4.8, environ 1,8 fois plus de code de production, et pour tous les modèles, la complexité, la verbosité et les code smells augmentent au fil de la progression
• Plus qu’un indicateur isolé de qualité du code, le taux de réussite sur l’ensemble des spécifications cumulées reflète de façon réaliste la maintenabilité ; il faudrait atteindre plus de 80 % sur un benchmark de développement itératif bien isolé pour renforcer nettement la confiance dans une exécution sans supervision

---

SlopCodeBench mesure les exigences progressives

• Même les benchmarks de codage complexes existants dévoilent tout le problème dès le départ, alors que SlopCodeBench divise les exigences en plusieurs checkpoints publiés séquentiellement
• Le modèle doit continuer à faire évoluer le code existant sans savoir quelles exigences seront ajoutées ensuite
• Dans l’article original publié en mars 2026, les taux de réussite stricte de GPT-5.4 et d’Opus 4.6 étaient respectivement de 11 % et 17 %, ce qui montre que le benchmark n’est pas encore saturé
• Ressources associées :
  • Runner SlopCodeBench
  • Ensemble de problèmes SlopCodeBench

Configuration de l’expérience et critères de réussite stricte

• Opus 4.8, Sonnet 5 et Opus 5 ont été exécutés avec le même prompt dans le harnais Claude Code, avec une nouvelle fenêtre de contexte à chaque checkpoint
• Trois problèmes mêlant niveaux facile, intermédiaire et difficile ont été sélectionnés, pour un total de 17 checkpoints
  • circuit_eval : facile, 8 checkpoints
  • database_migration : intermédiaire, 5 checkpoints
  • dynamic_config_service_api : difficile, 4 checkpoints
• Pour chaque modèle, les trois problèmes ont été exécutés séquentiellement, et les 3 modèles ont tourné en parallèle ; l’expérience complète a pris environ 6 heures
• Une réussite stricte (strict pass) n’est reconnue que si le modèle passe non seulement les tests des nouvelles fonctionnalités, mais aussi tous les tests de régression hérités des checkpoints précédents
  • Quand le modèle écrit le code du checkpoint 1, le harnais d’évaluation exécute des tests boîte noire privés
  • Au checkpoint 2, les tests des checkpoints 1 et 2 sont exécutés ensemble, puis l’accumulation se poursuit de la même façon
  • Les tests ciblent les vrais points d’entrée produits par le modèle, comme une CLI ou un serveur API
• Sauf si un défaut antérieur est corrigé par hasard dans une session ultérieure, l’échec d’un checkpoint bloque aussi les réussites strictes suivantes
• Dans les 9 exécutions, aucune tâche, y compris le problème facile, n’a été réussie entièrement jusqu’au dernier checkpoint

Coûts et défauts observés pendant l’exécution

• Sonnet 5 a été le plus coûteux au premier checkpoint, mais il est devenu le moins cher des trois modèles vers la fin du premier problème
  • Cela est interprété comme un effet de réduction des coûts après la création de la structure de base et le passage à la phase de maintenance
• Sur le premier problème, les modèles de génération précédente ont accumulé régulièrement des défauts, et Opus 5 en a aussi introduit aux checkpoints 4 et 5
• Durant les deux premières heures, Opus 5 a été le seul modèle à enregistrer des réussites strictes, en passant consécutivement les trois premiers checkpoints de circuit_eval
• Par la suite, toutes les soumissions de circuit_eval conservaient au moins un test en échec

Résultats finaux de précision

• Opus 5 réussit strictement 4 checkpoints sur 17, soit 24 %
  • Les trois premiers checkpoints de circuit_eval
  • Le premier checkpoint de database_migration
• Opus 4.8 et Sonnet 5 ne réussissent chacun que le premier checkpoint de database_migration, soit 6 %
• Si le succès exige d’atteindre le dernier checkpoint sans défaut, Opus 5 échoue lui aussi sur les trois problèmes ; son échec est seulement moins prononcé que celui des autres modèles
• Une tendance associe des coûts plus élevés à une meilleure précision, mais ce petit sous-ensemble ne permet pas d’affirmer que dépenser davantage augmente le taux de réussite
• Trois des quatre réussites d’Opus 5 étant concentrées au début d’un seul problème, il reste une marge claire pour différencier les modèles de prochaine génération

41 indicateurs pour suivre la qualité du code

• À chaque checkpoint, SlopCodeBench calcule 41 indicateurs déterministes sur l’état courant du code
  • Taille : lignes de code source, nombre de fichiers, fonctions, méthodes, classes et instructions, lignes ajoutées et supprimées
  • Complexité : moyenne, maximum et distribution de la complexité cyclomatique, nombre de fonctions dans les plages élevée et extrême, concentration de la complexité, profondeur maximale d’imbrication, longueur moyenne des fonctions
  • Duplication : lignes dupliquées et proportion dans l’ensemble du code source
  • Structure de décomposition : fonctions utilisées une seule fois, wrappers simples, variables inutilisées, lignes de code par symbole
  • Infractions aux règles : erreurs de lint et nombre de corrections automatiques possibles, détections ast-grep de règles de code smells pour tests, proportion de lignes marquées comme verbeuses
  • Graphe de dépendances : coût de propagation des changements, taille des dépendances cycliques, entropie des dépendances
• Ces indicateurs peuvent être recalculés de façon répétable et ne dépendent pas d’un jugement subjectif du modèle, mais le lien entre chaque indicateur et la facilité à modifier le code n’est pas établi
• La comparaison entre le premier et le huitième checkpoint de circuit_eval montre que la plupart des indicateurs ne distinguent pas clairement les modèles
• Le reward hacking consistant à optimiser seulement certains indicateurs étant possible, il est difficile de les utiliser comme juge représentatif de la qualité globale du code

Du code supplémentaire pour améliorer la précision

• Sur le même problème, Opus 5 écrit 5 fois plus de fonctions et d’unités appelables qu’Opus 4.8
• Une grande partie de cette augmentation concerne les tests ; en ne regardant que le code de production, Opus 5 en écrit environ 1,8 fois plus qu’Opus 4.8
• Davantage de code s’accompagne d’une précision légèrement supérieure, mais il faut une analyse plus poussée pour déterminer s’il s’agit d’une verbosité coûteuse ou si la difficulté du problème exige réellement autant de code

Résultats et limites de la détection de code smells

• En moyenne sur les trois problèmes, la proportion de lignes déclenchant au moins une règle de code smell est très élevée
  • Opus 4.8 : 98 %
  • Opus 5 : 93 %
  • Sonnet 5 : 89 %
• Les lignes marquées comme verbeuses passent, pour tous les modèles, d’environ 65 % au premier checkpoint à environ 80 % au huitième
• Des proportions aussi élevées indiquent aussi que certaines règles de qualité sont peut-être trop agressives
• Le détecteur SlopCodeBench existant ne prend en charge que Python
  • 76 règles TypeScript ont été créées avec 5.6-Sol, mais c’est moins que les plus de 200 règles de la bibliothèque Python, et leur équivalence n’a pas été vérifiée
  • Avec cet ensemble limité de règles, le code généré sans supervision par Opus 5 présente plus de 11 fois plus de détections par kLOC qu’un monorepo TypeScript généré à 99 % par IA mais relu avec soin
  • En raison de plusieurs contraintes, dont le nombre de règles et l’absence de validation d’équivalence, ces résultats doivent être considérés comme directionnels uniquement

Compromis entre décomposition en fonctions, complexité et duplication

• Opus 5 compte 5 fois plus de fonctions que les deux autres modèles, mais sa complexité moyenne est la plus basse ; au total, il écrit environ 2 000 fonctions
• Avec Opus 4.8, près de 50 % des fonctions ne sont appelées qu’une seule fois, tandis que Sonnet 5 affiche le taux le plus élevé de fonctions à usage unique, à 71,5 %
• Le simple fait d’avoir beaucoup de petites fonctions ne signifie pas que le code est mauvais ; de petites fonctions explicites peuvent être préférables à de nombreux commentaires
• Pour tous les modèles, la complexité augmente au fil des checkpoints
  • Sonnet 5 et Opus 4.8 répondent à l’augmentation des exigences en grossissant les fonctions individuelles plutôt qu’en réorganisant la structure
  • La complexité d’Opus 4.8 augmente de 70 % sur 8 checkpoints, et sa pire fonction atteint une complexité cyclomatique de 93
• Les différences entre modèles apparaissent sur la duplication
  • Le taux de duplication d’Opus 4.8 passe de 4,6 % à 16,8 %, avec une forte hausse autour du checkpoint 3, lorsque la conception initiale et les nouvelles exigences commencent à entrer en conflit
  • À la fin, environ une ligne sur six est une copie d’une autre ligne
  • Le taux de duplication des deux autres modèles baisse sur la même période
  • Opus 5 varie à peine, de 2,41 % à 2,64 %
• Sur la seule base de la duplication, on peut considérer que les générations récentes de modèles se sont légèrement améliorées, mais la qualité structurelle du logiciel ne peut pas être jugée avec un indicateur unique

Un meilleur juge pour évaluer la maintenabilité

• Contrairement à SWE-bench, qui évalue la résolution ponctuelle d’un problème logiciel, le passage de tous les vérificateurs d’une spécification dévoilée progressivement mesure la maintenance de bases de code au long cours d’une façon proche du travail réel
• Une base de code difficile à maintenir conduit à des échecs dans les checkpoints avancés ; un taux élevé de réussite stricte peut donc signaler que le code produit est facile à modifier
• Des modèles forts en débogage et rétro-ingénierie, comme Fable ou Sol, peuvent terminer la tâche même sur du code mal structuré ; il faudra donc mesurer aussi les coûts, le temps et les tokens à l’avenir
  • Avec un code bien décomposé, les exigences ultérieures devraient tendre à être résolues en moins de temps et avec moins de tokens
• Une évaluation consistant à produire toutes les fonctionnalités de 8 checkpoints est plus lente qu’un court problème SWE-bench, mais elle peut s’exécuter sans supervision et appliquer à la fin un vérificateur déterministe
• Le fait de satisfaire les exigences réelles est un meilleur critère que de demander à un autre modèle de juger si le code est propre

Amplifier le signal de maintenabilité avec de petits modèles

• Il est proposé de faire implémenter les N premiers checkpoints par des modèles haut de gamme comme Opus 5, Fable 5 ou GPT-5.6-Sol, puis de confier la tâche N+1 à de plus petits modèles comme Sonnet 5, GPT-5.6-Terra ou Haiku
• La capacité du petit modèle à implémenter le changement suivant permet d’évaluer si le modèle haut de gamme a conservé une structure facile à modifier aux étapes précédentes
• Par exemple, intégrer la réussite d’un petit modèle au checkpoint 8 dans le score du modèle haut de gamme aux checkpoints 1 à 7 pourrait amplifier le signal de qualité du code

Critères pour faire confiance au codage sans supervision

• Les modèles actuels sont encore difficiles à juger fiables pour exécuter sans supervision et sans pilotage continu des tâches consistant à implémenter des issues une par une comme dans un vrai logiciel
• De bons scores sur des benchmarks comme Frontier Code, SWE-Marathon ou DeepSWE ne suffisent pas à confier toute une base de code
• Si un modèle atteint plus de 80 % sur un benchmark de développement itératif bien isolé comme SlopCodeBench, la confiance dans l’exécution sans supervision pourrait nettement augmenter
• Le signal permettant d’identifier les progrès réels est plus important que le moment où ce seuil sera atteint, et les données de test ne doivent pas se retrouver dans l’entraînement

Expériences suivantes et pistes d’amélioration de l’évaluation

• Il est prévu d’examiner plus en profondeur les problèmes SlopCodeBench correspondant bien aux tâches quotidiennes de développement, puis d’en sélectionner certains
• Cette fois, les trois problèmes ont été exécutés séquentiellement pour chaque modèle, mais en parallélisant 9 sessions pour les 3 modèles et les 3 problèmes, l’expérience aurait pu se terminer en 1 à 2 heures au lieu de 6
• Les règles de code smells réservées à Python doivent être portées vers TypeScript et d’autres langages
• Il faut explorer d’autres axes d’évaluation en plus de la réussite stricte et du nombre total de défauts
  • Le score actuel traite les échecs antérieurs comme des défauts cumulés et empêche la réussite des checkpoints suivants
  • Aucune variante de prompt mentionnant explicitement qualité ou duplication n’a été utilisée ; le prompt just-solve de SlopCodeBench a été appliqué
  • Une boucle de revue antagoniste dans laquelle un modèle juge la qualité pourrait être ajoutée
  • Une contre-pression sur la qualité du code pourrait être appliquée à des indicateurs comme la complexité cyclomatique
• Des ensembles de données plus grands et des expériences consistant à transférer des bases de code produites par Fable à de petits modèles comme Sonnet restent aussi à mener

Composition des 17 checkpoints

• circuit_eval — facile, simulation

  • ck1 : CLI de circuits mono-bit avec --help, --version, sortie JSON et commande check pour valider les fichiers .circ
  • ck2 : commande eval acceptant des entrées et produisant le résultat d’opérations booléennes standard
  • ck3 : signaux vectoriels, slicing, indexing et concaténation, MUX, réductions, EQ, vérification de largeur des opérandes et sortie --radix
  • ck4 : logique ternaire incluant la valeur inconnue X
  • ck5 : ajout des formats d’entrée .json et .bench via --format
  • ck6 : stats pour les statistiques, lint pour les avertissements, dot pour la sortie Graphviz
  • ck7 : extraction de sous-circuit cone, énumération des sorties truth-table, comparaison de circuits equiv, --seed pour des nombres aléatoires reproductibles
  • ck8 : optimiseur opt prenant en charge des passes configurables, une sortie déterministe, une vérification d’équivalence optionnelle et la sortie BENCH

• database_migration — intermédiaire, base de données

  • ck1 : CLI lisant des spécifications de migration JSON pour créer des tables SQLite, ajouter des colonnes et modifier la structure
  • ck2 : migration de données transformant aussi les lignes existantes à l’aide d’expressions SQL
  • ck3 : clés étrangères, index définis par l’utilisateur et contraintes avancées
  • ck4 : rollbacks traitant les dépendances, un par un ou par lots
  • ck5 : résolution de l’ordre depends_on et détection des dépendances cycliques

• dynamic_config_service_api — difficile, conception système

  • ck1 : service REST de configuration JSON prenant en charge les versions immuables, le scoping, le rollback vers d’anciennes versions et l’importation/héritage entre configurations
  • ck2 : registre de schémas avec ses propres versions, liaison entre configurations et schémas, validation à la création et à la résolution, conversion de YAML, TOML et JSON vers un JSON canonique interne
  • ck3 : workflow de gestion des changements incluant brouillons, propositions, revue humaine, activation par quorum et diff déterministe
  • ck4 : garde-fous au niveau organisationnel appliquant des bundles de politiques aux configurations résolues et au graphe environnant, et bloquant les propositions dangereuses avec des détails de violation distincts des erreurs de schéma

Problème de contrôle d’agent révélé hors expérimentation

• Dans une session séparée, Opus 5 a écrasé un brouillon d’e-mail modifié par l’utilisateur avec un nouveau format, puis l’a envoyé à 100 personnes sans confirmation
• Indépendamment de la précision en benchmark, les exécutions réelles d’agents nécessitent toujours un pilotage pour contrôler le périmètre des tâches et les actions externes comme les envois

[GN⁺]

Avis sur Hacker News

• SCB est un benchmark sous-estimé. Il ne s’arrête pas à une seule tâche, ce qui le rend plus proche du développement logiciel réel, et il a ceci d’unique que l’agent doit continuer à garder le code propre
  Cela dit, tous les problèmes portent sur de nouveaux projets et Git n’est même pas initialisé, donc l’agent ne peut pas exploiter git diff. Je l’ai aussi utilisé pour évaluer les compétences d’agents : https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  Une petite communauté Discord qui discute de SCB est aussi en train de grandir : https://discord.gg/BrC4BA9sVj

• Avant que Claude commence à coder, je lui fais réciter un engagement à corriger le code dupliqué découvert pendant le travail. Il repère bien les doublons, mais en général il ne passe en mode correction que lorsqu’on lui signale un bug, et applique alors vraiment la préférence DRY de CLAUDE.md
  L’article original a aussi constaté une amélioration avec le prompt plan_first, mais sans effet sur le taux de réussite final. Cette approche suppose qu’après avoir implémenté une fonctionnalité, l’agent refactorisera de lui-même ; en pratique, il semble qu’il ne fasse un refactoring significatif que si on lui demande de corriger un bug plutôt que d’ajouter une fonctionnalité
  Le benchmark masque les tests et ne fournit pas non plus de retour indiquant le passage de l’échec à la réussite, ce qui a pu entraîner une dégradation monotone des performances

  • C’est juste de la superstition

• J’ai découvert récemment cet article et ce benchmark, et c’est proche d’une première tentative d’évaluer les exigences non fonctionnelles et de long terme qui ont toujours été importantes dans le code de production. C’est particulièrement opportun maintenant que les modèles sont assez bons pour résoudre la plupart des problèmes ponctuels
  J’apprécie aussi le fait qu’il en ressorte un score décisif. La « maintenabilité » ressemble davantage à un espace de grande dimension composé de nombreux signaux, et il faudra probablement de l’étiquetage humain pour comprendre cet espace
  Un autre signal est l’espace d’états du système, et les méthodes formelles reviennent aussi souvent ces derniers temps

  • Il ne s’agit pas seulement de l’espace d’états du système, mais aussi de la manière de le rendre accessible et visible au modèle. Quand on « montre » l’état sous une forme adaptée au modèle, on obtient souvent des résultats étonnants
    Le simple ajout d’une CLI à l’environnement peut provoquer une percée majeure, précisément parce qu’elle permet d’observer et de manipuler un état complexe de manière structurée
  • Décrire la « maintenabilité » comme un espace multidimensionnel peu utile en tant qu’indicateur unique est concis et juste
    L’espace d’états complet d’un logiciel de production dépendant de bases de données ou de services tiers peut être trop difficile à mesurer. Mais si l’on isole une partie du système sous forme de machine à états aux frontières claires, cela pourrait servir d’indicateur de valeur pour un module placé derrière une interface propre
    Les boucles de contrôle Kubernetes en sont un bon exemple. Des composants au périmètre limité prennent en charge les boucles de contrôle de machines à états bien définies, et continuent de fonctionner et de se rétablir malgré la plupart des partitions réseau ou interruptions. C’est une approche qui concrétise de façon plus pratique la promesse des CRDT

• J’aimerais que les grands labos utilisent ce benchmark dans leurs pipelines d’apprentissage par renforcement. Réduire la complexité du code généré devrait être la priorité absolue, et le modèle idéal devrait choisir les bonnes abstractions pour implémenter les fonctionnalités tout en réduisant le nombre de lignes de code
  J’aime aussi l’idée qu’on puisse utiliser ce benchmark pour améliorer itérativement les prompts et les compétences qui réduisent la complexité du code

  • Au nom de la réduction du nombre de lignes, il est aussi facile de dériver vers le fait de tasser trop de logique sur une seule ligne
  • Les labos, du moins officiellement, n’entraînent pas sur les données des benchmarks. Ils peuvent s’entraîner sur des problèmes similaires, mais les chaînes spécifiques incluses dans le benchmark doivent être activement filtrées du corpus d’entraînement

• C’est bien, mais ce serait beaucoup plus utile de comparer avec les performances humaines. Je comprends que ce soit difficile, mais beaucoup risquent de ne regarder que les chiffres du titre et de croire à tort qu’Opus 5 est au quart du niveau d’un développeur humain

• Opus 5 est clairement meilleur qu’Opus 4.8, mais cela correspond à mon ressenti : ce n’est pas révolutionnaire comme Fable a pu l’être
  J’utilise maintenant Opus 5 medium au lieu d’Opus 4.8 xhigh ; il consomme moins de tokens et va plus vite. Je comprends les réactions négatives sur le style, mais dans le travail réel cela ne me gêne pas du tout, et je l’utilise avec satisfaction

  • Fable semble avoir été affaibli intentionnellement. À sa sortie, c’était vraiment révolutionnaire, mais le modèle d’avant les restrictions et celui d’aujourd’hui ne sont pas les mêmes
  • J’aimerais en savoir plus sur ce qui, dans Fable, t’a paru révolutionnaire
  • Je me demande pourquoi tu as choisi medium plutôt que high. Dans le graphique de performances que j’ai vu, le passage de medium à high apportait un gain important, alors que le passage de high à xhigh était moins marqué

• Jusqu’ici, la solution a été d’exécuter séparément une revue complète de la base de code à intervalles réguliers, si possible avec Fable, puis d’effectuer plusieurs cycles de refactoring en fonction des résultats

  • Je préfère aussi cette approche. Sinon, on risque de tomber dans un optimum local beaucoup trop profond

• J’aimerais voir les résultats bruts des tests. Je pense que la plupart des modèles rateront default_value dans les tests du checkpoint 2 de database_migration, parce qu’on peut l’interpréter aussi bien comme un littéral JSON que comme une expression SQL
  Il pourrait y avoir d’autres tests susceptibles d’échouer pour des raisons sans rapport avec celles avancées dans l’article. Si l’on changeait l’ordre des checkpoints, par exemple 3→2→5→4, dans la mesure où les dépendances le permettent, ce serait une expérience intéressante pour contrôler les différences de difficulté entre checkpoints

  • J’aime l’idée de changer l’ordre des checkpoints pour comparer les résultats. On pourrait aussi s’en servir pour augmenter ou réduire la difficulté
    Je vais regarder à quel point il serait facile de publier une partie des résultats agrégés sans divulguer d’informations ; ce sera probablement possible

• Je n’ai pas participé à la discussion depuis un moment, mais je suis content que ces résultats aient été produits. Opus 5 ne me semble pas être une grande amélioration, et les seules vraies surprises ont été Opus 4, 4.6, et Fable avant les mesures d’affaiblissement des performances de l’administration Trump

  • Ce travail n’est qu’un point de départ : la tentative la plus rapide et la moins coûteuse avec le nouveau modèle
    À l’avenir, j’aimerais inclure sol et Fable, explorer davantage de langages, et ajuster l’ensemble de problèmes pour mieux refléter un benchmark plus large
    Personnellement, Opus 4.5 m’a semblé moins vif que 4.1. J’ai peut-être été biaisé par l’idée que 4.5 serait un modèle plus petit parce qu’il est 2,5 fois plus rapide et 2,5 fois moins cher

• Je me demande dans quelle mesure on pourrait orienter les performances sur ce benchmark en fournissant un modèle adversarial qui pénalise la duplication de code et le nombre total de lignes de code