Ławka Umiejętności, część 2: Umiejętność TDD Claude'a vs. brak

Część 1 tej serii zestawiła umiejętność z pustym promptem w zadaniu tworzenia szkieletu, co zakończyło się jednostronnym zwycięstwem. Część 2 nie przyniosła takiego rezultatu. Zbudowaliśmy tego samego bota Telegram dwukrotnie z użyciem Claude Sonnet, jednemu uruchomieniu przypisaliśmy najwyżej ocenianą umiejętność test-driven-development z naszego katalogu, a umiejętność dodała tokeny, nie dodając testu, który miałby znaczenie. Publikujemy ten wynik w niezmienionej formie, ponieważ benchmark, który publikujesz tylko wtedy, gdy umiejętność wygrywa, nie jest benchmarkiem.

Konfiguracja i metodologia

To jest N=1. Jedno zadanie, jeden model, jedna umiejętność, uruchomione raz na każdą gałąź. To za mało danych, aby twierdzić o procentowej różnicy w jakości, i nie będziemy udawać, że jest inaczej. Wystarcza to jednak do pokazania, co faktycznie dzieje się w jednej sesji, linia po linii, czego większość marketingów umiejętności w ogóle nie pokazuje.

Zadanie: zbudować bota Telegram do zarządzania zadaniami na aiogram v3 z czterema komendami: /add, /list, /done, /delete, wspieranego przez pamięć podręczną (in-memory storage) z zakresem dla każdego użytkownika. Opis zadania wymagał czystego podziału: storage.py zawierającego czystą logikę bez importów Telegrama, bot.py łączącego tę logikę z handlerami aiogram, oraz test_storage.py pokrywającego warstwę przechowywania danych. Uruchomić pytest aż do uzyskania zielonego statusu, a następnie zatrzymać.

Obie gałęzie otrzymały identyczny prompt, identyczny model (Claude Sonnet) oraz identyczny szkielet repozytorium do rozpoczęcia. Jedyna zmienna: gałąź z umiejętnością miała zainstalowany plik SKILL.md test-driven-development obra/superpowers, tę samą umiejętność, która uzyskała 9.6 na 10 punktów w naszym katalogu za egzekwowanie ścisłej pętli red-green-refactor i odmawianie uznania pracy za zakończoną, gdy testy się nie powiodły. Gałąź bazowa nie miała nic zainstalowanego poza domyślnym zachowaniem Claude Code. Pełna metoda skryptowania i logowania tych uruchomień znajduje się w jak testujemy umiejętności Claude'a, a szersza rubryka oceniania jest dostępna na naszej stronie metodologii.

Co dostarczyły obie gałęzie

Obie gałęzie zakończyły pracę. Obie osiągnęły w pełni zielony wynik pytest. Obie wygenerowały podział na trzy pliki, o który prosił opis zadania, z logiką przechowywania danych odizolowaną od kodu handlera aiogram. Na pierwszy rzut oka wygląda to na remis, a gdybyś przestał czytać po słowach „obie osiągnęły zielony status”, doszedłbyś do wniosku, że umiejętność nie zrobiła żadnej różnicy i poszedłbyś dalej.

Żaden plik bot.py nie zrobił nic zaskakującego. Każdy podłączył cztery komendy do handlerów Router i Message aiogram, parsował tekst zadania lub indeks z argumentów komend i bezpośrednio wywoływał warstwę przechowywania danych w celu wykonania właściwej pracy. Dokładnie o to prosił opis zadania: utrzymanie cienkiego pliku bota, utrzymanie testowalnej logiki. W kwestii połączeń aiogram, obie sesje zbiegły się niemal całkowicie, co samo w sobie jest użytecznym punktem danych. Rozbieżności pojawiły się wyłącznie po stronie przechowywania danych, w tym, co każda z nich uznała za warte przetestowania.

Różnica ujawnia się w tym, co każda gałąź uznała za warte przetestowania, oraz w kosztach, jakie poniosła, aby to osiągnąć.

Liczby

	Linia bazowa (bez umiejętności)	Umiejętność (test-driven-development)	Delta
Łączna liczba tokenów	48,536	52,480	+8%
Napisane testy	23	13	-10
Testy ścieżek wyjątków	9	5	-4
Końcowy status pytest	Zielony	Zielony	Remis

Gałąź z umiejętnością zużyła więcej tokenów, aby wyprodukować mniejszy zestaw testów z mniejszym pokryciem wyjątków. To jest cały wynik. Bez ukrytych gwiazdek, bez „ale jeśli spojrzysz na jakość kodu zamiast na liczbę testów”. Sesja bazowa, działająca bez żadnego szkieletu procesowego, napisała prawie dwukrotnie więcej przypadków ścieżek wyjątków.

Analiza zestawów testów: 23 vs 13

Sama liczba testów to słaby sygnał, dlatego przeczytaliśmy oba zestawy linia po linii, zamiast ufać liczbie z nagłówka.

23 testy linii bazowej pokrywały cztery komendy na poziomie „happy-path”, a następnie zagłębiały się w przypadki brzegowe, o które nikt nie prosił z nazwy: co się dzieje, gdy oznaczysz jako wykonany indeks spoza zakresu, co robi indeks zerowy lub ujemny, czy lista zadań jednego użytkownika nie wycieka do listy innego użytkownika, oraz czy usunięcie elementu 2 prawidłowo przesuwa indeksy elementów 3 i 4, tak aby /done 3 nadal wskazywało na właściwe zadanie. Ten ostatni to rodzaj błędu, który przetrwa demo, a następnie psuje się przed prawdziwym użytkownikiem, gdy ten po raz pierwszy usunie coś ze środka listy. Dziewięć z 23 testów istniało wyłącznie po to, aby sprawdzić te ścieżki wyjątków.

13 testów gałęzi z umiejętnością pokrywało te same cztery komendy na poziomie „happy-path”, plus pięć przypadków ścieżek wyjątków: głównie indeksy spoza zakresu i jeden scenariusz dodawania duplikatów. Czego brakuje w porównaniu do linii bazowej: brak jawnego testu izolacji dla każdego użytkownika oraz brak testu potwierdzającego zachowanie indeksów po usunięciu, które przesuwa listę. Logika przechowywania danych w pliku storage.py gałęzi z umiejętnością może dobrze obsługiwać te przypadki. Nietestowane poprawne zachowanie i testowane poprawne zachowanie to jednak nie to samo twierdzenie, a cały sens zestawu testów polega na zamykaniu tej luki.

Żaden zestaw nie jest zły. Trzynaście testów z pięcioma przypadkami wyjątków w bocie z czterema komendami to obronny punkt wyjścia według wszelkich normalnych standardów inżynierskich. Porównanie wygląda druzgocąco tylko w zestawieniu z linią bazową, która, pracując z identycznym promptem bez żadnego szkieletu red-green, napisała więcej testów, a nie mniej.

Dlaczego to nie obala TDD

Oto czego jednorazowy benchmark strukturalnie nie jest w stanie dostrzec: argument TDD nigdy nie brzmiał „napiszesz więcej testów za pierwszym razem”. Chodzi o to, co dzieje się przez tygodnie iteracji, przy dziesiątej funkcji dodanej do bazy kodu, której model nie napisał od zera, w momencie, gdy zmęczony inżynier (lub agent pod presją czasu) kusi się, by wdrożyć z czerwonym testem i naprawić to „później”.

To jest twierdzenie dotyczące dyscypliny, a nie jednorazowego wyniku, a ten benchmark został uruchomiony dokładnie raz. Nie możemy zmierzyć dyscypliny w jednej sesji, ponieważ dyscyplina to coś, co powstrzymuje Cię przed pójściem na skróty w szóstej sesji, a tutaj nie ma szóstej sesji.

Mamy jednak ślad tego, jak ta dyscyplina wygląda w praktyce, z naszych własnych notatek testowych na stronie umiejętności test-driven-development: podczas sesji obejmującej trzy funkcje, umiejętność odmawiała pominięcia cyklu red-green, nawet gdy poprawka wydawała się oczywista, a pokusa, by od razu przejść do zielonego statusu, była silna. Najpierw napisała test, który się nie powiódł, obserwowała jego niepowodzenie z właściwego powodu, a następnie napisała minimalny kod, aby go zaliczyć, za każdym razem, we wszystkich trzech funkcjach. Nikt nie musiał interweniować i mówić „poczekaj, najpierw napisz test”. To jest zachowanie, które umiejętność dyscypliny ma zapewnić, i nie jest to to samo zachowanie co „pisze więcej testów w jednej próbie na małym, dobrze zdefiniowanym module”.

W zadaniu tej wielkości i tak dobrze sprecyzowanym, bazowa ocena Claude Sonnet dotycząca tego, co należy przetestować, była już solidna. Umiejętność dodała jawny proces do oceny, która jeszcze nie wymagała wielu poprawek, a ten proces kosztował 8% więcej tokenów bez odpowiadającej mu wygranej jakości w tej konkretnej próbie. Obie rzeczy mogą być prawdziwe: TDD warto mieć zainstalowane, a tutaj nie pomogło.

Istnieje również prostsze wyjaśnienie, które warto wymienić: napisanie testu, który się nie powiedzie, obserwowanie jego niepowodzenia, a następnie napisanie minimalnego kodu, aby go zaliczyć, wymaga więcej iteracji niż napisanie implementacji i testu do niej w jednym przejściu. Ten narzut jest celem dyscypliny, gdy implementacja jest nietrywialna lub model ma tendencję do pomijania kroków. W przypadku bota do zadań z czterema komendami, implementacja nigdy nie budziła wątpliwości, więc narzut zapewnił proces bez zapewnienia kontroli nad czymkolwiek, co faktycznie było zagrożone niepowodzeniem.

Co to oznacza, jeśli kupujesz umiejętności

Niekomfortowa dla nas część, konkretnie, polega na tym, że sprzedajemy przetestowane umiejętności, a nasz własny test właśnie pokazał, że wysoko oceniona umiejętność nie wygrała jednorazowego porównania z brakiem umiejętności w ogóle. Wolimy, abyś zobaczył to, niż skrót najlepszych momentów.

Praktyczny wniosek jest taki, aby dopasować umiejętność do zadania, a nie do wyniku. Wynik 9.6/10 w katalogu oznacza, że umiejętność działa zgodnie z opisem, niezawodnie i nie psuje Twojej konfiguracji, a nie to, że wygrywa każdy benchmark w każdym rozmiarze zadania. Jeśli Twoim zadaniem jest mały, dobrze sprecyzowany moduł, który budujesz od nowa, za jednym posiedzeniem, domyślna ocena silnego modelu może już pokrywać ścieżki wyjątków, na których Ci zależy, a umiejętność procesowa to narzut, za który płacisz bez odpowiadającej mu korzyści w tej sesji. Jeśli Twoim zadaniem jest baza kodu, którą będziesz dotykać przez miesiące, z wieloma współtwórcami i długimi przerwami między sesjami, gdzie ciche pójście na skróty kumuluje się, to właśnie temu ma zapobiegać umiejętność dyscypliny, taka jak TDD, a jednorazowy benchmark nigdy nie był w stanie uchwycić tej wartości.

Umiejętności szybkościowe i umiejętności dyscypliny odpowiadają na różne pytania. Przeczytaj opis umiejętności, aby dowiedzieć się, na jakie pytanie odpowiada, zanim zainstalujesz ją do niewłaściwego zadania. Omawiamy, jak odczytać ten sygnał w naszym przeglądzie najlepszych umiejętności kodowania.

Odtwórz to samodzielnie

Zadanie jest na tyle małe, że można je ponownie uruchomić w jedno popołudnie. Sklonuj czysty projekt aiogram v3, a następnie uruchom identyczny prompt dwukrotnie: raz w czystej sesji Claude Code, raz z zainstalowaną umiejętnością test-driven-development obra/superpowers. Poproś o /add /list /done /delete z pamięcią podręczną (in-memory storage) dla każdego użytkownika, podziałem na storage.py/bot.py i zestawem testów pytest, który działa na zielono, zanim uznasz to za zakończone. Zaloguj łączną liczbę tokenów z podsumowania użycia każdej sesji, a następnie ręcznie porównaj dwa pliki test_storage.py: policz asercje i specjalnie oznacz wszystko, co dotyczy ujemnych indeksów, brakujących kluczy, izolacji dla każdego użytkownika oraz przesunięć indeksów po usunięciu. Te cztery kategorie to miejsca, gdzie zauważyliśmy lukę, i to właśnie je warto sprawdzić w każdej aplikacji CRUD typu „todo”, niezależnie od tego, którą umiejętność testujesz.

FAQ

Czy to oznacza, że umiejętność TDD jest zła?

Nie. Oznacza to, że jednorazowy benchmark na małym, dobrze sprecyzowanym module nie jest testem, który pokazuje, do czego służy TDD. Wartość umiejętności polega na zapobieganiu pójściu na skróty podczas długiej sesji lub długiego projektu, czego ten benchmark, z założenia, nie trwał wystarczająco długo, aby zmierzyć.

Dlaczego gałąź z umiejętnością napisała mniej testów, skoro egzekwuje bardziej rygorystyczny proces?

Pętla red-green-refactor skłania Cię do napisania testu dla zachowania, które zamierzasz zaimplementować, następnie zaimplementowania go, a potem przejścia do następnego zachowania. Nie skłania Cię automatycznie do powrotu i dodawania testów dla przypadków brzegowych, o które nikt wyraźnie nie prosił, chyba że sesja poświęci czas na ich oddzielne burze mózgów. Gałąź bazowa, nieograniczona stałym cyklem, najwyraźniej poświęciła więcej swojego wyniku na właśnie taką burzę mózgów.

Czy powinienem zainstalować umiejętność TDD dla Claude Code?

Jeśli pracujesz w bazie kodu, do której będziesz wracać wielokrotnie, zwłaszcza z innymi współtwórcami lub z długimi przerwami między sesjami, tak. To ubezpieczenie przed konkretnym trybem awarii: cichym wdrożeniem z czerwonym testem, ponieważ poprawka wydawała się oczywista. Ten tryb awarii nie pojawia się w jednodniowym benchmarku, ale pojawia się w prawdziwych projektach.

Co dalej w tej serii?

Część 3 „Ławki Umiejętności” przygląda się umiejętności debugowania w walce z niezmienioną grą w węża i poszukiwaniem błędów. Część 4 audytuje skrypt automatyzacji Google zx. Obie części przestrzegają tej samej zasady co ta: to samo zadanie, ten sam model, jedna zmienna, liczby drukowane tak czy inaczej.

Seria Ławka Umiejętności

Część 2 z 4. Przeczytaj część 1: budowa strony docelowej, część 3: debugowanie węża i część 4: audyt skryptu Google zx.