Skill Bench, část 2: Dovednost TDD u Claude vs. bez dovednosti

Část 1 této série postavila dovednost proti prázdnému promptu na úkolu se scaffoldingem a získala jednostranné vítězství. Část 2 nikoli. Stejného Telegram bota jsme dvakrát vytvořili s Claude Sonnet, jednomu spuštění jsme dali nejlépe hodnocenou dovednost test-driven-development z našeho katalogu a tato dovednost přidala tokeny, aniž by přidala test, který by byl relevantní. Tento výsledek zveřejňujeme tak, jak je, protože benchmark, který publikujete pouze tehdy, když dovednost vyhraje, není benchmark.

Nastavení a metodika

Toto je N=1. Jeden úkol, jeden model, jedna dovednost, spuštěno jednou na každé větvi. To není dostatek dat k tvrzení o procentuálním rozdílu v kvalitě a nebudeme předstírat opak. Na co to stačí, je ukázat, co se skutečně děje v jedné relaci, řádek po řádku, což je něco, co vám většina marketingu dovedností nikdy neukáže.

Úkol: vytvořit Telegram todo bota na aiogram v3 se čtyřmi příkazy, /add, /list, /done, /delete, podpořeného in-memory úložištěm s rozsahem pro každého uživatele. Zadání požadovalo čisté rozdělení: storage.py obsahující čistou logiku bez importů Telegramu, bot.py propojující tuto logiku s handlery aiogramu a test_storage.py pokrývající vrstvu úložiště. Spustit pytest, dokud nebude zelený, a poté zastavit.

Obě větve dostaly identický prompt, identický model (Claude Sonnet) a identický scaffold repozitáře pro začátek. Jediná proměnná: větev s dovedností měla nainstalovanou test-driven-development SKILL.md od obra/superpowers, stejnou dovednost, která v našem katalogu získala 9.6 z 10 za vynucování přísné smyčky red-green-refactor a odmítání označit práci za hotovou, dokud test selhává. Základní větev neměla nainstalováno nic kromě výchozího chování Claude Code. Kompletní metoda, jak skriptujeme a logujeme tato spuštění, je popsána v jak testujeme dovednosti Claude a širší hodnotící rubrika je k dispozici na naší stránce metodiky.

Co obě větve dodaly

Obě větve dokončily. Obě dosáhly plně zeleného spuštění pytestu. Obě vytvořily rozdělení do tří souborů, které zadání požadovalo, s logikou úložiště izolovanou od kódu handlerů aiogramu. Na první pohled to vypadá jako remíza, a kdybyste přestali číst u "obě byly zelené", dospěli byste k závěru, že dovednost neměla žádný vliv a šli byste dál.

Ani jeden soubor bot.py neudělal nic překvapivého. Každý propojil čtyři příkazy s handlery Router a Message aiogramu, parsoval text úkolu nebo index z argumentů příkazu a volal přímo do vrstvy úložiště pro skutečnou práci. Přesně to zadání požadovalo: udržet soubor bota tenký, udržet logiku testovatelnou. V zapojení aiogramu se obě relace téměř úplně shodovaly, což je samo o sobě užitečný datový bod. Kde se lišily, bylo zcela na straně úložiště, v tom, co každá považovala za hodné testování.

Rozdíl se projevuje v tom, co každá větev považovala za hodné testování, a v tom, co to stálo, aby se tam dostala.

Čísla

	Základní (bez dovednosti)	Dovednost (test-driven-development)	Delta
Celkem tokenů	48,536	52,480	+8%
Napsaných testů	23	13	-10
Testy výjimečných cest	9	5	-4
Konečný stav pytestu	Zelený	Zelený	Remíza

Větev s dovedností použila více tokenů k vytvoření menší sady testů s menším pokrytím výjimek. To je celý výsledek. Žádná skrytá hvězdička, žádné "ale když se podíváte na kvalitu kódu místo počtu testů". Základní relace, běžící zcela bez procesního scaffoldingu, napsala téměř dvakrát tolik případů výjimečných cest.

Čtení testovacích sad: 23 vs 13

Samotný počet testů je slabý signál, proto jsme obě sady četli řádek po řádku, místo abychom důvěřovali číslu v záhlaví.

23 testů základní verze pokrylo čtyři příkazy na úrovni "happy-path", a poté pokračovalo do okrajových případů, které nikdo výslovně nepožadoval: co se stane, když označíte index mimo rozsah jako hotový, co dělá nulový nebo záporný index, zda se seznam úkolů jednoho uživatele neprolíná s jiným uživatelem, a zda smazání položky 2 správně posune indexy položek 3 a 4 tak, aby /done 3 stále ukazovalo na správný úkol. Ten poslední je typ chyby, která přežije demo a pak se rozbije před skutečným uživatelem, když poprvé smaže něco ze středu seznamu. Devět z 23 testů existovalo čistě proto, aby se zaměřilo na tyto výjimečné cesty.

13 testů větve s dovedností pokrylo stejné čtyři příkazy na úrovni "happy-path", plus pět případů výjimečných cest: většinou indexy mimo rozsah a jeden scénář duplicitního přidání. Co chybí oproti základní verzi: žádný explicitní test izolace pro uživatele a žádný test potvrzující chování indexů po smazání, které posune seznam. Logika úložiště v storage.py větve s dovedností může tyto případy správně zpracovávat. Netestované správné chování a testované správné chování však nejsou stejné tvrzení a celým smyslem testovací sady je tuto mezeru vyplnit.

Ani jedna sada není špatná. Třináct testů s pěti výjimečnými případy na čtyřpříkazovém botovi je obhajitelný výchozí bod podle jakéhokoli běžného inženýrského standardu. Srovnání vypadá odsuzující pouze vedle základní verze, která, pracující z identického promptu zcela bez red-green scaffoldingu, napsala více testů, nikoli méně.

Proč to nevyvrací TDD

Zde je věc, kterou jednorázový benchmark strukturálně nemůže vidět: argument TDD nikdy nebyl "napíšete více testů na první pokus". Jde o to, co se děje během týdnů iterací, napříč desátou funkcí přidanou do codebase, kterou model nenapsal od nuly, v okamžiku, kdy je unavený inženýr (nebo agent pod časovým tlakem) v pokušení odeslat kód s červeným testem a opravit ho "později".

To je tvrzení o disciplíně, nikoli tvrzení o jednorázovém výstupu, a tento benchmark proběhl přesně jednou. Disciplínu nelze měřit v jedné relaci, protože disciplína je to, co vám zabrání zkrátit si cestu v šesté relaci, a zde žádná šestá relace není.

Máme však záznam toho, jak tato disciplína vypadá v praxi, z našich vlastních testovacích poznámek na stránce dovednosti test-driven-development: během relace se třemi funkcemi dovednost odmítla přeskočit cyklus red-green, i když oprava vypadala zjevně a pokušení přejít rovnou na zelenou bylo na dosah. Nejprve napsala selhávající test, sledovala, jak selhává ze správného důvodu, a poté napsala minimální kód k jeho úspěšnému průchodu, pokaždé, napříč všemi třemi funkcemi. Nikdo nemusel zasahovat a říkat "počkat, nejprve napiš test". To je chování, které by dovednost disciplíny měla přinést, a není to stejné chování jako "napíše více testů na jeden pokus na malém, dobře vymezeném modulu".

Na úkolu této velikosti a takto dobře specifikovaném byl základní úsudek Claude Sonnet o tom, co testovat, již pevný. Dovednost přidala explicitní proces nad úsudek, který ještě nepotřeboval mnoho oprav, a tento proces stál o 8% více tokenů bez odpovídajícího kvalitativního vítězství v tomto konkrétním pokusu. Obě věci mohou být pravdivé: TDD stojí za to mít nainstalované, a zde nepomohlo.

Existuje také jednodušší vysvětlení, které stojí za zmínku: napsání selhávajícího testu, sledování jeho selhání a poté napsání minimálního kódu k jeho úspěšnému průchodu vyžaduje více tam a zpět než napsání implementace a testu pro ni v jednom průchodu. Tato režie je smyslem disciplíny, když implementace není triviální nebo model má tendenci přeskakovat dopředu. U čtyřpříkazového todo bota nebyla implementace nikdy pochybná, takže režie přinesla proces, aniž by přinesla kontrolu nad něčím, co by skutečně hrozilo selháním.

Co to znamená, pokud kupujete dovednosti

Nepříjemná část pro nás, konkrétně, je, že prodáváme testované dovednosti a naše vlastní testovací prostředí právě ukázalo, že nejlépe hodnocená dovednost nevyhrála jednorázové srovnání proti žádné dovednosti. Raději bychom, abyste viděli toto než sestřih nejlepších momentů.

Praktickým závěrem je sladit dovednost s úkolem, nikoli s hodnocením. Hodnocení 9.6/10 v katalogu znamená, že dovednost spolehlivě dělá to, co slibuje, a nerozbije vaše nastavení, nikoli že vyhraje každý benchmark na každé velikosti úkolu. Pokud je vaším úkolem malý, dobře specifikovaný modul, který vytváříte od začátku, v jednom zátahu, výchozí úsudek silného modelu může již pokrývat výjimečné cesty, na kterých vám záleží, a procesní dovednost je režie, za kterou platíte bez odpovídajícího přínosu v dané relaci. Pokud je vaším úkolem codebase, které se budete dotýkat měsíce, s více přispěvateli a dlouhými přestávkami mezi relacemi, kde se tiché zkracování cest hromadí, pak je to to, čemu má disciplinární dovednost jako TDD zabránit, a jednorázový benchmark by tuto hodnotu nikdy nezachytil.

Dovednosti pro rychlost a dovednosti pro disciplínu odpovídají na různé otázky. Přečtěte si popis dovednosti, na jakou otázku odpovídá, než ji nainstalujete pro špatný úkol. Jak číst tento signál, pokrýváme v našem přehledu nejlepších kódovacích dovedností.

Reprodukujte si to sami

Úkol je dostatečně malý, aby se dal znovu spustit během odpoledne. Naklonujte čistý projekt aiogram v3 a poté spusťte identický prompt dvakrát: jednou v čisté relaci Claude Code, jednou s nainstalovanou dovedností test-driven-development od obra/superpowers. Požádejte o /add /list /done /delete s in-memory úložištěm pro každého uživatele, rozdělením na storage.py/bot.py a sadou pytest testů, která běží zeleně, než to prohlásíte za hotové. Zalogujte celkový počet tokenů ze souhrnu využití každé relace, poté ručně porovnejte dva soubory test_storage.py: spočítejte aserce a konkrétně označte cokoli, co se týká záporných indexů, chybějících klíčů, izolace pro uživatele a posunů indexů po smazání. Tyto čtyři kategorie jsou místa, kde jsme viděli mezeru, a jsou to ty, které stojí za kontrolu u jakékoli CRUD aplikace typu "todo", bez ohledu na to, jakou dovednost testujete.

Často kladené otázky

Znamená to, že dovednost TDD je špatná?

Ne. Znamená to, že jednorázový benchmark na malém, dobře specifikovaném modulu není test, který by ukázal, k čemu TDD slouží. Hodnota dovednosti spočívá v prevenci zkracování cest v průběhu dlouhé relace nebo dlouhého projektu, což tento benchmark, záměrně, nebyl dostatečně dlouhý na to, aby změřil.

Proč větev s dovedností napsala méně testů, když vynucuje přísnější proces?

Smyčka red-green-refactor vás vede k napsání testu pro chování, které se chystáte implementovat, poté k jeho implementaci a následně k dalšímu chování. Automaticky vás nevyzývá k návratu a přidání testů pro okrajové případy, které nikdo výslovně nepožadoval, pokud si relace neudělá čas na jejich samostatné promyšlení. Základní větev, neomezená pevným cyklem, zjevně věnovala více svého výstupu právě tomuto brainstormingu.

Měl bych si nainstalovat dovednost TDD pro Claude Code?

Pokud pracujete na codebase, ke které se budete opakovaně vracet, zejména s dalšími přispěvateli nebo s dlouhými mezerami mezi relacemi, pak ano. Je to pojištění proti specifickému režimu selhání: tichému odeslání kódu s červeným testem, protože oprava vypadala zjevně. Tento režim selhání se neprojeví v jednorázovém odpoledním benchmarku, ale projevuje se ve skutečných projektech.

Co bude dál v této sérii?

Část 3 "The Skill Bench" se zaměřuje na dovednost ladění proti nemodifikovanému lovu chyb ve hře had. Část 4 audituje automatizační skript Google zx. Obě se řídí stejným pravidlem jako tato: stejný úkol, stejný model, jedna proměnná, čísla vytištěna tak či onak.

Série Skill Bench

Část 2 ze 4. Přečtěte si část 1: tvorba vstupní stránky, část 3: ladění hry had a část 4: audit skriptu Google zx.