Skill Bench, del 2: Claude TDD-færdighed vs. ingen færdighed

Del 1 af denne serie satte en færdighed op mod en tom prompt på en scaffolding-opgave og opnåede en skæv sejr. Del 2 gør ikke. Vi byggede den samme Telegram-bot to gange med Claude Sonnet, gav den ene kørsel den højest scorede test-driven-development-færdighed i vores katalog, og færdigheden tilføjede tokens uden at tilføje en test, der betød noget. Vi udgiver dette resultat, som det er, fordi en benchmark, du kun udgiver, når færdigheden vinder, ikke er en benchmark.

Opsætning og metodologi

Dette er N=1. Én opgave, én model, én færdighed, kørt én gang per arm. Det er ikke nok data til at hævde en procentvis forskel i kvalitet, og vi vil ikke foregive andet. Hvad det er nok til, er at vise, hvad der faktisk sker i en enkelt session, linje for linje, hvilket er noget, de fleste færdighedsmarkedsføring aldrig viser dig.

Opgaven: byg en Telegram todo-bot på aiogram v3 med fire kommandoer, /add, /list, /done, /delete, understøttet af in-memory storage scoped per bruger. Briefet bad om en ren opdeling: storage.py indeholdende ren logik uden Telegram-imports, bot.py der forbinder den logik til aiogram-handlere, og test_storage.py der dækker storage-laget. Kør pytest indtil den er grøn, stop derefter.

Begge arme fik den identiske prompt, den identiske model (Claude Sonnet) og det identiske repo-scaffold at starte fra. Den eneste variabel: færdighedsarmen havde obra/superpowers' test-driven-development SKILL.md installeret, den samme færdighed, der scorede 9.6 ud af 10 i vores katalog for at håndhæve en streng red-green-refactor-cyklus og nægte at lade en session markere arbejde som udført, mens en test fejler. Baseline-armen havde intet installeret ud over standard Claude Code-adfærd. Den fulde metode til, hvordan vi skripter og logger disse kørsler, findes i hvordan vi tester Claude-færdigheder, og den bredere scoringsrubrik findes på vores metodologiside.

Hvad begge arme leverede

Begge arme blev færdige. Begge opnåede en fuldt grøn pytest-kørsel. Begge producerede den tre-fils opdeling, som briefet bad om, med storage-logik isoleret fra aiogram-handlerkoden. På overfladen ligner dette uafgjort, og hvis du stoppede med at læse ved "begge blev grønne", ville du konkludere, at færdigheden ikke gjorde nogen forskel og gå videre.

Ingen af bot.py-filerne gjorde noget overraskende. Hver især forbandt de fire kommandoer til aiograms Router- og Message-handlere, parsede todo-teksten eller indekset ud af kommandoargumenterne og kaldte direkte ind i storage-laget for det faktiske arbejde. Det var præcis, hvad briefet bad om: hold bot-filen tynd, hold logikken testbar. Med hensyn til aiogram-forbindelsen konvergerede de to sessioner næsten fuldstændigt, hvilket i sig selv er et nyttigt datapunkt. Hvor de divergerede, var udelukkende på storage-siden, i hvad hver især anså for at være værd at teste.

Forskellen viser sig i, hvad hver arm besluttede var værd at teste, og hvad det kostede at nå dertil.

Tallene

	Baseline (no skill)	Skill (test-driven-development)	Delta
Total tokens	48,536	52,480	+8%
Tests written	23	13	-10
Exception-path tests	9	5	-4
Final pytest status	Green	Green	Tie

Færdighedsarmen brugte flere tokens til at producere en mindre testsuite med mindre undtagelsesdækning. Det er hele resultatet. Ingen skjult asterisk, ingen "men hvis du ser på kodekvalitet i stedet for antal tests." Baseline-sessionen, der kørte uden nogen proces-scaffolding overhovedet, skrev næsten dobbelt så mange undtagelses-path-tilfælde.

Læsning af testsuiterne: 23 vs 13

Antal tests alene er et svagt signal, så vi læste begge suiter linje for linje i stedet for at stole på overskriftens tal.

Baselinens 23 tests dækkede de fire kommandoer på happy-path-niveau, og fortsatte derefter ind i edge cases, som ingen bad om ved navn: hvad der sker, når du markerer et indeks uden for rækkevidde som færdigt, hvad et nul- eller negativt indeks gør, om én brugers todo-liste lækker ind i en anden brugers, og om sletning af element 2 korrekt flytter indekserne for element 3 og 4, så /done 3 stadig peger på den rigtige opgave bagefter. Den sidste er den slags fejl, der overlever en demo og derefter bryder sammen foran en rigtig bruger første gang de sletter noget fra midten af en liste. Ni af de 23 tests eksisterede udelukkende for at prikke til disse undtagelses-paths.

Færdighedsarmens 13 tests dækkede de samme fire kommandoer på happy-path-niveau, plus fem undtagelses-path-tilfælde: for det meste indekser uden for rækkevidde og ét duplicate-add-scenarie. Hvad der mangler i forhold til baselinen: ingen eksplicit per-bruger isoleringstest, og ingen test, der bekræfter indeksadfærd efter en sletning flytter listen. Storage-logikken i færdighedsarmens storage.py kan meget vel håndtere disse tilfælde korrekt. Utestet korrekt adfærd og testet korrekt adfærd er dog ikke den samme påstand, og hele pointen med en testsuite er at lukke det hul.

Ingen af suiterne er dårlige. Tretten tests med fem undtagelsestilfælde på en fire-kommando bot er et forsvarligt udgangspunkt efter enhver normal ingeniørstandard. Sammenligningen ser kun fordømmende ud ved siden af en baseline, der, ud fra en identisk prompt uden red-green scaffolding overhovedet, skrev flere tests, ikke færre.

Hvorfor dette ikke modbeviser TDD

Her er det, en one-shot benchmark strukturelt ikke kan se: TDD's argument var aldrig "du vil skrive flere tests i dit første forsøg." Det handler om, hvad der sker over ugers iteration, på tværs af den tiende funktion tilføjet til en kodebase, som modellen ikke skrev fra bunden, på det tidspunkt, hvor en træt ingeniør (eller en agent under tidspres) fristes til at shippe med en rød test og rette den "senere."

Det er en disciplinpåstand, ikke en one-shot outputpåstand, og denne benchmark kørte præcis ét skud. Vi kan ikke måle disciplin i en enkelt session, fordi disciplin er det, der forhindrer dig i at springe over, hvor gærdet er lavest i session seks, og der er ingen session seks her.

Vi har et spor af, hvordan den disciplin ser ud i praksis, fra vores egne testnoter på test-driven-development færdighedssiden: på tværs af en tre-funktions session nægtede færdigheden at springe red-green-cyklussen over, selv når løsningen så indlysende ud, og fristelsen til at springe direkte til grøn var lige der. Den skrev den fejlede test først, så den fejle af den rigtige grund, og skrev derefter den minimale kode for at bestå den, hver gang, på tværs af alle tre funktioner. Ingen behøvede at gribe ind og sige "vent, skriv testen først." Det er den adfærd, en disciplinfærdighed forventes at levere, og det er ikke den samme adfærd som "skriver flere tests i ét forsøg på et lille, velafgrænset modul."

På en opgave af denne størrelse og så veldefineret var Claude Sonnets baseline-vurdering af, hvad der skulle testes, allerede solid. Færdigheden tilføjede en eksplicit proces oven på en vurdering, der endnu ikke behøvede meget korrektion, og den proces kostede 8% flere tokens uden en tilsvarende kvalitetsgevinst i dette specifikke forsøg. Begge ting kan være sande: TDD er værd at have installeret, og det hjalp ikke her.

Der er også en enklere forklaring, der er værd at nævne: at skrive en fejlet test, se den fejle, og derefter skrive den minimale kode for at bestå den, kræver mere frem og tilbage end at skrive implementeringen og en test for den i ét hug. Den overhead er pointen med disciplinen, når implementeringen er ikke-triviel, eller modellen er tilbøjelig til at springe frem. På en fire-kommando todo-bot var implementeringen aldrig i tvivl, så overheaden købte proces uden at købe en kontrol af noget, der faktisk var i fare for at gå galt.

Hvad dette betyder, hvis du køber færdigheder

Den ubehagelige del for os, specifikt, er, at vi sælger testede færdigheder, og vores egen testbænk viste netop en top-scorende færdighed, der ikke vandt en one-shot sammenligning mod ingen færdighed overhovedet. Vi vil hellere, at du ser det end en highlight-reel.

Den praktiske konklusion er at matche færdigheden til opgaven, ikke til scoren. En 9.6/10 katalogscore betyder, at færdigheden gør, hvad den lover pålideligt og ikke ødelægger din opsætning, ikke at den vinder hver benchmark på enhver opgavestørrelse. Hvis din opgave er et lille, veldefineret modul, du bygger fra bunden, i én omgang, kan en stærk models standardvurdering allerede dække de undtagelses-paths, du bekymrer dig om, og en procesfærdighed er overhead, du betaler for uden en tilsvarende fordel i den session. Hvis din opgave er en kodebase, du vil røre ved i måneder, med flere bidragydere og lange pauser mellem sessioner, hvor genveje ophobes i stilhed, er det, hvad en disciplinfærdighed som TDD er bygget til at forhindre, og en enkelt-session benchmark ville aldrig fange den værdi i første omgang.

Hastighedsfærdigheder og disciplinfærdigheder besvarer forskellige spørgsmål. Læs en færdigheds beskrivelse for at se, hvilket spørgsmål den besvarer, før du installerer den til den forkerte opgave. Vi dækker, hvordan man læser det signal i vores oversigt over de bedste kodningsfærdigheder.

Reproducer det selv

Opgaven er lille nok til at genkøre på en eftermiddag. Klon et bart aiogram v3-projekt, kør derefter den identiske prompt to gange: én gang i en ren Claude Code-session, én gang med obra/superpowers' test-driven-development-færdighed installeret. Bed om /add /list /done /delete med per-bruger in-memory storage, en storage.py/bot.py-opdeling og en pytest-suite, der kører grønt, før du erklærer den færdig. Log det samlede antal tokens fra hver sessions brugsoversigt, og diff derefter de to test_storage.py-filer manuelt: tæl assertions, og flag specifikt alt, der berører negative indekser, manglende nøgler, per-bruger isolering og indeksforskydninger efter en sletning. Disse fire kategorier er, hvor vi så hullet, og det er dem, der er værd at tjekke på enhver todo-stil CRUD-app, uanset hvilken færdighed du tester.

Ofte stillede spørgsmål

Betyder dette, at TDD-færdigheden er dårlig?

Nej. Det betyder, at en one-shot benchmark på et lille, veldefineret modul ikke er den test, der viser, hvad TDD er til for. Færdighedens værdi ligger i at forhindre genveje over en lang session eller et langt projekt, hvilket denne benchmark, per design, ikke kørte længe nok til at måle.

Hvorfor skrev færdighedsarmen færre tests, hvis den håndhæver en strengere proces?

Red-green-refactor-cyklussen driver dig til at skrive en test for den adfærd, du er ved at implementere, derefter implementere den, og derefter gå videre til den næste adfærd. Den beder dig ikke automatisk om at gå tilbage og tilføje tests for edge cases, som ingen eksplicit bad om, medmindre sessionen tager tid til at brainstorme dem separat. Baseline-armen, ubegrænset af en fast cyklus, brugte tilsyneladende mere af sit output på netop den brainstorming.

Skal jeg installere en TDD-færdighed til Claude Code?

Hvis du arbejder i en kodebase, du gentagne gange vil vende tilbage til, især med andre bidragydere eller lange pauser mellem sessioner, ja. Det er en forsikring mod en specifik fejltype: at shippe i stilhed med en rød test, fordi løsningen så indlysende ud. Den fejltype viser sig ikke i en enkelt eftermiddags benchmark, men den viser sig i virkelige projekter.

Hvad er det næste i denne serie?

Del 3 af "The Skill Bench" ser på en debugging-færdighed mod en umodificeret snake game bug hunt. Del 4 reviderer et Google zx-automatiseringsscript. Begge følger den samme regel som denne: samme opgave, samme model, én variabel, tal udskrives uanset hvad.

Skill Bench-serien

Del 2 af 4. Læs del 1: landing page build, del 3: debugging snake og del 4: auditing a Google zx script.