Skill Bench: systematisk feilsøking vs. baseline

Del 3 av Skill Bench stiller et smalere spørsmål enn de to første: ikke "hjelper en ferdighet," men "slår en ferdighet bygget for én oppgave en uassistert modell som utfører nøyaktig den oppgaven." Feilsøking er den reneste testen vi har for dette, fordi vi kan plante feilene selv, vite nøyaktig hva som er galt, og sjekke rapporten mot fasiten linje for linje.

Så vi skrev et canvas Snake-spill, brøt det med vilje på tre spesifikke måter, og kjørte det samme ødelagte spillet og den samme klagen gjennom to identiske Claude Sonnet-sesjoner. Den ene hadde systematic-debugging-ferdigheten installert. Den andre hadde det ikke. Samme prompt, samme modell, samme feil. Bare ferdigheten er forskjellig.

Resultatet var ikke den klare seieren vi forventet, og det er den delen som er verdt å lese.

Fellen vi bygde

Vi startet fra en fungerende Snake-implementasjon, og plantet deretter tre feil med vilje:

1. Inverterte retningsvektorer. ArrowUp og ArrowDown var koblet til vektorene du ville brukt i normale kartesiske koordinater, ikke canvas-koordinater, der y øker nedover. Trykk opp, slangen går ned.
2. Mat gyter i pikselrom i stedet for rutenettrom. spawnFood brukte cv.width (400 piksler) som grense for en koordinat som skulle være en rutenettindeks i et 20-cellers rutenett (GRID). Multipliser et rutenettsteg med et 400-bredt område, og du får matkoordinater som lander utenfor det synlige brettet omtrent 95% av tiden.
3. Poeng øker for hver tick. score++ satt i hovedspillsløyfen i stedet for inne i "slangen spiste mat"-grenen, så poengsummen steg for hver ramme uavhengig av hva slangen faktisk gjorde.

Vi fortalte ingen av Claude-sesjonene hva som var galt. Vi ga begge armene den samme feilrapporten i spillerstil, formulert slik en faktisk irritert tester ville formulert den: "kontrollene føles feil, mat dukker aldri opp, poengsummen stiger av seg selv." Deretter ba vi hver sesjon om å finne og fikse alt som forårsaket dette.

Tre feil, én ærlig klage, to Claudes. Her er hva som kom tilbake.

Hva hver arm rapporterte

Baseline (ingen ferdighet)

Baselinesesjonen jobbet gjennom koden uten noen pålagt metode, og leste inndatahåndtereren, matgyteren og spillsløyfen etter tur. Den fant alle de tre plantede feilene:

• Retningsvektorer var snudd for y-aksen i forhold til hvordan canvas-rendering behandler "ned".
• spawnFood multipliserte cv.width der den skulle ha brukt rutenettkonstanten, og produserte piksel-skala koordinater i et celleindeksert spill.
• Poengøkningen satt utenfor kollisjonskontrollen med mat, så den ble utløst ubetinget hver ramme.

Deretter fortsatte den å lese, og fant et fjerde problem som ingen hadde plantet: selvkollisjonskontrollen sammenlignet slangens hode med halecellen før halen var fjernet for den rammen. Når slangen beveger seg inn i ruten dens egen hale forlater, ser kontrollen fortsatt den ruten som opptatt og kaller det en kollisjon. Det er et reelt, velkjent Snake-grensetilfelle. Det eksisterte i koden vår fordi vi skrev kollisjonslogikken før vi plantet noe, og baselinjen leste tilfeldigvis langt nok til å finne det.

Ferdighetsarm (systematic-debugging installert)

Ferdighetsarmen leste først obra/superpowers' systematic-debugging SKILL.md (en ferdighet vi separat har scoret 9.6/10 for hypotesedrevet årsaksanalyse), og anvendte deretter sin metode: formuler en hypotese for hvert symptom, test den mot koden, bekreft før du rører noe.

Den fant de samme tre plantede feilene, med strammere, mer presis årsaksbeskrivelse:

• "Retningsinversjon sporet til canvas y-ned-konvensjon: ArrowUp mapper til {x:0,y:-1} forutsatt kartesisk y-opp, men canvas gjengir y økende nedover, så opp og ned er byttet om."
• "Matgyting bruker pikselromsgrense (cv.width = 400) der beregningen skulle brukt rutenettromsgrense (GRID = 20). Bekreftet av enhetsuoverensstemmelse: å multiplisere en tilfeldig rutenett-skala brøk med en piksel-skala grense plasserer ~95% av gytingene utenfor canvas.width."
• "Poeng øker ubetinget i tick-sløyfen i stedet for å være begrenset av mat-spist-grenen. Bekreftet ved å spore sløyfekroppen: score++ utføres før kollisjonskontrollen kjører, på hver ramme."

Den fant ikke den fjerde feilen. Selvkollisjonsproblemet dukket aldri opp, fordi de rapporterte symptomene (feil kontroller, manglende mat, løpsk poengsum) ikke pekte på kollisjonslogikk, og ferdighetens hypotesedrevne metode forblir forankret i symptomene den ble gitt. Den avsluttet rapporten trygg på at alle problemer var løst, og ifølge klagens ordlyd var de det.

Den fjerde feilens plottvist

Dette er tvisten vi verifiserte manuelt, ved å lese begge diffene mot den faktiske koden: ferdighetsarmen var mer presis om feilene den ble bedt om å finne, og baseline-armen fant en reell feil til som ingen spurte om.

Det er ikke en kritikk av systematic-debugging som ferdighet. Hypotesedrevet feilsøking er bygget for å gjøre nøyaktig det den gjorde her: ta et rapportert symptom, snevre inn til en testbar årsak, bekreft før du fikser, og stopp når symptomet er forklart. Den disiplinen er nettopp poenget når du stirrer på en produksjonshendelse med en stack trace og en klokke som tikker. Den er også, per konstruksjon, symptom-avgrenset. Den vandrer ikke inn i kode som ikke er implisert av klagen.

Baselinesesjonen hadde ingen slik avgrensning. Den leste mer av filen enn den strengt tatt trengte, og å lese mer av filen er hvordan du snubler over en feil ingen nevnte. Fri-roaming utforskning er ineffektivt av design, og her betalte ineffektiviteten seg.

Den ærlige lesningen: ingen av armene er "bedre" generelt. Den ene armen er presis og billig i oppmerksomhet, forankret i det den ble fortalt. Den andre er ufokusert og, denne ene gangen, grundig nok til å fange noe billetten ikke nevnte. Hvis feilrapporten din er komplett, er ferdighetsarmens rapport den du vil lese. Hvis feilrapporten din kan mangle noe, vil du ha det andre paret øyne baselinen ga deg gratis.

Tallene

	Baseline (ingen ferdighet)	Ferdighetsarm (systematic-debugging)
Feil funnet (av 3 plantede)	3 / 3	3 / 3
Uplantet reell feil funnet	Ja (hale-forlat kollisjon)	Nei
Årsakspresisjon	Korrekt, mindre formalisert	Korrekt, navngitt mekanisme per feil
Rapportstruktur	Ad hoc	Hypotese → test → bekreft, per feil
Tokens brukt	50,338	58,357
Token delta	—	+16%

Ferdigheten kostet 16% flere tokens for en rapport som leser bedre og spesifiserer mekanismen mer presist, men den fant ikke flere feil enn en baseline som rett og slett fikk fortsette å lese. Det er funnet vi ikke forventet da vi startet, og det er grunnen til at vi publiserer den rå sammenligningen i stedet for en dom som smigrer ferdigheten.

Når du vil ha systematic-debugging

Snake-benken underdriver ferdighetens virkelige verdi, fordi et spill med plantede feil med en full kildekodefil i sikte er nær det beste tilfellet for en uassistert modell: alt relevant passer i én lesing. Produksjonsfeilsøking ser sjelden slik ut.

Der hypotesedrevet årsaksanalyse virkelig kommer til sin rett, er feilen som kommer tilbake. I våre egne katalognotater om systematic-debugging var ett testtilfelle en race condition som Claude allerede hadde "fikset" tre separate ganger i samme kodebase, hver gang ved å lappe en plausibel gjetning i stedet for den faktiske årsaken. Ferdighetens disiplin (angi hypotesen, design en test som ville falsifisere den, ikke rør koden før testen bekrefter det) var det som endelig festet den virkelige interaksjonen i stedet for å produsere en fjerde gjetning. Det er den typen feil systematic-debugging er for: tilbakevendende, unnvikende, gjettet på tre ganger allerede, i en kodebase som er for stor til å lese ende til ende på et innfall.

Det er også det rette verktøyet i det øyeblikket du triager en produksjonshendelse. Du har et symptom, en klokke, og ingen appetitt for en modell som vandrer av gårde for å lese urelaterte moduler. Avgrens til rapporten, bekreft årsaken, send ut fiksen. Det er en funksjon, ikke en begrensning, i akkurat den settingen.

Når en fri gjennomgang vinner

Vårt Snake-resultat argumenterer også for det motsatte: når du mistenker at feilrapporten er ufullstendig, eller når du utfører en før-utgivelsesgjennomgang i stedet for å jage et rapportert symptom, gjør en ubegrenset lesing av koden noe en hypotesedrevet metode strukturelt ikke vil. Den ser på kode ingen har klaget på ennå.

Det er samme form som en manuell kodegjennomgang versus en målrettet hendelsesrespons. Begge har sin plass. Feilen er å anta at en feilsøkingsferdighet erstatter en gjennomgang, snarere enn å sitte ved siden av en. Hvis du vil ha den generelle gjennomgangsvinkelen på dette, se vår mening om hvorfor ferdigheter ikke alltid utløses som forventet og hvordan vi strukturerer disse testene.

Gjengi det selv

Benken er liten nok til å gjenoppbygge på tjue minutter hvis du vil sjekke tallene våre i stedet for å ta dem på tro. Skriv et canvas Snake-spill (rutenettbevegelse, en matgyter, en poengteller, en spillsløyfe) og plant disse tre feilene:

1. Koble ArrowUp/ArrowDown til kartesisk-stil vektorer (y: 1 for opp, y: -1 for ned) i stedet for canvas-stil vektorer, der økende y flytter seg nedover skjermen.
2. I din matgytefunksjon, multipliser din tilfeldige brøk med canvasens pikselbredde i stedet for ditt rutenettcelleantall, slik at den resulterende koordinaten er en pikselverdi som behandles som en rutenettindeks.
3. Flytt poengøkningen ut av "landet hodet akkurat på mat"-grenen og inn i den ubetingede kroppen av spillsløyfen.

Gi en Claude-sesjon kun spillerklagen ("kontrollene føles feil, mat dukker aldri opp, poengsummen stiger av seg selv"), aldri feillisten, og se hva som kommer tilbake. Les deretter din egen kollisjonslogikk for hale-forlat-tilfellet: sjekk hodets neste posisjon mot halens nåværende celle før halen beveger seg, og se om den er der også. Vår var det, uten at vi plantet den.

FAQ

Gjør systematic-debugging-ferdigheten Claude dårligere til å finne feil?

Nei. Den fant hver plantede feil med mer presise årsaker enn baselinen. Det den ikke gjorde, var å overskride omfanget av de rapporterte symptomene, noe som gjorde at baselinen snublet over en fjerde, uplantet feil. Omfangsdisiplin er ferdighetens designintensjon, ikke en defekt.

Hvorfor fant baselinen en feil ferdigheten gikk glipp av?

Baselinen hadde ingen hypotese å forankre seg til, så den leste mer av kodebasen enn de rapporterte symptomene strengt tatt krevde. Å lese mer kode er hvordan du finner ting ingen spurte om. Det er en ineffektiv strategi som tilfeldigvis lønnet seg én gang, ikke en generell fordel.

Er en 16% token-økning verdt det for en feilsøkingsferdighet?

Avhenger av feilen. For et tilbakevendende, vanskelig å identifisere problem, er disiplinen verdt langt mer enn 16% i tokens, fordi alternativet er at Claude gjetter på samme årsak gjentatte ganger, slik den gjorde i vår egen katalogtest før vi brukte denne ferdigheten. For en feil som allerede er godt avgrenset og overfladisk, gir overheaden deg en renere rapport og ikke mye annet.

Bør jeg bruke systematic-debugging for hver feilretting?

Ikke for hver. Bruk den når en feil er tilbakevendende, når et tidligere fiksforsøk ikke holdt, eller når du triager en live-hendelse og trenger å holde deg innenfor omfanget av det rapporterte symptomet. For en første gjennomgang av en fersk feilrapport, eller når du ønsker en bredere gjennomgang som kan fange opp tilstøtende problemer, kan en vanlig feilsøkingssesjon, eller en dedikert gjennomgang, dekke områder ferdigheten ikke vil. Se våre beste kodeferdigheter for hvordan vi rangerer feilsøkings- og gjennomgangsferdigheter mot hverandre.

---

Skill Bench, del 3 av 4. Les de andre kontrollerte sammenligningene: del 1, bygging av landingssiden, del 2, Telegram-boten, og del 4, revisjon av Google zx.