O czym jest ten film
- Premiera wersji 1.1 repozytorium umiejętności (skills) Matta Pococka do pracy z agentami AI przy programowaniu.
- Zmiana nazw dwóch kluczowych umiejętności:
to-prd→to-specorazto-issues→to-tickets, wraz z uzasadnieniem terminologicznym. - Poprawki błędów w umiejętnościach „grillujących” (
grill-me,grill-with-docs) — m.in. pojedyncze pytania i bramka potwierdzenia przed wdrożeniem. - Nowa umiejętność
implementdomykająca proces od planowania do implementacji w pełny cykl życia oprogramowania. - Aktualizacja umiejętności
code-review— recenzja na dwóch osiach oraz wykrywanie „zapachów kodu” według Martina Fowlera. - Zupełnie nowa umiejętność
wayfinderdo planowania dużych zadań rozbitych na wiele sesji agenta, z mapą zapisaną w GitHub Issues. - Nowa, mała umiejętność
researchuruchamiająca agenta w tle do badania zagadnień w oparciu o źródła pierwotne. - Umiejętność
prototype— teraz wywoływana przez model, wybór między prototypem logiki a prototypem UI. - Umiejętność TDD przekształcona w materiał referencyjny (tylko red-green, refaktoryzacja przeniesiona do etapu code review).
- Zapowiedź nowego, samodzielnego i tańszego kursu „AI Coding Crash Course” planowanego mniej więcej na sierpień.
Redakcyjne tłumaczenie
Wstęp: wersja 1.1 jest gotowa
Witajcie, przyjaciele. To pierwszy film od dłuższego czasu, a powodem jest to, że pracowałem nad wersją 1.1 mojego repozytorium umiejętności. Znalazła się w nim zdumiewająca ilość rzeczy. Jest tam zupełnie nowe podejście do „grillowania”, które prawdopodobnie zasługuje na osobny film, ale spróbuję je tu jakoś zmieścić. Jest cała masa zmian w istniejących umiejętnościach, w tym zmiana nazw dwóch głównych umiejętności obsługujących przepływ pracy. Tego jest naprawdę zbyt wiele, żeby streścić we wstępie, więc będziecie musieli po prostu obejrzeć film. Widać, że pull request jest gotowy do scalenia. To zróbmy to — scalmy to wreszcie. I w ten sposób mamy gotową wersję 1.1.
(Informacja dodatkowa: „skills” to modularne umiejętności — zestawy instrukcji dla agentów AI programujących w środowiskach takich jak Claude Code. Pocock rozwija popularne open-source’owe repozytorium takich umiejętności.)
Zmiana nazw: to-spec i to-tickets
Zacznijmy od dwóch zmian, które będą dla was prawdopodobnie najbardziej irytujące i wywołają pytanie: „Po co on to zrobił?”. Zrobiłem to z bardzo konkretnego powodu — zmieniłem nazwy dwóch umiejętności. Umiejętność to-prd została przemianowana na to-spec. A jeśli wejdziemy poziom wyżej, to to-issues zostało przemianowane na to-tickets.
Powód jest taki, że dręczyło mnie to od dawna. To, co tworzyliśmy jako PRD, w rzeczywistości nie było PRD — to była specyfikacja. Dokument wymagań produktowych (PRD) opisuje raczej rzeczy dotyczące samego produktu, a my pozwalaliśmy, by do „PRD” przenikały treści, które PRD wcale nie były. Dlatego od dawna chciałem zmienić nazwę na to-spec, bo to właśnie tworzyliśmy — specyfikację. „Specyfikacja” to znacznie szersze pojęcie, które faktycznie obejmuje to, co budowaliśmy: specyfikację rzeczy, którą chcemy zbudować. Może być techniczna, może być nietechniczna, może łączyć jedno z drugim. To nie ma znaczenia.
(Informacja dodatkowa: PRD, czyli Product Requirements Document, to klasyczny dokument produktowy opisujący cel, użytkowników i wymagania produktu.)
Jeśli chodzi o to-issues, ta nazwa zawsze wydawała mi się stronnicza w stronę GitHuba i Lineara, które używają terminu „issues” (zgłoszenia). Naprawdę jednak chcemy, by były to „tickety”. Masz specyfikację, a pod nią tickety — czyli drogę, którą przechodzisz, żeby tę specyfikację zrealizować i stworzyć. Dręczyło mnie to od dawna, a teraz w końcu przestało. Sprawia mi to wręcz radość.
Jedna irytująca rzecz przy tej zmianie nazw: prawdopodobnie będziecie musieli usunąć te umiejętności i pobrać je od nowa. Oznacza to uruchomienie npx skills add mattpocock/skills. Jestem prawie pewien, że instalator umiejętności nie wykryje zmiany nazwy, więc nie spróbuje zaktualizować to-prd na to-spec. Uruchomienie tej komendy jest najbezpieczniejszym sposobem, by pobrać wszystkie nowe umiejętności, bo możesz sam wybrać, które chcesz. A gdy już to zrobisz, przejdź przez folder z umiejętnościami i sprawdź, czy nie zostały tam żadne stare, złe wersje. Chodzi o to, żeby świadomie pobrać wszystkie właściwe umiejętności.
Poprawki w umiejętnościach „grillujących”
Kolejna zmiana to poprawka kilku błędów, które zgłaszali użytkownicy grill-me i grill-with-docs. Obie opierają się na centralnej referencyjnej umiejętności grillowania, która pokazuje modelowi, jak „przesłuchiwać” osobę.
(Informacja dodatkowa: „grillowanie” u Pococka oznacza tryb, w którym agent zamiast od razu wykonywać zadanie zadaje użytkownikowi serię pytań, żeby dokładnie zrozumieć jego intencje — alternatywa dla trybu planowania.)
Wyostrzyłem tu jedną linię, mówiąc, że zadawanie wielu pytań naraz jest dezorientujące. Nawet z instrukcją, żeby pytać po jednym, model czasem wciąż zadawał kilka pytań jednocześnie. Więc wyjaśniłem mu, dlaczego nie chcemy wielu pytań naraz.
Dodaliśmy też bramkę potwierdzenia na końcu: „nie wdrażaj planu, dopóki nie potwierdzę, że osiągnęliśmy wspólne zrozumienie”. Wielu ludzi na różnych modelach zgłaszało, że sesja grillowania po prostu się kończyła i model od razu przechodził do implementacji. To dodatkowe zabezpieczenie.
Wreszcie w niektórych sytuacjach model grillował sam siebie, co jest bardzo dziwne. Sam tego u siebie nie zauważyłem, ale widzę tylko niewielki wycinek tego, jak te umiejętności są faktycznie używane. Wprowadziłem więc kilka słów kluczowych, żeby rozróżnić fakty i decyzje. Wcześniej model używał poprzedniego sformułowania, po prostu eksplorując bazę kodu i grillując sam siebie — działo się to szczególnie z modelem Fable. Postanowiłem rozróżnić fakty (rzeczy, które sam znajdujesz, eksplorując kod) od decyzji (które musi podjąć użytkownik). Kilka zdań, kilka zmian — i stało się to znacznie bardziej spójne. Dostaję zdecydowanie mniej skarg na te dziwne sytuacje.
Nowa umiejętność implement i pełny cykl życia oprogramowania
Dodałem kilka umiejętności, które biorą proces będący dotąd głównie procesem planowania — nieprowadzącym cię za rękę aż do implementacji — i zamieniają go w prawdziwy cykl życia oprogramowania. Wielu ludzi pyta mnie: jaki jest przepływ? Jaki jest główny przepływ, którego mam używać z tymi umiejętnościami? Otóż oto on.
Po pierwsze — zamiast trybu planowania, każesz agentowi cię przegrillować. Wykorzystuje przy tym kilka dokumentów, które dodają glosariusz, żeby lepiej cię rozumieć w miarę pracy, oraz rejestry decyzji architektonicznych (ADR), żeby uchwycić rzeczy nieoczywiste.
(Informacja dodatkowa: ADR, czyli Architectural Decision Records, to krótkie notatki dokumentujące ważne decyzje architektoniczne i ich uzasadnienie.)
To, co powstaje w dokumentach z grillowania, trafia następnie do specyfikacji, jak widzieliśmy wcześniej. Specyfikacja definiuje cel — miejsce, do którego zmierzasz. Potem zamieniasz tę specyfikację na pojedyncze tickety, żeby rozłożyć rozwój na wiele sesji agenta. Temu służy to-tickets. Każdy z tych ticketów implementujesz następnie umiejętnością implement.
Umiejętność implement jest bardzo prosta. Wygląda tak: „Zaimplementuj pracę opisaną przez użytkownika w specyfikacji lub ticketach. Stosuj TDD tam, gdzie to możliwe, w uprzednio uzgodnionych szwach. Regularnie uruchamiaj sprawdzanie typów. Regularnie uruchamiaj pojedyncze pliki testowe. Pełny przebieg testów raz na końcu. Po zakończeniu użyj code-review do przeglądu pracy, a następnie zatwierdź (commit) pracę na bieżącej gałęzi”.
(Informacja dodatkowa: „szwy” (seams) to miejsca w kodzie, w których można wprowadzić testy lub oddzielić komponenty — termin z książki „Working Effectively with Legacy Code” Michaela Feathersa.)
Prawie nie zrobiłem umiejętności do tego, bo jest naprawdę prosta — opiera się głównie na wiedzy wbudowanej w agenta i w środowisko (harness), które uczy go, co robić. Szczerze mówiąc, nie sądziłem, że potrzebujemy tu umiejętności. Ale ludzie ciągle pytali o przepływ, więc pomyślałem: prosta umiejętność implement. Na każdym etapie procesu wywołujesz odpowiednią umiejętność. Dzięki temu implement zasługuje na swoje miejsce: gdy mamy już tickety, po prostu implementujemy każdy z nich w osobnej sesji kodowania.
Aktualizacja umiejętności code-review i „zapachy kodu” Fowlera
implement samo wywołuje code-review, którą wypromowałem z fazy „w toku” jeszcze w wersji pierwszej. Jest więc z nami od jakiegoś czasu, ale w tej wersji wprowadziłem kilka aktualizacji.
Idea umiejętności code-review polega na tym, że recenzuje kod na dwóch osiach — dla każdej uruchamia osobnego podagenta. Pierwsza oś to standardy: czy kod jest zgodny z udokumentowanymi standardami kodowania tego repozytorium? Jeśli masz gdzieś w repozytorium plik coding-standards.md, umiejętność go przeczyta i sprawdzi kod względem tych standardów. Generalnie uważam, że standardy kodowania powinny być poza plikiem agents.md — powinny być gdzieś osobno, a przegląd kodu to moment, w którym są najbardziej przydatne. Po standardach przechodzimy do specyfikacji: czy kod wiernie implementuje pierwotne zgłoszenie, PRD lub specyfikację? Oba podagenty działają równolegle i przechodzą przez każdą część po kolei.
Nowa i fajna rzecz w tej umiejętności: znów czytałem „Refactoring” Martina Fowlera. Postanowiłem wykorzystać to, że Fowler nazywa wiele różnych „zapachów”, które agent może rozpoznać w złym kodzie. „Refactoring” to książka tak stara i tak często cytowana, że te zapachy są głęboko zakorzenione w wiedzy agenta. Wystarczy więc przywołać ideę — „tajemnicza nazwa”, „zduplikowany kod”, „zazdrość o cechy” (feature envy), „skupiska danych” (data clumps), „obsesja na punkcie typów prostych” (primitive obsession), „powtarzające się instrukcje switch”, „rozbieżna zmiana”, „spekulatywna ogólność”, „łańcuchy komunikatów” (message chains). Wszystkie te pojęcia są głęboko w bazie wiedzy agenta i wystarczy opisać je jednym zdaniem. Odkryłem, że to skłania agenta do powtórzenia danego terminu i powiedzenia: „tak, znalazłem łańcuchy komunikatów, muszę je usunąć” albo „znalazłem sytuację z pośrednikiem (middleman), muszę to naprawić”.
(Informacja dodatkowa: „code smells” to charakterystyczne symptomy w kodzie sygnalizujące potencjalne problemy projektowe; katalog nazw pochodzi właśnie z książki Fowlera „Refactoring”.)
Testowałem to przez kilka tygodni i było skandalicznie użyteczne. Naprawdę świetnie poprawiało jakość mojego kodu, a dodanie tego jest bardzo tanie — jakieś dziesięć linii.
Wayfinder: planowanie dużych zadań ponad jedną sesją agenta
Przejdźmy do umiejętności, którą jestem naprawdę podekscytowany — zupełnie nowego podejścia do tego, jak inicjujemy i kształtujemy specyfikacje. To etap przed specyfikacją. Umiejętność ta może w niektórych sytuacjach zastąpić grill-with-docs i nazywa się Wayfinder.
Zrobię o Wayfinderze osobny wpis i osobny film, ale wystarczy powiedzieć, że w sytuacjach, w których myślisz o użyciu grill-with-docs, chciałbym, żebyś zamiast tego domyślnie sięgał po Wayfinder.
Wayfinder jest zaprojektowany do sytuacji, w których masz mnóstwo rzeczy do zaplanowania, ale jest to zbyt duże na jedną sesję agenta. Innymi słowy, wykroczysz poza „inteligentną strefę” (smart zone) agenta albo nawet poza jego okno kontekstowe. Musisz podzielić to na wiele części, żeby ustalić, dokąd zmierzasz.
(Informacja dodatkowa: „smart zone” to zakres zajętości kontekstu, w którym model zachowuje wysoką jakość odpowiedzi; przekroczenie go pogarsza rozumowanie, jeszcze zanim skończy się fizyczne okno kontekstowe.)
Opis brzmi tak: „Pojawił się luźny pomysł, zbyt duży na jedną sesję agenta i spowity mgłą. Droga stąd do celu nie jest jeszcze widoczna. Ta umiejętność wytycza drogę jako wspólną mapę w systemie śledzenia zgłoszeń repozytorium, a następnie realizuje jej tickety po kolei, aż trasa stanie się jasna”. Mapy te są zapisywane w GitHub Issues.
Na przykład ta mapa dotyczy repozytorium Sand Castle, gdzie robimy rozpoznanie (spike) pod kątem ewentualnego dołączenia AI SDK jako zależności — bardzo duża zmiana. Widać, że na razie nie podjęto żadnych decyzji, a wszystkie decyzje, które trzeba podjąć, są zapisane w podzgłoszeniach, i te podzgłoszenia mają relacje blokujące. Widać, że żadnej decyzji nie można podjąć, zanim nie podejmiemy tej kluczowej decyzji na początku. Każda z tych decyzji jest zwymiarowana tak, by zmieścić się w jednej sesji agenta.
Są oznaczone różnymi typami. Na przykład ta jest oznaczona jako zadanie badawcze (research) — to zadanie typu AFK, gdzie agent idzie, robi badania i wraca. Ta również jest badawcza, i ta. A ta to zadanie grillowania — wymaga sesji grillowania.
(Informacja dodatkowa: AFK, czyli „away from keyboard”, oznacza zadanie, które agent wykonuje samodzielnie, bez obecności człowieka przy klawiaturze.)
Typy ticketów są zdefiniowane na dole. Mamy więc: research (badanie), grilling (grillowanie), a także prototype (prototyp). Prototypowanie to coś, za czym ostatnio mocno się opowiadam — więcej prototypowania, zanim dojdziesz do specyfikacji. Idea jest taka, że podnosisz wierność dyskusji, tworząc tani, surowy, konkretny artefakt, na który można zareagować: szkicowe UI, logika, kod — poprzez umiejętność prototype. Ticket linkuje do prototypu jako zasobu. Opis mówi: „użyj, gdy kluczowym pytaniem jest »jak to ma wyglądać« lub »jak to ma się zachowywać«”. To niezbędne przy niemal wszystkim, co dotyka kodu front-endu. Zdecydowanie polecałbym Wayfinder do wszystkiego, co dotyczy front-endu.
Ostatni typ to po prostu „task” (zadanie): konfiguracja, którą trzeba ustawić, przydzielanie dostępów, przenoszenie danych do właściwego kształtu — cała ta nudna robota, która nie wymaga decyzji z grillowania i której AI nie może tak naprawdę zautomatyzować.
To, co ostatecznie otrzymujesz: po zamknięciu wszystkich tych ticketów wszystkie informacje trafiają na mapę, a pierwotne tickety pełnią rolę źródeł pierwotnych dla tego, co uchwycono. Możesz potem wziąć tę mapę i po prostu zamienić ją w specyfikację w zwykły sposób.
Odkryłem, że zamiast lęku o zarządzanie sesją w grill-with-docs — konieczności przekazywania stanu, martwienia się o inteligentną strefę — z Wayfinderem wszystko jest za mnie ogarnięte. Po prostu zamykam sesję i otwieram kolejny ticket Wayfindera. Wszystko jest zapisane w GitHubie, więc jest to wspólne, można to dzielić w zespole. A gdy mapa jest gotowa, po prostu przechodzisz do to-spec i możesz działać dalej.
Umiejętność research
Aby wspierać Wayfinder, mamy nową umiejętność research — bardzo małą, bardzo poręczną, gdy po prostu potrzebujesz przeprowadzić sesję badawczą. Wpływa też na model tak, by badał we właściwy sposób — a przynajmniej w taki, jaki lubię. Uruchamia agenta w tle do przeprowadzenia badania, żebyś mógł dalej pracować, gdy on czyta. „Zbadaj pytanie w oparciu o źródła pierwotne. Zapisz ustalenia w prostym pliku Markdown i umieść go tam, gdzie repozytorium już trzyma takie notatki — dopasuj się do istniejącej konwencji”. Jest to przydatne również wtedy, gdy potrzebujesz przeprowadzić jakiekolwiek badania — po prostu wywołujesz umiejętność research i gotowe.
Umiejętność prototype
Kolejna to prototype, którą pokazywałem już wcześniej — chyba nie zrobiłem jednak o niej pełnego filmu. Teraz jest wywoływana przez model, tak by Wayfinder mógł wywołać ją samodzielnie. Zasadniczo daje wybór między logiką a stanem: to albo prototyp logiki, albo prototyp UI, a te reagują dość odmiennie.
Zmiana w umiejętności TDD
Ostatnia zmiana to coś, o co ludzie prosili od dawna i na co w końcu się zdecydowałem. Wcześniej moja umiejętność TDD rekomendowała zestaw kroków do wykonania, co czasem było trochę niezręczne. Kroki wyglądały tak, że model uzgadniał z tobą, jakie testy chce napisać, a potem prowadziłeś go krok po kroku — i to nie pasowało do tego, jak większość ludzi wyobraża sobie TDD. Powinno być tak, że możesz przekazać umiejętność TDD agentowi działającemu w trybie AFK i to po prostu zadziała.
Dlatego umiejętność TDD jest teraz wyłącznie materiałem referencyjnym. Nie określa żadnych konkretnych kroków poza kolejnością, w jakiej powinieneś pisać testy — czyli red-green-refactor. Mówi po prostu: „red przed green, jeden wycinek naraz”. Oddziela też refaktoryzację jako coś, co nie jest częścią pętli. To już nie jest pętla red-green-refactor, tylko po prostu red-green. Uważam, że umieszczenie refaktoryzacji w części przeglądu kodu (code-review) jest znacznie bardziej produktywne, bo wtedy nie przeciążasz implementacji.
(Informacja dodatkowa: red-green-refactor to klasyczny cykl TDD — najpierw piszesz test, który nie przechodzi (red), potem minimalny kod, żeby przeszedł (green), a na końcu porządkujesz kod (refactor).)
Podsumowanie i zapowiedź kursu
To wszystkie zmiany, które trafiły do umiejętności. To dużo zmian. Jeśli obawiasz się, że przegapisz jakieś aktualizacje, polecam wyczyścić wszystkie umiejętności i uruchomić npx skills update, żeby pobrać wszystkie nowe. Jeśli w międzyczasie sam wprowadziłeś zmiany w swoich umiejętnościach, możesz po prostu skierować swojego agenta na moje repozytorium i powiedzieć: „ściągnij wszystkie dobre nowości”, zwłaszcza wskazując na notatki wydania (release notes).
Myślę, że to wydanie zostanie zapamiętane ze zmiany na to-spec i to-tickets, bo to trochę tarcia — ale dobrego tarcia, bo nazywa rzeczy właściwie. Mam też nadzieję, że będzie to początek waszej obsesji na punkcie Wayfindera. Sam używam go dosłownie do wszystkiego, nawet do rzeczy niezwiązanych z kodowaniem. Planowałem nim mój następny kurs i sprawdza się naprawdę świetnie.
A skoro o tym mowa — pokażę wam ten kurs. To „AI Coding Crash Course”. Będzie się różnił od kohort, które zwykle prowadzę. Będzie znacznie tańszy i samodzielny (self-paced), więc możesz go kupić w dowolnym momencie. Dostajesz pomoc na Discordzie w zwykły sposób, ale nie będzie on ograniczany bramkami jak normalna kohorta. To będzie idealne wprowadzenie dla każdego, kto chce wejść w programowanie z AI — niezależnie od tego, czy jesteś programistą, czy nie. Dla starszych inżynierów będzie to kurs konwersyjny, a dla osób nowych w programowaniu — sposób, by faktycznie stać się produktywnym z tymi szalonymi nowymi narzędziami. Nie ogłosiłem jeszcze ceny. Będę po prostu dodawał zapisy, a kurs będzie dostępny, gdy skończę go nagrywać — myślę, że może w okolicach sierpnia.
Dziękuję wam bardzo za oglądanie. To zawsze przyjemność dzielić się z wami aktualizacjami umiejętności. Naprawdę fajnie jest patrzeć, jak użycie po prostu rośnie i rośnie. Wszyscy mówią, że nie powinienem pokazywać liczby gwiazdek, ale doszła już do jakichś 160 tysięcy. Na Skills.sh jest 7 milionów pobrań. To po prostu szaleństwo. Dziękuję, że korzystacie z tych umiejętności. Mam nadzieję, że pomagają wam dostarczać więcej i pracować produktywniej — do zobaczenia wkrótce.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nazywaj artefakty właściwie: „spec” i „ticket” zamiast „PRD” i „issue”
Na czym polega: Pocock zmienił nazwy to-prd → to-spec i to-issues → to-tickets, bo faktycznie tworzył specyfikacje (szersze niż PRD) i chciał terminu niezależnego od GitHuba/Lineara.
Jak stosować: Traktuj „specyfikację” jako dokument celu (co budujemy, techniczny lub nie), a „tickety” jako drogę do jego realizacji. Nazewnictwo porządkuje myślenie o etapach pracy.
Na co uważać: Instalator umiejętności nie wykryje zmiany nazwy automatycznie — musisz usunąć stare umiejętności, pobrać nowe (npx skills add) i ręcznie przejść przez folder, żeby nie zostały duplikaty.
2.Wymuszaj bramki potwierdzenia między planowaniem a implementacją
Na czym polega: Modele często kończyły sesję grillowania i od razu przechodziły do implementacji; dodano jawną instrukcję „nie wdrażaj, dopóki nie potwierdzę wspólnego zrozumienia”.
Jak stosować: W każdym własnym promptie planistycznym dodaj wyraźną bramkę wymagającą potwierdzenia użytkownika przed przejściem do działania.
Na co uważać: Zachowanie różni się między modelami — to, co działa u jednego, może zawodzić u innego (Fable szczególnie „grillował sam siebie”). Testuj na modelu, którego faktycznie używasz.
3.Rozróżniaj „fakty” i „decyzje” w instrukcjach dla agenta
Na czym polega: Aby agent nie zadawał sobie pytań zamiast użytkownikowi, Pocock wprowadził rozróżnienie: fakty znajdujesz sam, eksplorując kod; decyzje musi podjąć użytkownik.
Jak stosować: W promptach jawnie oznaczaj, czego agent ma szukać samodzielnie, a co musi skonsultować z człowiekiem. Kilka precyzyjnych słów kluczowych potrafi znacząco zmienić zachowanie.
Na co uważać: Bez tego rozróżnienia agent może „halucynować” decyzje na podstawie kodu zamiast dopytać — co daje pozornie kompletne, ale błędne plany.
4.Domknij cykl: od grillowania przez spec i tickety do implementacji
Na czym polega: Nowa umiejętność implement przekształca proces czysto planistyczny w pełny cykl życia: grill → spec → tickety → implementacja → code review → commit.
Jak stosować: Rozbij duże zadanie na tickety i implementuj każdy w osobnej sesji agenta, wywołując na końcu każdego etapu odpowiednią umiejętność. Utrzymuje to porządek i mieści pracę w kontekście.
Na co uważać: Sama umiejętność implement jest celowo minimalna i polega na wiedzy wbudowanej agenta — na słabszym modelu lub bez dobrego środowiska może nie wystarczyć bez dodatkowych instrukcji.
5.Recenzuj kod na dwóch osiach: standardy i zgodność ze specyfikacją
Na czym polega: code-review uruchamia dwóch równoległych podagentów — jeden sprawdza zgodność ze standardami kodowania repo, drugi wierność implementacji względem pierwotnej specyfikacji.
Jak stosować: Trzymaj standardy kodowania w osobnym pliku (coding-standards.md), a nie w agents.md — przegląd kodu to moment, w którym są najbardziej przydatne. Rozdziel weryfikację „jak” (standardy) od „co” (spec).
Na co uważać: Jeśli nie masz udokumentowanych standardów, oś standardów nie ma się o co oprzeć — warto je najpierw spisać.
6.Wykorzystuj „zapachy kodu” Fowlera jako słowa wyzwalające dla agenta
Na czym polega: Nazwy zapachów z „Refactoring” (feature envy, data clumps, primitive obsession, message chains itd.) są głęboko w wiedzy modelu; wystarczy je krótko przywołać, by agent je rozpoznawał i nazywał.
Jak stosować: W instrukcjach przeglądu wypisz katalog nazwanych zapachów z jednozdaniowym opisem każdego — to tanie (ok. 10 linii) i wyraźnie podnosi jakość recenzji.
Na co uważać: Efekt opiera się na wiedzy pretreningowej modelu o konkretnej, klasycznej książce; przy niszowych czy nowych pojęciach ta sztuczka nie zadziała tak dobrze.
7.Przy dużych zadaniach planuj Wayfinderem, dzieląc pracę na wiele sesji
Na czym polega: Wayfinder wytycza „mapę” dużego, mglistego zadania jako zestaw powiązanych zgłoszeń w GitHub Issues, każde zwymiarowane na jedną sesję agenta, z relacjami blokującymi.
Jak stosować: Sięgaj po Wayfinder, gdy zadanie przekroczy inteligentną strefę lub okno kontekstowe pojedynczej sesji. Zamykasz jedną sesję, otwierasz kolejny ticket — stan jest zapisany w GitHubie i współdzielony w zespole.
Na co uważać: Wymaga trackera zgłoszeń (GitHub Issues) i dyscypliny w wymiarowaniu ticketów; przy małych zadaniach to nadmiarowa ceremonia — wtedy wystarczy zwykłe grillowanie.
8.Prototypuj wcześnie, by podnieść wierność dyskusji
Na czym polega: Umiejętność prototype tworzy tani, surowy, konkretny artefakt (UI albo logika), na który można zareagować, zanim powstanie specyfikacja.
Jak stosować: Używaj prototypu zawsze, gdy kluczowe pytanie brzmi „jak to ma wyglądać/zachowywać się” — szczególnie przy czymkolwiek dotyczącym front-endu. Wybierasz między prototypem logiki a prototypem stanu/UI.
Na co uważać: Prototyp to artefakt do reakcji, nie produkcyjny kod — nie traktuj go jako gotowej implementacji ani nie inwestuj w jego dopracowanie.
9.Deleguj badania agentowi w tle w oparciu o źródła pierwotne
Na czym polega: Mała umiejętność research uruchamia agenta w tle, który bada pytanie, opierając się na źródłach pierwotnych, i zapisuje ustalenia w Markdown zgodnie z konwencją repo.
Jak stosować: Wywołuj research, gdy chcesz pracować dalej, a agent w tym czasie czyta i notuje. Instrukcja „match the existing convention” utrzymuje notatki spójne z resztą repozytorium.
Na co uważać: Jakość zależy od tego, czy agent faktycznie dotrze do wiarygodnych źródeł pierwotnych — warto weryfikować ustalenia, zwłaszcza przy zadaniach AFK.
10.W TDD rozdziel red-green od refaktoryzacji
Na czym polega: Umiejętność TDD stała się wyłącznie materiałem referencyjnym: „red przed green, jeden wycinek naraz”, a refaktoryzację przeniesiono z pętli do etapu code review.
Jak stosować: Nie przeładowuj fazy implementacji poprawianiem struktury — najpierw zielone testy wycinek po wycinku, a porządkowanie zostaw na przegląd kodu. Dzięki temu skill działa też dla agenta AFK.
Na co uważać: To odejście od klasycznej pętli red-green-refactor — jeśli twój zespół oczekuje refaktoryzacji w każdym cyklu, ustal jawnie, że dzieje się ona później, na etapie recenzji.