De Skill Bench, deel 2: Claude TDD skill vs. geen skill

Deel 1 van deze serie zette een skill tegenover een lege prompt voor een scaffolding-taak en behaalde een scheve overwinning. Deel 2 doet dat niet. We bouwden tweemaal dezelfde Telegram bot met Claude Sonnet, gaven één run de hoogst gewaardeerde test-driven-development skill uit onze catalogus, en de skill voegde tokens toe zonder een test toe te voegen die ertoe deed. We publiceren dit resultaat zoals het is, want een benchmark die je alleen publiceert als de skill wint, is geen benchmark.

Opzet en methodologie

Dit is N=1. Eén taak, één model, één skill, één keer uitgevoerd per arm. Dat is niet genoeg data om een percentageverschil in kwaliteit te claimen, en we zullen ook niet anders beweren. Waar het wel genoeg voor is, is het tonen van wat er daadwerkelijk gebeurt in één sessie, regel voor regel, iets wat de meeste skill-marketing je helemaal nooit laat zien.

De taak: bouw een Telegram todo bot op aiogram v3 met vier commando's, /add, /list, /done, /delete, ondersteund door in-memory opslag per gebruiker. De opdracht vroeg om een duidelijke scheiding: storage.py met pure logica zonder Telegram imports, bot.py die die logica verbindt met aiogram handlers, en test_storage.py die de opslaglaag dekt. Voer pytest uit totdat het groen is, en stop dan.

Beide armen kregen de identieke prompt, het identieke model (Claude Sonnet), en de identieke repo scaffold om mee te beginnen. De enige variabele: de skill-arm had obra/superpowers' test-driven-development SKILL.md geïnstalleerd, dezelfde skill die 9.6 van de 10 scoorde in onze catalogus voor het afdwingen van een strikte red-green-refactor loop en het weigeren om een sessie werk als voltooid te markeren terwijl een test faalt. De baseline-arm had niets geïnstalleerd behalve het standaard Claude Code gedrag. De volledige methode voor hoe we deze runs scripten en loggen staat in how we test Claude skills, en de bredere scoringsrubriek staat op our methodology page.

Wat beide armen opleverden

Beide armen waren klaar. Beide behaalden een volledig groene pytest run. Beide produceerden de driedelige bestandsstructuur waar de opdracht om vroeg, met opslaglogica geïsoleerd van de aiogram handler code. Oppervlakkig gezien lijkt dit een gelijkspel, en als je zou stoppen met lezen bij "beide werden groen", zou je concluderen dat de skill geen verschil maakte en verdergaan.

Geen van beide bot.py bestanden deed iets verrassends. Elk verbond de vier commando's met aiogram's Router en Message handlers, parseerde de todo-tekst of index uit de commando-argumenten, en riep direct de opslaglaag aan voor het eigenlijke werk. Dat is precies wat de opdracht vroeg: houd het bot-bestand dun, houd de logica testbaar. Wat de aiogram-bedrading betreft, kwamen de twee sessies bijna volledig overeen, wat op zichzelf een nuttig datapunt is. Waar ze verschilden, was volledig aan de opslagkant, in wat elk de moeite waard vond om te testen.

Het verschil blijkt uit wat elke arm de moeite waard vond om te testen, en in wat het kostte om daar te komen.

De cijfers

	Baseline (geen skill)	Skill (test-driven-development)	Delta
Totaal aantal tokens	48,536	52,480	+8%
Geschreven tests	23	13	-10
Exception-path tests	9	5	-4
Eindstatus pytest	Green	Green	Tie

De skill-arm gebruikte meer tokens om een kleinere testsuite te produceren met minder exception-dekking. Dat is het hele resultaat. Geen verborgen asterisk, geen "maar als je kijkt naar codekwaliteit in plaats van het aantal tests." De baseline-sessie, die zonder enige proces-scaffolding draaide, schreef bijna twee keer zoveel exception-path cases.

De testsuites lezen: 23 vs. 13

Het aantal tests alleen is een zwak signaal, dus lazen we beide suites regel voor regel in plaats van het kopnummer te vertrouwen.

De 23 tests van de baseline dekten de vier commando's op happy-path niveau, en gingen vervolgens verder met edge cases waar niemand expliciet om vroeg: wat er gebeurt als je een index buiten bereik als voltooid markeert, wat een nul- of negatieve index doet, of de todo-lijst van de ene gebruiker lekt naar die van een andere gebruiker, en of het verwijderen van item 2 de indices van items 3 en 4 correct verschuift, zodat /done 3 daarna nog steeds naar de juiste taak wijst. Dat laatste is het soort bug dat een demo overleeft en vervolgens breekt voor een echte gebruiker de eerste keer dat ze iets uit het midden van een lijst verwijderen. Negen van de 23 tests bestonden puur om deze exception paths te onderzoeken.

De 13 tests van de skill-arm dekten dezelfde vier commando's op happy-path niveau, plus vijf exception-path cases: voornamelijk indices buiten bereik en één duplicate-add scenario. Wat ontbreekt ten opzichte van de baseline: geen expliciete per-user isolatietest, en geen test die indexgedrag bevestigt nadat een verwijdering de lijst verschuift. De opslaglogica in de storage.py van de skill-arm kan deze gevallen wellicht correct afhandelen. Ongetest correct gedrag en getest correct gedrag zijn echter niet dezelfde bewering, en het hele punt van een testsuite is het dichten van die kloof.

Geen van beide suites is slecht. Dertien tests met vijf exception cases op een bot met vier commando's is een verdedigbaar startpunt volgens elke normale engineeringstandaard. De vergelijking ziet er alleen maar vernietigend uit naast een baseline die, werkend vanuit een identieke prompt zonder enige red-green scaffolding, meer tests schreef, niet minder.

Waarom dit TDD niet weerlegt

Dit is wat een eenmalige benchmark structureel niet kan zien: het argument van TDD was nooit "je schrijft meer tests bij je eerste poging." Het gaat over wat er gebeurt over weken van iteratie, over de tiende feature die is toegevoegd aan een codebase die het model niet vanaf nul heeft geschreven, op het punt waar een vermoeide engineer (of een agent onder tijdsdruk) in de verleiding komt om te shippen met een rode test en deze "later" te fixen.

Dat is een claim over discipline, geen claim over een eenmalige output, en deze benchmark draaide precies één keer. We kunnen discipline niet meten in één sessie, omdat discipline je ervan weerhoudt om een kortere weg te nemen in sessie zes, en er is hier geen sessie zes.

We hebben wel een spoor van hoe die discipline er in de praktijk uitziet, uit onze eigen testnotities op de test-driven-development skill page: gedurende een sessie met drie features weigerde de skill de red-green cyclus over te slaan, zelfs toen de oplossing voor de hand lag en de verleiding om direct naar groen te springen groot was. Het schreef eerst de falende test, zag deze om de juiste reden falen, en schreef vervolgens de minimale code om deze te laten slagen, elke keer, voor alle drie de features. Niemand hoefde in te grijpen en te zeggen "wacht, schrijf eerst de test." Dat is het gedrag dat een discipline-skill zou moeten opleveren, en het is niet hetzelfde gedrag als "schrijft meer tests in één poging op een kleine, goed afgebakende module."

Bij een taak van deze omvang en zo goed gespecificeerd, was Claude Sonnet's basisoordeel over wat te testen al solide. De skill voegde een expliciet proces toe bovenop een oordeel dat nog niet veel correctie nodig had, en dat proces kostte 8% meer tokens zonder een overeenkomstige kwaliteitswinst bij deze specifieke poging. Beide dingen kunnen waar zijn: TDD is de moeite waard om geïnstalleerd te hebben, en het hielp hier niet.

Er is ook een eenvoudigere verklaring die het benoemen waard is: het schrijven van een falende test, deze zien falen, en vervolgens de minimale code schrijven om deze te laten slagen, vergt meer heen-en-weer dan het schrijven van de implementatie en een test ervoor in één keer. Die overhead is het punt van de discipline wanneer de implementatie niet triviaal is of het model de neiging heeft om vooruit te springen. Bij een todo bot met vier commando's was de implementatie nooit in twijfel, dus de overhead leverde proces op zonder een controle te bieden op iets dat daadwerkelijk het risico liep mis te gaan.

Wat dit betekent als je skills koopt

Het ongemakkelijke deel voor ons, specifiek, is dat wij geteste skills verkopen, en onze eigen bench liet net zien dat een hoog scorende skill geen eenmalige vergelijking won tegen helemaal geen skill. We zien liever dat je dat ziet dan een highlight reel.

De praktische les is om de skill af te stemmen op de taak, niet op de score. Een catalogusscore van 9.6/10 betekent dat de skill betrouwbaar doet wat het belooft en je setup niet kapotmaakt, niet dat het elke benchmark op elke taakgrootte wint. Als je taak een kleine, goed gespecificeerde module is die je vers bouwt, in één keer, dan kan het standaard oordeel van een sterk model de exception paths die je belangrijk vindt al dekken, en is een proces-skill overhead waarvoor je betaalt zonder een overeenkomstige meerwaarde in die sessie. Als je taak een codebase is die je maandenlang zult aanraken, met meerdere bijdragers en lange periodes tussen sessies waarin het nemen van kortere wegen zich stilletjes opstapelt, dan is dat wat een discipline-skill zoals TDD moet voorkomen, en een single-session benchmark zou die waarde in de eerste plaats nooit hebben vastgelegd.

Snelheidsskills en disciplineskills beantwoorden verschillende vragen. Lees de beschrijving van een skill om te zien welke vraag het beantwoordt voordat je het voor de verkeerde taak installeert. We behandelen hoe je dat signaal leest in our roundup of the best coding skills.

Reproduceer het zelf

De taak is klein genoeg om in een middag opnieuw uit te voeren. Kloon een kaal aiogram v3 project, en voer vervolgens de identieke prompt tweemaal uit: één keer in een schone Claude Code sessie, één keer met obra/superpowers' test-driven-development skill geïnstalleerd. Vraag om /add /list /done /delete met in-memory opslag per gebruiker, een storage.py/bot.py splitsing, en een pytest suite die groen draait voordat je het als voltooid beschouwt. Log het totale aantal tokens uit de gebruiksoverzicht van elke sessie, en vergelijk vervolgens de twee test_storage.py bestanden handmatig: tel assertions, en markeer specifiek alles wat betrekking heeft op negatieve indices, ontbrekende sleutels, per-user isolatie, en indexverschuivingen na een verwijdering. Die vier categorieën zijn waar we de kloof zagen, en het zijn degenen die de moeite waard zijn om te controleren bij elke todo-achtige CRUD-app, ongeacht welke skill je test.

Veelgestelde vragen

Betekent dit dat de TDD skill slecht is?

Nee. Het betekent dat een eenmalige benchmark op een kleine, goed gespecificeerde module niet de test is die laat zien waar TDD voor is. De waarde van de skill ligt in het voorkomen van het nemen van kortere wegen gedurende een lange sessie of een lang project, wat deze benchmark, door het ontwerp, niet lang genoeg heeft gemeten.

Waarom schreef de skill-arm minder tests als het een strikter proces afdwingt?

De red-green-refactor loop drijft je ertoe om een test te schrijven voor het gedrag dat je gaat implementeren, het vervolgens te implementeren, en dan naar het volgende gedrag te gaan. Het spoort je niet automatisch aan om terug te gaan en tests toe te voegen voor edge cases waar niemand expliciet om vroeg, tenzij de sessie tijd neemt om deze afzonderlijk te brainstormen. De baseline-arm, onbeperkt door een vaste cyclus, besteedde blijkbaar meer van zijn output aan precies dat brainstormen.

Moet ik een TDD skill installeren voor Claude Code?

Als je werkt in een codebase waar je herhaaldelijk naar terugkeert, vooral met andere bijdragers of lange pauzes tussen sessies, ja. Het is een verzekering tegen een specifieke faalmodus: stilletjes shippen met een rode test omdat de oplossing voor de hand liggend leek. Die faalmodus verschijnt niet in een benchmark van één middag, maar wel in echte projecten.

Wat is het volgende in deze serie?

Deel 3 van "The Skill Bench" kijkt naar een debugging skill tegen een ongewijzigde snake game bug hunt. Deel 4 auditeert een Google zx automatiseringsscript. Beide volgen dezelfde regel als deze: dezelfde taak, hetzelfde model, één variabele, cijfers hoe dan ook afgedrukt.

De Skill Bench serie

Deel 2 van 4. Lees deel 1: landing page build, deel 3: debugging snake, en deel 4: auditing a Google zx script.