Le Banc d'Essai des Compétences : systematic-debugging vs. référence

La partie 3 du Banc d'Essai des Compétences pose une question plus spécifique que les deux premières : non pas "une compétence est-elle utile", mais "une compétence conçue pour une tâche spécifique surpasse-t-elle un modèle non assisté effectuant cette même tâche". Le débogage est le test le plus clair que nous ayons pour cela, car nous pouvons introduire les bugs nous-mêmes, savoir précisément ce qui ne va pas, et vérifier le rapport par rapport à la vérité terrain ligne par ligne.

Nous avons donc écrit un jeu Snake sur canvas, l'avons délibérément cassé de trois manières spécifiques, et avons exécuté le même jeu défectueux et la même plainte à travers deux sessions Claude Sonnet identiques. L'une avait la compétence systematic-debugging installée. L'autre non. Même prompt, même modèle, même bug. Seule la compétence diffère.

Le résultat n'a pas été la victoire nette à laquelle nous nous attendions, et c'est la partie qui mérite d'être lue.

Le piège que nous avons construit

Nous sommes partis d'une implémentation fonctionnelle de Snake, puis avons délibérément introduit trois bugs :

1. Vecteurs de direction inversés. ArrowUp et ArrowDown étaient connectés aux vecteurs que vous utiliseriez dans des coordonnées cartésiennes normales, et non aux coordonnées du canvas, où y augmente vers le bas. Appuyez sur haut, le serpent descend.
2. Apparition de nourriture dans l'espace pixel au lieu de l'espace grille. spawnFood utilisait cv.width (400 pixels) comme limite pour une coordonnée qui était censée être un index de grille dans une grille de 20 cellules (GRID). Multipliez un pas de grille par une plage de 400 et vous obtenez des coordonnées de nourriture qui atterrissent hors du plateau visible environ 95% du temps.
3. Incrémentation du score à chaque tick. score++ se trouvait dans la boucle de jeu principale au lieu d'être à l'intérieur de la branche "le serpent a mangé de la nourriture", de sorte que le score augmentait à chaque image, indépendamment de ce que le serpent faisait réellement.

Nous n'avons dit à aucune des sessions Claude ce qui n'allait pas. Nous avons donné aux deux branches le même rapport de bug de style joueur, formulé comme un testeur réellement agacé le ferait : "les commandes semblent incorrectes, la nourriture n'apparaît jamais, le score augmente tout seul." Ensuite, nous avons demandé à chaque session de trouver et de corriger tout ce qui causait cela.

Trois bugs, une plainte honnête, deux Claude. Voici ce qui est revenu.

Ce que chaque branche a rapporté

Référence (sans compétence)

La session de référence a parcouru le code sans méthode imposée, lisant tour à tour le gestionnaire d'entrée, le générateur de nourriture et la boucle de jeu. Elle a identifié les trois bugs introduits :

• Les vecteurs de direction étaient inversés pour l'axe y par rapport à la façon dont le rendu du canvas traite le "bas".
• spawnFood multipliait cv.width là où il aurait dû utiliser la constante de grille, produisant des coordonnées à l'échelle du pixel dans un jeu indexé par cellule.
• L'incrémentation du score se trouvait en dehors de la vérification de collision avec la nourriture, de sorte qu'elle se déclenchait inconditionnellement à chaque image.

Ensuite, il a continué à lire et a trouvé un quatrième problème que personne n'avait introduit : la vérification d'auto-collision comparait la tête du serpent à la cellule de la queue avant que la queue n'ait été retirée pour cette image. Lorsque le serpent se déplace dans le carré que sa propre queue est en train de quitter, la vérification considère toujours ce carré comme occupé et le qualifie de collision. C'est un cas limite réel et bien connu de Snake. Il existait dans notre code parce que nous avions écrit la logique de collision avant d'introduire quoi que ce soit, et la référence a simplement lu suffisamment loin pour le rencontrer.

Branche avec compétence (systematic-debugging installé)

La branche avec compétence a d'abord lu le fichier SKILL.md de systematic-debugging d'obra/superpowers (une compétence que nous avons notée séparément 9.6/10 pour la recherche de cause première basée sur des hypothèses), puis a appliqué sa méthode : formuler une hypothèse pour chaque symptôme, la tester par rapport au code, confirmer avant de toucher quoi que ce soit.

Elle a trouvé les trois mêmes bugs introduits, avec un langage de cause première plus concis et précis :

• "Inversion de direction due à la convention y-vers-le-bas du canvas : ArrowUp correspond à {x:0,y:-1} en supposant un y-vers-le-haut cartésien, mais le canvas rend y croissant vers le bas, donc haut et bas sont inversés."
• "L'apparition de nourriture utilise une limite en espace pixel (cv.width = 400) là où le calcul devrait utiliser une limite en espace grille (GRID = 20). Confirmé par une incompatibilité d'unités : multiplier une fraction aléatoire à l'échelle de la grille par une limite à l'échelle du pixel place environ 95% des apparitions en dehors de canvas.width."
• "Le score s'incrémente inconditionnellement dans la boucle de tick au lieu d'être conditionné par la branche de nourriture mangée. Confirmé en traçant le corps de la boucle : score++ s'exécute avant que la vérification de collision ne se produise, à chaque image."

Elle n'a pas trouvé le quatrième bug. Le problème d'auto-collision n'est jamais apparu, car les symptômes rapportés (commandes incorrectes, nourriture manquante, score incontrôlable) ne pointaient pas vers la logique de collision, et la méthode basée sur des hypothèses de la compétence reste ancrée aux symptômes qui lui ont été donnés. Elle a clôturé le rapport, confiante que tous les problèmes étaient résolus, et selon la lettre de la plainte, ils l'étaient.

Le rebondissement du quatrième bug

C'est le rebondissement que nous avons vérifié manuellement, en relisant les deux diffs par rapport au code réel : la branche avec compétence était plus précise sur les bugs qu'on lui avait demandé de trouver, et la branche de référence a trouvé un bug réel supplémentaire que personne n'avait demandé.

Ce n'est pas une critique de systematic-debugging en tant que compétence. Le débogage basé sur des hypothèses est conçu pour faire exactement ce qu'il a fait ici : prendre un symptôme rapporté, le réduire à une cause testable, confirmer avant de corriger, et s'arrêter une fois que le symptôme est expliqué. Cette discipline est précisément le point clé lorsque vous êtes confronté à un incident de production avec une trace de pile et un chronomètre en marche. Elle est également, par construction, limitée aux symptômes. Elle ne s'aventure pas dans du code qui n'est pas impliqué par la plainte.

La session de référence n'avait pas une telle portée. Elle a lu plus de code qu'elle n'en avait strictement besoin, et lire plus de code est la façon dont on tombe sur un bug que personne n'a mentionné. L'exploration libre est inefficace par conception, et ici, l'inefficacité a porté ses fruits.

La lecture honnête : aucune des deux branches n'est "meilleure" en général. Une branche est précise et peu coûteuse en attention, ancrée à ce qui lui a été dit. L'autre est moins ciblée et, cette fois-ci, suffisamment approfondie pour détecter quelque chose que le ticket ne mentionnait pas. Si votre rapport de bug est complet, le rapport de la branche avec compétence est celui que vous voulez lire. Si votre rapport de bug pourrait manquer de quelque chose, vous voulez la deuxième paire d'yeux que la référence vous a offerte gratuitement.

Les chiffres

	Référence (sans compétence)	Branche avec compétence (systematic-debugging)
Bugs trouvés (sur 3 introduits)	3 / 3	3 / 3
Bug réel non introduit trouvé	Oui (collision queue-libérée)	Non
Précision de la cause première	Correcte, moins formalisée	Correcte, mécanisme nommé par bug
Structure du rapport	Ad hoc	Hypothèse → test → confirmation, par bug
Tokens utilisés	50,338	58,357
Delta de tokens	—	+16%

La compétence a coûté 16% de tokens supplémentaires pour un rapport plus lisible et qui identifie le mécanisme plus précisément, mais elle n'a pas surpassé une référence qui a simplement été autorisée à continuer à lire. C'est la découverte à laquelle nous ne nous attendions pas en commençant, et c'est la raison pour laquelle nous publions la comparaison brute au lieu d'un verdict qui flatterait la compétence.

Quand vous voulez systematic-debugging

Le banc d'essai Snake sous-estime la valeur réelle de la compétence, car un jeu avec des bugs introduits et un fichier source complet en vue est proche du meilleur cas pour un modèle non assisté : tout ce qui est pertinent tient en une seule lecture. Le débogage en production ressemble rarement à cela.

Là où la recherche de cause première basée sur des hypothèses fait ses preuves, c'est pour le bug qui revient. Dans nos propres notes de catalogue sur systematic-debugging, un cas de test était une condition de concurrence que Claude avait déjà "corrigée" trois fois différentes dans la même base de code, chaque fois en appliquant un correctif plausible au lieu de la cause réelle. La discipline de la compétence (énoncer l'hypothèse, concevoir un test qui la falsifierait, ne pas toucher au code tant que le test ne la confirme pas) a finalement permis d'identifier la véritable interaction au lieu de produire une quatrième supposition. C'est le type de bug pour lequel systematic-debugging est conçu : récurrent, évasif, déjà deviné trois fois, dans une base de code trop grande pour être lue de bout en bout sur un coup de tête.

C'est aussi l'outil approprié dès que vous triez un incident de production. Vous avez un symptôme, un chronomètre, et aucune envie qu'un modèle s'égare à lire des modules non pertinents. Limitez-vous au rapport, confirmez la cause, déployez le correctif. C'est une fonctionnalité, pas une limitation, précisément dans ce contexte.

Quand une analyse libre l'emporte

Notre résultat Snake plaide également pour le cas inverse : lorsque vous soupçonnez que le rapport de bug est incomplet, ou lorsque vous effectuez une passe de pré-version plutôt que de courir après un symptôme rapporté, une lecture non contrainte du code fait quelque chose qu'une méthode basée sur des hypothèses ne fera structurellement pas. Elle examine du code dont personne ne s'est encore plaint.

C'est la même forme qu'une revue de code manuelle versus une réponse ciblée à un incident. Les deux ont leur place. L'erreur est de supposer qu'une compétence de débogage remplace une passe de revue plutôt que de la compléter. Si vous voulez l'angle général de la passe de revue à ce sujet, consultez notre point de vue sur les raisons pour lesquelles les compétences ne se déclenchent pas toujours comme vous l'attendez et comment nous structurons ces tests.

Reproduisez-le vous-même

Le banc d'essai est suffisamment petit pour être reconstruit en vingt minutes si vous voulez vérifier nos chiffres plutôt que de les prendre pour argent comptant. Écrivez un jeu Snake sur canvas (mouvement sur grille, un générateur de nourriture, un compteur de score, une boucle de jeu) et introduisez ces trois défauts :

1. Connectez ArrowUp/ArrowDown à des vecteurs de style cartésien (y: 1 pour le haut, y: -1 pour le bas) au lieu de vecteurs de style canvas, où l'augmentation de y déplace vers le bas de l'écran.
2. Dans votre fonction de génération de nourriture, multipliez votre fraction aléatoire par la largeur en pixels du canvas au lieu de votre nombre de cellules de grille, de sorte que la coordonnée résultante soit une valeur en pixels traitée comme un index de grille.
3. Déplacez l'incrémentation du score hors de la branche "la tête vient-elle d'atterrir sur de la nourriture" et dans le corps inconditionnel de la boucle de jeu.

Donnez à une session Claude uniquement la plainte du joueur ("les commandes semblent incorrectes, la nourriture n'apparaît jamais, le score augmente tout seul"), jamais la liste des bugs, et voyez ce qui revient. Ensuite, lisez votre propre logique de collision pour le cas de la queue libérée : vérifiez la position suivante de la tête par rapport à la cellule actuelle de la queue avant que la queue ne bouge, et voyez si elle s'y trouve aussi. La nôtre l'était, sans que nous l'ayons introduite.

FAQ

La compétence systematic-debugging rend-elle Claude moins efficace pour trouver des bugs ?

Non. Elle a trouvé tous les bugs introduits avec des causes premières plus précises que la référence. Ce qu'elle n'a pas fait, c'est dépasser la portée des symptômes rapportés, ce qui a permis à la référence de tomber sur un quatrième bug non introduit. La discipline de la portée est l'intention de conception de la compétence, pas un défaut.

Pourquoi la référence a-t-elle trouvé un bug que la compétence a manqué ?

La référence n'avait aucune hypothèse à laquelle s'ancrer, elle a donc lu plus de code que les symptômes rapportés ne l'exigeaient strictement. Lire plus de code est la façon dont on trouve des choses que personne n'a demandées. C'est une stratégie inefficace qui a porté ses fruits une fois, pas un avantage général.

Une augmentation de 16% des tokens en vaut-elle la peine pour une compétence de débogage ?

Cela dépend du bug. Pour un problème récurrent et difficile à cerner, la discipline vaut bien plus que 16% de tokens, car l'alternative est que Claude devine la même cause à plusieurs reprises, comme il l'a fait lors de notre propre test de catalogue avant que nous n'appliquions cette compétence. Pour un bug déjà bien circonscrit et superficiel, le surcoût vous offre un rapport plus clair et pas grand-chose d'autre.

Devrais-je utiliser systematic-debugging pour chaque correction de bug ?

Pas pour tous. Utilisez-la lorsqu'un bug est récurrent, lorsqu'une tentative de correction précédente n'a pas tenu, ou lorsque vous triez un incident en direct et devez rester limité au symptôme rapporté. Pour une première passe sur un nouveau rapport de bug, ou lorsque vous souhaitez une analyse plus large qui pourrait détecter des problèmes adjacents, une session de débogage simple, ou une passe de revue dédiée, peut couvrir un terrain que la compétence ne couvrira pas. Consultez nos meilleures compétences de codage pour voir comment nous classons les compétences de débogage et de revue les unes par rapport aux autres.

---

Le Banc d'Essai des Compétences, partie 3 sur 4. Lisez les autres comparaisons contrôlées : partie 1, la construction de la page d'atterrissage, partie 2, le bot Telegram, et partie 4, l'audit de Google zx.