De Skill Bench: systematisch debuggen vs. baseline

Deel 3 van de Skill Bench stelt een specifiekere vraag dan de eerste twee: niet "helpt een skill," maar "verslaat een skill, gebouwd voor één taak, een onondersteund model dat exact die taak uitvoert." Debuggen is de meest duidelijke test die we hiervoor hebben, omdat we de bugs zelf kunnen plaatsen, precies weten wat er mis is, en het rapport regel voor regel kunnen controleren tegen de grondwaarheid.

Dus schreven we een canvas Snake-game, braken deze opzettelijk op drie specifieke manieren, en voerden dezelfde kapotte game en dezelfde klacht door twee identieke Claude Sonnet-sessies. Eén had de systematic-debugging skill geïnstalleerd. Eén niet. Dezelfde prompt, hetzelfde model, dezelfde bug. Alleen de skill verschilt.

Het resultaat was niet de duidelijke overwinning die we vooraf verwachtten, en dat is het deel dat het lezen waard is.

De val die we bouwden

We begonnen met een werkende Snake-implementatie en plaatsten vervolgens opzettelijk drie bugs:

1. Omgekeerde richtingsvectoren. ArrowUp en ArrowDown waren gekoppeld aan de vectoren die je zou gebruiken in normale Cartesische coördinaten, niet canvascoördinaten, waar y naar beneden toeneemt. Druk op omhoog, de slang gaat naar beneden.
2. Voedsel spawnen in pixelruimte in plaats van rasterruimte. spawnFood gebruikte cv.width (400 pixels) als grens voor een coördinaat dat een rasterindex had moeten zijn in een 20-cellen raster (GRID). Vermenigvuldig een rasterstap met een 400-brede reeks en je krijgt voedselcoördinaten die ongeveer 95% van de tijd buiten het zichtbare bord landen.
3. Score verhoogt elke tick. score++ bevond zich in de hoofdgameloop in plaats van binnen de "slang at voedsel"-tak, dus de score steeg bij elk frame, ongeacht wat de slang daadwerkelijk deed.

We vertelden geen van beide Claude-sessies wat er mis was. We gaven beide takken hetzelfde bugrapport in spelersstijl, geformuleerd zoals een daadwerkelijk geïrriteerde tester het zou formuleren: "besturing voelt verkeerd, voedsel verschijnt nooit, score stijgt vanzelf." Vervolgens vroegen we elke sessie om alles te vinden en te repareren wat dat veroorzaakte.

Drie bugs, één eerlijke klacht, twee Claudes. Dit is wat er terugkwam.

Wat elke tak rapporteerde

Baseline (geen skill)

De baseline-sessie werkte door de code zonder enige opgelegde methode, waarbij achtereenvolgens de input handler, de food spawner en de gameloop werden gelezen. Het stuitte op alle drie de geplaatste bugs:

• Richtingsvectoren waren omgedraaid voor de y-as ten opzichte van hoe canvas rendering "beneden" behandelt.
• spawnFood vermenigvuldigde cv.width waar het de rasterconstante had moeten gebruiken, wat pixel-schaal coördinaten opleverde in een cel-geïndexeerde game.
• De scoreverhoging bevond zich buiten de botsing-met-voedsel controle, dus deze werd onvoorwaardelijk bij elk frame geactiveerd.

Daarna bleef het lezen en vond een vierde probleem dat niemand had geplaatst: de zelfbotsingscontrole vergeleek de kop van de slang met de staartcel voordat de staart voor dat frame was verwijderd. Wanneer de slang in het vakje beweegt dat zijn eigen staart verlaat, ziet de controle dat vakje nog steeds als bezet en noemt het een botsing. Dat is een echt, bekend Snake edge case. Het bestond in onze code omdat we de botsingslogica schreven voordat we iets plaatsten, en de baseline las toevallig ver genoeg om het te vinden.

Skill-tak (systematic-debugging geïnstalleerd)

De skill-tak las eerst obra/superpowers' systematic-debugging SKILL.md (een skill die we afzonderlijk 9.6/10 hebben gescoord voor hypothese-gedreven root-causing), en paste vervolgens de methode toe: vorm een hypothese voor elk symptoom, test deze tegen de code, bevestig voordat je iets aanraakt.

Het vond dezelfde drie geplaatste bugs, met strakkere, preciezere root-cause taal:

• "Richtingomkering herleid tot canvas y-naar-beneden conventie: ArrowUp koppelt aan {x:0,y:-1} uitgaande van Cartesische y-omhoog, maar het canvas rendert y toenemend naar beneden, dus omhoog en omlaag zijn verwisseld."
• "Voedsel spawn gebruikt pixel-ruimte grens (cv.width = 400) waar de berekening raster-ruimte grens (GRID = 20) zou moeten gebruiken. Bevestigd door eenheidswijziging: het vermenigvuldigen van een willekeurige raster-schaal fractie met een pixel-schaal grens plaatst ~95% van de spawns buiten canvas.width."
• "Score verhoogt onvoorwaardelijk in de tick-loop in plaats van te worden beperkt door de voedsel-gegeten tak. Bevestigd door het traceren van de loop body: score++ wordt uitgevoerd voordat de botsingscontrole loopt, bij elk frame."

Het vond de vierde bug niet. Het zelfbotsingsprobleem kwam nooit naar boven, omdat de gerapporteerde symptomen (verkeerde besturing, ontbrekend voedsel, weglopende score) niet wezen op botsingslogica, en de hypothese-gedreven methode van de skill blijft verankerd aan de symptomen die het kreeg. Het sloot het rapport af, ervan overtuigd dat alle problemen waren opgelost, en volgens de letter van de klacht waren ze dat ook.

De plotwending van de vierde bug

Dit is de wending die we handmatig hebben geverifieerd, door beide diffs opnieuw te lezen tegen de daadwerkelijke code: de skill-tak was preciezer over de bugs die het moest vinden, en de baseline-tak vond nog één echte bug waar niemand om vroeg.

Dat is geen kritiek op systematic-debugging als skill. Hypothese-gedreven debuggen is gebouwd om precies te doen wat het hier deed: een gerapporteerd symptoom nemen, vernauwen tot een testbare oorzaak, bevestigen voordat je repareert, en stoppen zodra het symptoom is verklaard. Die discipline is precies het punt wanneer je naar een productie-incident staart met een stack trace en een tikkende klok. Het is ook, van nature, symptoom-gericht. Het dwaalt niet af naar code die niet wordt geïmpliceerd door de klacht.

De baseline-sessie had zo'n scope niet. Het las meer van het bestand dan strikt noodzakelijk was, en meer van het bestand lezen is hoe je stuit op een bug die niemand heeft genoemd. Vrije verkenning is van nature inefficiënt, en hier betaalde de inefficiëntie zichzelf terug.

De eerlijke lezing: geen van beide takken is over het algemeen "beter". De ene tak is precies en zuinig met aandacht, verankerd aan wat het werd verteld. De andere is ongericht en, deze keer, grondig genoeg om iets te vangen wat de ticket niet vermeldde. Als je bugrapport compleet is, is het rapport van de skill-tak degene die je wilt lezen. Als je bugrapport mogelijk iets mist, wil je het tweede paar ogen dat de baseline je gratis gaf.

De cijfers

| | Baseline (geen skill) | Skill-tak (systematic-debugging) | |---| | Gevonden bugs (van 3 geplaatst) | 3 / 3 | 3 / 3 | | Ongeplaatste echte bug gevonden | Ja (staart-verlating botsing) | Nee | | Precisie root-cause | Correct, minder geformaliseerd | Correct, benoemd mechanisme per bug | | Rapportstructuur | Ad hoc | Hypothese → test → bevestig, per bug | | Gebruikte tokens | 50,338 | 58,357 | | Token delta | — | +16% |

De skill kostte 16% meer tokens voor een rapport dat beter leest en het mechanisme preciezer vastlegt, maar het overtrof geen baseline die simpelweg mocht blijven lezen. Dat is de bevinding die we niet verwachtten, en het is de reden dat we de ruwe vergelijking publiceren in plaats van een oordeel dat de skill vleit.

Wanneer je systematic-debugging wilt

De Snake bench onderschat de werkelijke waarde van de skill, omdat een game met geplaatste bugs en een volledig bronbestand in beeld dicht bij het beste geval komt voor een onondersteund model: alles wat relevant is, past in één lezing. Productiedebugging ziet er zelden zo uit.

Waar hypothese-gedreven root-causing zijn waarde bewijst, is bij de bug die terugkomt. In onze eigen catalogusnotities over systematic-debugging was één testcase een race condition die Claude al drie keer afzonderlijk had "opgelost" in dezelfde codebase, elke keer een aannemelijke gok patchte in plaats van de werkelijke oorzaak. De discipline van de skill (stel de hypothese, ontwerp een test die deze zou weerleggen, raak de code niet aan totdat de test deze bevestigt) was wat uiteindelijk de echte interactie vastpinde in plaats van een vierde gok te produceren. Dat is het type bug waar systematic-debugging voor is: terugkerend, ontwijkend, al drie keer geraden, in een codebase die te groot is om zomaar van begin tot eind te lezen.

Het is ook de juiste tool op het moment dat je een productie-incident triageert. Je hebt een symptoom, een klok, en geen zin in een model dat afdwaalt om ongerelateerde modules te lezen. Scope naar het rapport, bevestig de oorzaak, lever de fix. Dat is een feature, geen beperking, precies in die setting.

Wanneer een vrije sweep wint

Ons Snake-resultaat pleit ook voor het tegenovergestelde: wanneer je vermoedt dat het bugrapport onvolledig is, of wanneer je een pre-release pass uitvoert in plaats van één gerapporteerd symptoom na te jagen, doet een onbeperkte lezing van de code iets wat een hypothese-gedreven methode structureel niet zal doen. Het kijkt naar code waar nog niemand over heeft geklaagd.

Dat is dezelfde vorm als een handmatige codereview versus een gerichte incidentrespons. Beide hebben hun plaats. De fout is om aan te nemen dat een debugging skill een review pass vervangt in plaats van ernaast te bestaan. Als je de algemene review-pass invalshoek hierop wilt, zie onze visie waarom skills niet altijd triggeren zoals je verwacht en hoe we deze tests structureren.

Reproduceer het zelf

De bench is klein genoeg om in twintig minuten opnieuw op te bouwen als je onze cijfers wilt controleren in plaats van ze op goed geloof aan te nemen. Schrijf een canvas Snake-game (rasterbeweging, een food spawner, een scoreteller, een gameloop) en plaats deze drie defecten:

1. Koppel ArrowUp/ArrowDown aan Cartesische vectoren (y: 1 voor omhoog, y: -1 voor omlaag) in plaats van canvas-stijl vectoren, waarbij toenemende y naar beneden op het scherm beweegt.
2. Vermenigvuldig in je food-spawn functie je willekeurige fractie met de pixelbreedte van het canvas in plaats van je rastercelaantal, zodat de resulterende coördinaat een pixelwaarde is die als rasterindex wordt behandeld.
3. Verplaats de scoreverhoging uit de "landde de kop net op voedsel"-tak en in de onvoorwaardelijke body van de gameloop.

Geef een Claude-sessie alleen de klacht van de speler ("besturing voelt verkeerd, voedsel verschijnt nooit, score stijgt vanzelf"), nooit de buglijst, en kijk wat er terugkomt. Lees vervolgens je eigen botsingslogica voor het staart-verlatingsgeval: controleer de volgende positie van de kop tegen de huidige cel van de staart voordat de staart beweegt, en zie of het daar ook is. Bij ons was dat het geval, zonder dat wij het plantten.

Veelgestelde vragen

Maakt de systematic-debugging skill Claude slechter in het vinden van bugs?

Nee. Het vond elke geplaatste bug met preciezere root causes dan de baseline. Wat het niet deed, was de scope van de gerapporteerde symptomen overschrijden, wat de baseline in staat stelde om op een vierde, ongeplaatste bug te stuiten. Scopediscipline is de ontwerpintentie van de skill, geen defect.

Waarom vond de baseline een bug die de skill miste?

De baseline had geen hypothese om aan vast te houden, dus las het meer van de codebase dan de gerapporteerde symptomen strikt vereisten. Meer code lezen is hoe je dingen vindt waar niemand om vroeg. Het is een inefficiënte strategie die toevallig één keer vruchten afwierp, geen algemeen voordeel.

Is een toename van 16% in tokens de moeite waard voor een debugging skill?

Hangt af van de bug. Voor een terugkerend, moeilijk te traceren probleem is de discipline veel meer waard dan 16% in tokens, omdat het alternatief is dat Claude herhaaldelijk dezelfde oorzaak raadt, zoals het deed in onze eigen catalogustest voordat we deze skill toepasten. Voor een bug die al goed is afgebakend en oppervlakkig, levert de overhead je een schoner rapport op en niet veel meer.

Moet ik systematic-debugging gebruiken voor elke bugfix?

Niet elke keer. Gebruik het wanneer een bug terugkeert, wanneer een eerdere fixpoging niet bleef plakken, of wanneer je een live incident triageert en binnen de scope van het gerapporteerde symptoom moet blijven. Voor een eerste pass op een nieuw bugrapport, of wanneer je een bredere sweep wilt die aangrenzende problemen kan vangen, kan een gewone debugsessie, of een speciale review pass, terrein bestrijken dat de skill niet zal doen. Zie onze beste coding skills voor hoe we debugging- en review skills tegen elkaar afwegen.

---

De Skill Bench, deel 3 van 4. Lees de andere gecontroleerde vergelijkingen: deel 1, de landing page build, deel 2, de Telegram bot, en deel 4, auditing Google zx.