Skill Bench: systematisk-felsökning vs. baslinje

Del 3 av Skill Bench ställer en snävare fråga än de två första: inte "hjälper en förmåga", utan "slår en förmåga byggd för en uppgift en oassisterad modell som utför exakt samma uppgift". Felsökning är det renaste testet vi har för detta, eftersom vi kan plantera buggarna själva, veta exakt vad som är fel och kontrollera rapporten mot sanningen rad för rad.

Så vi skrev ett canvas Snake-spel, bröt det medvetet på tre specifika sätt och körde samma trasiga spel och samma klagomål genom två identiska Claude Sonnet-sessioner. En hade systematic-debugging-förmågan installerad. En hade det inte. Samma prompt, samma modell, samma bugg. Endast förmågan skiljer sig.

Resultatet var inte den klara vinst vi förväntade oss, och det är den delen som är värd att läsa.

Fällan vi byggde

Vi utgick från en fungerande Snake-implementering och planterade sedan medvetet tre buggar:

1. Inverterade riktningsvektorer. ArrowUp och ArrowDown kopplades till de vektorer man skulle använda i normala kartesiska koordinater, inte canvas-koordinater, där y ökar nedåt. Tryck upp, ormen går ner.
2. Mat spawnar i pixelutrymme istället för rutnätsutrymme. spawnFood använde cv.width (400 pixlar) som gräns för en koordinat som skulle vara ett rutnätsindex i ett 20-cellers rutnät (GRID). Multiplicera ett rutnätssteg med ett 400-brett intervall och du får matkoordinater som hamnar utanför den synliga spelplanen ungefär 95% av tiden.
3. Poäng ökar varje tick. score++ låg i huvudspelloopen istället för inuti "ormen åt mat"-grenen, så poängen ökade varje bildruta oavsett vad ormen faktiskt gjorde.

Vi berättade inte för någon av Claude-sessionerna vad som var fel. Vi gav båda armarna samma buggrapport i spelarstil, formulerad som en faktiskt irriterad testare skulle uttrycka det: "kontrollerna känns fel, mat dyker aldrig upp, poängen klättrar av sig själv." Sedan bad vi varje session att hitta och åtgärda allt som orsakade detta.

Tre buggar, ett ärligt klagomål, två Claudes. Här är vad som kom tillbaka.

Vad varje arm rapporterade

Baslinje (ingen förmåga)

Baslinjesessionen arbetade igenom koden utan någon påtvingad metod, läste inmatningshanteraren, matspawnaren och spelloopen i tur och ordning. Den hittade alla tre planterade buggar:

• Riktingsvektorerna var omvända för y-axeln i förhållande till hur canvas-rendering behandlar "ner".
• spawnFood multiplicerade cv.width där den borde ha använt rutnätskonstanten, vilket producerade koordinater i pixel-skala i ett cellindexerat spel.
• Poängökningen låg utanför kollisionskontrollen med mat, så den triggades ovillkorligt varje bildruta.

Sedan fortsatte den att läsa och hittade ett fjärde problem som ingen hade planterat: självkollisionskontrollen jämförde ormens huvud med svanscellen innan svansen hade tagits bort för den bildrutan. När ormen rör sig in i rutan som dess egen svans lämnar, ser kontrollen fortfarande den rutan som upptagen och kallar det en kollision. Det är ett verkligt, välkänt Snake-kantfall. Det fanns i vår kod eftersom vi skrev kollisionslogiken innan vi planterade något, och baslinjen råkade bara läsa tillräckligt långt för att stöta på det.

Förmågsarm (systematic-debugging installerad)

Förmågsarmen läste obra/superpowers' systematic-debugging SKILL.md först (en förmåga vi separat har betygsatt 9.6/10 för hypotesdriven grundorsaksanalys), och tillämpade sedan sin metod: formulera en hypotes för varje symptom, testa den mot koden, bekräfta innan något ändras.

Den hittade samma tre planterade buggar, med snävare, mer precisa formuleringar av grundorsaken:

• "Riktningsinversion spårad till canvas y-ner-konvention: ArrowUp mappas till {x:0,y:-1} förutsatt kartesisk y-upp, men canvas renderar y ökande nedåt, så upp och ner är omvända."
• "Mat-spawn använder pixel-utrymmesgräns (cv.width = 400) där beräkningen borde använda rutnäts-utrymmesgräns (GRID = 20). Bekräftat av enhetsfel: att multiplicera en slumpmässig bråkdel i rutnäts-skala med en gräns i pixel-skala placerar ~95% av spawns utanför canvas.width."
• "Poäng ökar ovillkorligt i tick-loopen istället för att vara begränsad till grenen för mat-äten. Bekräftat genom att spåra loopkroppen: score++ exekveras innan kollisionskontrollen körs, varje bildruta."

Den hittade inte den fjärde buggen. Självkollisionsproblemet dök aldrig upp, eftersom de rapporterade symptomen (felaktiga kontroller, saknad mat, skenande poäng) inte pekade på kollisionslogik, och förmågans hypotesdrivna metod förblir förankrad i de symptom den fick. Den avslutade rapporten övertygad om att alla problem var lösta, och enligt klagomålets ordalydelse var de det.

Den fjärde buggens oväntade vändning

Detta är den vändning vi verifierade manuellt, genom att läsa om båda diffarna mot den faktiska koden: förmågsarmen var mer precis om de buggar den ombads hitta, och baslinjearmen hittade en verklig bugg till som ingen frågade om.

Det är ingen kritik mot systematic-debugging som förmåga. Hypotesdriven felsökning är byggd för att göra exakt vad den gjorde här: ta ett rapporterat symptom, avgränsa till en testbar orsak, bekräfta innan fixning, och sluta när symptomet är förklarat. Den disciplinen är exakt poängen när du står inför en produktionsincident med en stack trace och en tickande klocka. Den är också, per konstruktion, symptom-avgränsad. Den vandrar inte in i kod som inte är implicerad av klagomålet.

Baslinjesessionen hade ingen sådan avgränsning. Den läste mer av filen än den strikt behövde, och att läsa mer av filen är hur man snubblar över en bugg som ingen nämnde. Fri utforskning är ineffektiv per design, och här betalade ineffektiviteten sig.

Den ärliga tolkningen: ingen av armarna är "bättre" i allmänhet. Den ena armen är precis och billig i uppmärksamhet, förankrad i vad den fick veta. Den andra är ofokuserad och, denna gång, tillräckligt grundlig för att fånga något som ärendet inte nämnde. Om din buggrapport är komplett är förmågsarmens rapport den du vill läsa. Om din buggrapport kan sakna något, vill du ha det andra paret ögon som baslinjen gav dig gratis.

Siffrorna

	Baslinje (ingen förmåga)	Förmågsarm (systematic-debugging)
Hittade buggar (av 3 planterade)	3 / 3	3 / 3
Oplanterad verklig bugg hittad	Ja (tail-vacate kollision)	Nej
Grundorsaksprecision	Korrekt, mindre formaliserad	Korrekt, namngiven mekanism per bugg
Rapportstruktur	Ad hoc	Hypotes → test → bekräfta, per bugg
Använda tokens	50,338	58,357
Token delta	—	+16%

Förmågan kostade 16% fler tokens för en rapport som läser bättre och fastställer mekanismen mer precist, men den överträffade inte en baslinje som helt enkelt tilläts fortsätta läsa. Det är fyndet vi inte förväntade oss när vi började, och det är anledningen till att vi publicerar den råa jämförelsen istället för en dom som smickrar förmågan.

När du vill ha systematic-debugging

Snake-bänken underskattar förmågans verkliga värde, eftersom ett spel med planterade buggar med en fullständig källfil i sikte är nära det bästa fallet för en oassisterad modell: allt relevant får plats i en enda läsning. Produktionsfelsökning ser sällan ut så.

Där hypotesdriven grundorsaksanalys gör sig förtjänt är vid buggar som återkommer. I våra egna katalognoter om systematic-debugging var ett testfall en race condition som Claude redan hade "fixat" tre separata gånger i samma kodbas, varje gång genom att lappa en plausibel gissning istället för den faktiska orsaken. Förmågans disciplin (ange hypotesen, designa ett test som skulle falsifiera den, rör inte koden förrän testet bekräftar den) var det som slutligen fastställde den verkliga interaktionen istället för att producera en fjärde gissning. Det är den typ av bugg systematic-debugging är till för: återkommande, svårfångade, gissade på tre gånger redan, i en kodbas som är för stor för att läsa från början till slut på ett infall.

Det är också rätt verktyg i det ögonblick du triagerar en produktionsincident. Du har ett symptom, en klocka och ingen lust att en modell vandrar iväg för att läsa orelaterade moduler. Avgränsa till rapporten, bekräfta orsaken, leverera fixen. Det är en funktion, inte en begränsning, i just den inställningen.

När en fri genomsökning vinner

Vårt Snake-resultat argumenterar också för det motsatta fallet: när du misstänker att buggrapporten är ofullständig, eller när du gör en genomgång före release snarare än att jaga ett rapporterat symptom, gör en obegränsad läsning av koden något som en hypotesdriven metod strukturellt inte kommer att göra. Den tittar på kod som ingen har klagat på ännu.

Det är samma form som en manuell kodgranskning kontra en riktad incidentrespons. Båda har sin plats. Misstaget är att anta att en felsökningsförmåga ersätter en granskningsrunda snarare än att kompletterar den. Om du vill ha den allmänna granskningsvinkeln på detta, se vår syn på varför förmågor inte alltid triggas som du förväntar dig och hur vi strukturerar dessa tester.

Återskapa det själv

Bänken är liten nog att återskapa på tjugo minuter om du vill kontrollera våra siffror snarare än att lita på dem. Skriv ett canvas Snake-spel (rutnätsrörelse, en matspawnare, en poängräknare, en spelloop) och plantera dessa tre defekter:

1. Koppla ArrowUp/ArrowDown till kartesiska vektorer (y: 1 för upp, y: -1 för ner) istället för canvas-stilvektorer, där ökande y flyttar ner på skärmen.
2. I din food-spawn-funktion, multiplicera din slumpmässiga bråkdel med canvasens pixelbredd istället för ditt antal rutnätsrutor, så att den resulterande koordinaten är ett pixelvärde som behandlas som ett rutnätsindex.
3. Flytta poängökningen ut ur grenen "landade huvudet precis på mat" och in i den ovillkorliga kroppen av spelloopen.

Ge en Claude-session endast spelarklagomålet ("kontrollerna känns fel, mat dyker aldrig upp, poängen klättrar av sig själv"), aldrig bugglistan, och se vad som kommer tillbaka. Läs sedan din egen kollisionslogik för tail-vacate-fallet: kontrollera huvudets nästa position mot svansens nuvarande cell innan svansen rör sig, och se om den finns där också. Vår fanns där, utan att vi planterade den.

FAQ

Gör systematic-debugging-förmågan Claude sämre på att hitta buggar?

Nej. Den hittade varje planterad bugg med mer precisa grundorsaker än baslinjen. Vad den inte gjorde var att överskrida omfattningen av de rapporterade symptomen, vilket var det som lät baslinjen snubbla över en fjärde, oplanterad bugg. Omfattningsdisciplin är förmågans designintention, inte en defekt.

Varför hittade baslinjen en bugg som förmågan missade?

Baslinjen hade ingen hypotes att förbli förankrad i, så den läste mer av kodbasen än vad de rapporterade symptomen strikt krävde. Att läsa mer kod är hur man hittar saker som ingen frågade om. Det är en ineffektiv strategi som råkade löna sig en gång, inte en allmän fördel.

Är en 16% tokenökning värd det för en felsökningsförmåga?

Beror på buggen. För ett återkommande, svårt att fastställa problem är disciplinen värd betydligt mer än 16% i tokens, eftersom alternativet är att Claude gissar på samma orsak upprepade gånger, som den gjorde i vårt eget katalogtest innan vi tillämpade denna förmåga. För en bugg som redan är välavgränsad och ytlig, ger överheaden dig en renare rapport och inte mycket annat.

Ska jag använda systematic-debugging för varje buggfix?

Inte för varje. Använd den när en bugg återkommer, när ett tidigare fixförsök inte höll, eller när du triagerar en live-incident och behöver hålla dig inom ramen för det rapporterade symptomet. För en första genomgång av en ny buggrapport, eller när du vill ha en bredare genomsökning som kan fånga upp angränsande problem, kan en vanlig felsökningssession, eller en dedikerad granskningsrunda, täcka mark som förmågan inte gör. Se våra bästa kodningsförmågor för hur vi rankar felsöknings- och granskningsförmågor mot varandra.

---

Skill Bench, del 3 av 4. Läs de andra kontrollerade jämförelserna: del 1, byggandet av landningssidan, del 2, Telegram-botten, och del 4, granskning av Google zx.