O czym jest ten film
- Autor przedstawia Wayfinder — skill do planowania z agentem AI zadań dowolnej wielkości, także takich, które nie mieszczą się w jednej sesji.
- Dotychczasowe narzędzia do planowania były zbyt przywiązane do pojedynczej sesji i kazały dopasowywać ambicję projektu do ograniczeń AI.
- Kluczowa metafora: planowanie jak podróż z mglistego punktu startu do celu, gdzie trzeba stopniowo „rozpraszać mgłę wojny”.
- Wayfinder buduje mapę zadań (ticketów), gdzie każdy ticket to osobna sesja z agentem: badanie, prototyp, rozmowa lub zadanie do wykonania.
- Cztery typy ticketów: research, prototype, grilling (rozmowa) i task; są wpisane wprost do trackera zadań.
- Wszystko trzyma w zwykłym issue trackerze (GitHub, ale też Linear, Jira — jest agnostyczny) jako mapę-nadrzędną z podzadaniami.
- Praca polega na przechodzeniu przez „frontier” — decyzje możliwe do podjęcia teraz — i obserwowaniu, jak zamknięcie ticketu odsłania kolejne.
- Prototypy są zabezpieczeniem przed tym, by dużo planowania z góry nie zamieniło się w waterfall.
- Z gotowej mapy tworzy się spec, a z niego tickety wykonawcze; spec jest u autora nietrwały — po wdrożeniu jest kasowany.
- Wayfinder sprawdza się też poza kodem (autor planował nim budowę ogrodowego biura); używać go tylko wtedy, gdy pracy nie da się zaplanować w jednej sesji.
Redakcyjne tłumaczenie
Dlaczego dotychczasowe planowanie było za ciasne
Wydaje mi się, że znalazłem sposób, by zaplanować z agentem pracę dowolnej wielkości. Narzędzia do planowania, których używałem i którymi się bawiłem — nawet te, które sam stworzyłem — wydawały mi się zbyt ograniczone, zbyt przywiązane do pojedynczej sesji. Czułem, że nie mogę być wystarczająco ambitny. A przez to zacząłem przykrawać to, co buduję, tak żeby pasowało do AI — co nie wydaje mi się właściwe. To nowe podejście nie ma tego limitu.
Możesz zaplanować ogromne fragmenty pracy, a Wayfinder poprowadzi to planowanie przez wiele różnych sesji. Wie, że do celu nie da się dojść w linii prostej — najpierw trzeba rozproszyć mgłę wojny. Rozumie decyzje zależne od siebie, a nawet pozwala planować równolegle. Najlepsze jest to, że opiera się na fundamentach — na podstawach planowania pracy, których nauczyłem się, gdy byłem prawdziwym programistą, jeszcze przed erą AI. Spakowałem to wszystko w skill, który jest już dostępny w moim repozytorium skilli i nazywa się Wayfinder.
(Informacja dodatkowa: „skill” to u Pococka wielokrotnego użytku zestaw instrukcji dla agenta kodującego, wywoływany po nazwie w trakcie sesji).
Ograniczenie pojedynczej sesji
Wcześniej planowałem pracę w sposób mocno przywiązany do jednej sesji. Chodzi o skill „grill me” (albo „grill with docs”) z mojego repozytorium. To wciąż bardzo ważny prymityw, ale działa tylko w obrębie jednej sesji. Część pracy jest większa, niż zdołasz zmieścić w oknie kontekstowym — a zwłaszcza w tej „inteligentnej strefie” okna kontekstowego agenta. I wiesz o tym z góry.
(Informacja dodatkowa: „grilling” to sesja, w której agent przepytuje autora, żeby wyciągnąć z niego wymagania; „smart zone” to ta część kontekstu, w której model jeszcze pracuje na pełnej jakości).
Dlatego często przed takimi sesjami z agentem poświęcasz czas na rozbicie zadania na mniejsze kawałki: „O, urwę sobie ten kawałek, potem tamten”. Ale wtedy okazuje się, że pracując nad jednym fragmentem grillingu, dochodzisz do pytania, na które nie potrafisz odpowiedzieć, albo po prostu gubisz się we mgle — i cały czas zarządzasz tą inteligentną strefą, starając się nie spalić zbyt wielu tokenów.
To narzędzie jest dostępne już od jakiegoś czasu i ludzie je uwielbiają. Ktoś jednym podejściem zbudował prototyp, który wcześniej przez miesiące zaczynał od nowa raz za razem. Nie znoszę słowa „oneshotting”, ale sądzę, że chodziło mu o to, że Wayfinder naprawdę mu pomógł. John zbudował nawet własny harness, bo tak polubił to podejście — ma taką śliczną mapę gwiazd, która pozwala odhaczać zadania po drodze. Wreszcie kręcę film, o który ludzie mnie prosili: czym jest Wayfinder i jak go najlepiej używać.
Jak wygląda planowanie dużej pracy
Zacznijmy od tego, jak zwykle planuje się dużą pracę. Masz punkt startu — miejsce, z którego musisz wyruszyć, jakiś mglisty pomysł, bez wyraźnego planu dotarcia — i próbujesz dojść do jakiegoś celu. Z grubsza wiesz, gdzie chcesz wylądować, ale kroki pomiędzy są zamglone. To prawda w inżynierii, ale też w wielu innych dziedzinach życia, gdy planujesz coś ambitnego.
Pierwsze, co warto zrobić, to sesja grillingu: agent przepytuje cię i ustala podstawowe założenia tego, dokąd zmierzasz. Dla części zadań to wystarczy i od razu dojdziesz do celu, ale przy wielu pracach wciąż zostaniesz w gęstej mgle. Może się okazać, że na podstawie tej pierwszej rozmowy potrzebujesz kolejnych sesji — sesji prototypowania, kolejnej sesji grillingu albo osobnego zadania badawczego.
Mapa, tickety i mgła wojny
Koncepcyjnie patrzymy tu na mapę. Tworzymy mapę tego, jak docieramy do celu — i właśnie dlatego to się nazywa Wayfinder: odnajdujemy drogę do celu. Każdy element na tej mapie to ticket, a każdy ticket wymaga osobnej sesji z agentem. Możesz więc mieć sesję prototypu, sesję grillingu i sesję badawczą — a wszystkie tworzy i zarządza nimi Wayfinder. I mała uwaga: to wszystko robi jeden skill. Działa z dowolnym agentem kodującym.
Na swojej mapie Wayfinder daje ci „frontier”, czyli zbiór ticketów, o których już wie — decyzji, które da się podjąć na tym etapie. Śledzi też wszystko, co wciąż tkwi we mgle: rzeczy, o których nie da się jeszcze zdecydować, bo nie zrobiliśmy badania, nie mamy prototypu do obejrzenia albo za mało rozmawialiśmy. W pewnym momencie cała mgła zostaje rozproszona i wtedy masz już dość podjętych decyzji, żeby wreszcie dotrzeć do celu.
Wayfinder potrafi zarządzać nie tylko badaniami, ale też realnymi zadaniami. Jeśli trzeba coś skonfigurować albo z kimś porozmawiać i załatwić sprawę w świecie, Wayfinder też to rozpisze. Innymi słowy: całą skomplikowaną robotę, którą trzeba wykonać przy planowaniu czegoś dużego, Wayfinder ci orkiestruje. Pilnuje, co już zrobiono, mierzy mgłę wojny i trzyma listę wszystkiego, o czym można zdecydować już teraz.
Gdzie to wszystko jest przechowywane
Jak Wayfinder to śledzi? Robi to w twoim issue trackerze — w moim przypadku w publicznym repozytorium „course video manager”. Są tam wszystkie moje ostatnie mapy Wayfindera. Jedna z nich to duża mapa nadrzędna, a pod nią dwanaście podzadań — to są tickety decyzyjne. Można zejść w dół i prześledzić wszystkie podjęte decyzje. Gdy decyzja zapada, zostaje rozwiązana wewnątrz ticketu — na przykład podzadanie „zamknij wyścig przy publikacji klipów” rozwiązaliśmy w dyskusji kilka tygodni temu. To rozwiązanie zostaje też wpisane z powrotem do mapy nadrzędnej, w skróconej formie.
Wayfinder śledzi więc wszystkie podjęte decyzje, wszystkie stworzone prototypy i wykonane zadania. I choć używam do tego GitHuba, moje skille są agnostyczne wobec trackera. Możesz użyć Lineara, Jiry albo czegokolwiek chcesz — wystarczy odrobina konfiguracji przez skill „setup map”.
Uruchomienie sesji: cel i pierwsze tickety
Pierwsze, co musisz ustalić przy starcie nowej sesji Wayfindera, to cel. W jednym przypadku dodawałem do aplikacji paletę poleceń z zestawem nowych akcji, a tym, czego ostatecznie chciałem, była gotowa do zbudowania specyfikacja — spec dla palety „Cmd+K” w oknie diagramu CVM.
(Informacja dodatkowa: CVM to autorska aplikacja Pococka, „course video manager”; paleta Cmd+K to szybkie menu poleceń wywoływane skrótem).
Zacząłem tak: wywołałem skill Wayfinder i opisałem, czego chcę — możliwości dodania w CVM pickera ikon, wyszukiwania innych diagramów, kopiowania rzeczy z diagramu i zapisywania ich. Duży kawał roboty. Wayfinder przeszedł przez repozytorium, wywołał skill grillingu i przepytał mnie o to, czego chcę. Najpierw zapytał, jak wygląda „gotowe” i czy chcę spec — i sam go zarekomendował, co jest dobre. Potem zadał kilka wstępnych pytań, a następnie stworzył pierwsze tickety i pierwszą mapę, dopisując pozostałe tickety jako podzadania.
Wystartowaliśmy od razu z siedmioma ticketami. Ale tylko trzy dało się wziąć od ręki: „skąd biorą się nazwy ikon”, „schemat przechowywania komponentów” oraz „architektura informacji palety”. Przeszedłem przez każdy z nich w nowej sesji — po prostu wywołując Wayfinder na nazwie danego ticketu. Robiłem to w nieco fikuśniejszy sposób, bo mam skill „handoff”, który automatycznie pisze mi prompt i uruchamia podagenta Claude, ale w istocie sprowadza się to do wywołania skillu Wayfinder na konkretnej mapie i konkretnym tickecie.
Tak właśnie pracuje się z mapą Wayfindera: robisz jeden początkowy prompt, żeby naszkicować mapę i wyłonić następny ticket, a potem dla każdego ticketu piszesz „Wayfinder” z jego URL-em. Używasz Wayfindera do obu rzeczy — do naszkicowania mapy i do przechodzenia przez kolejne tickety.
Cztery typy ticketów
Tickety mają różne typy — jest ich cztery, i są one wniesione wprost do issue trackera.
Research — badanie: agent idzie znaleźć informacje i przynieść je z powrotem. Zwykle rusza od razu, więc nie musisz nawet tego oglądać; robi to w podagencie i raportuje.
Prototype — prototyp: tworzy prototyp, co jest nieprawdopodobnie cenne, bo pozwala naprawdę zobaczyć, jak rzeczy nabierają kształtu w trakcie planowania. Nagrałem o tym osobny film i Wayfinder korzysta z tego samego skillu prototypowania. Niektórzy patrzą na Wayfinder i myślą: „Boże, ile tu planowania — czy to nie wygląda jak waterfall?”. I to właśnie prototypy chronią przed zsunięciem się w waterfall. Ogromne ilości niskorozdzielczego planowania z góry, a prototyp to wysokorozdzielczy sposób na zebranie realnej informacji zwrotnej o tym, co faktycznie budujesz. To, że Wayfinder zachęca do budowania tylu prototypów, sprawia, że efekt jest nieprawdopodobnie dobry.
(Informacja dodatkowa: waterfall to kaskadowy model wytwarzania, w którym cały projekt planuje się szczegółowo z góry przed rozpoczęciem realizacji — krytykowany za brak elastyczności).
Grilling — rozmowa: tam, gdzie potrzebna jest dyskusja, na przykład o szczególe implementacyjnym albo o konkretnym aspekcie planu.
Task — zadanie: rzeczy do wykonania w realnym świecie, których agent nie potrafi zrobić sam, albo takie, które sam mógłby zrobić, ale są zaplanowane za inną pracą.
Relacje blokujące i przesuwający się frontier
Naprawdę fajną rzeczą w Wayfinderze jest to, jak ustala relacje blokujące między ticketami, bo część decyzji da się podjąć dopiero po podjęciu innych. Na jednej z map mam czternaście z siedemnastu ticketów zrobionych — sporo roboty — a mimo to wciąż nie zbudowaliśmy skillu, wokół którego cała mapa jest zbudowana. Dopiero gdy zbudujemy ten skill, będziemy musieli wrócić do paru innych rzeczy w zależności od tego, jak skill działa i co realnie poprawia.
Dlatego pracując z mapą Wayfindera, robisz często tak: „Dobra, rozwiązałem ten ticket. Zobaczmy, jakie nowe tickety to otwiera. Dokąd przesunął się frontier?”.
Od mapy do specyfikacji, do ticketów wykonawczych
Kiedy mapa jest gotowa, co z nią robisz? Ponieważ w tym przypadku celem był spec, sama mapa Wayfindera jest zwykle zbyt gęsta, żeby być specyfikacją. Dlatego lubię tworzyć spec na podstawie mapy. Dosłownie wywołałem „to spec” na mapie Wayfindera i wciągnęło to olbrzymi dokument z praktycznie wszystkimi decyzjami z mapy do jednego issue na GitHubie. Pierwsza wersja była nawet za duża jak na limit znaków GitHuba — co coś mówi o jej rozmiarze. Stamtąd zamieniłem ją w tickety moim zwykłym sposobem: „to spec”, a potem „to tickets”.
Innymi słowy, Wayfinder wchodzi dokładnie tam, gdzie w moim zwykłym procesie stoi „grill with docs”. Zamiast robić „grill with docs”, a potem „to spec” i „to tickets”, spędzasz znacznie więcej czasu w Wayfinderze, tworząc tę ogromną mapę, a potem zamieniasz mapę w spec, spec w tickety, wdrażasz każdy ticket i na końcu odpalasz code review.
Świetne w tej konfiguracji jest to, że specyfikacje, które powstają, są tak gęste i wszystkie linkują z powrotem do pierwotnych ticketów decyzyjnych. Agent może więc pójść i sięgnąć do pierwotnego źródła, jeśli czegoś nie rozumie. To była zawsze słabość „grill with docs”: musiałeś polegać na tym, że spec jest źródłem prawdy, a spec to tylko streszczenie tego, co faktycznie padło na spotkaniu. Teraz, z Wayfinderem, masz dostęp do pierwotnego źródła — co jest genialne.
To właśnie jest Wayfinder: sposób na zmapowanie ogromnych fragmentów pracy przez szczegółowe rozplanowanie ich z wyprzedzeniem. Radzi sobie z prototypowaniem, badaniami, dowolnymi zadaniami i dyskusjami.
FAQ
„To o wiele za dużo procesu, za ciężkie jak na moją pracę — kiedy właściwie tego używać?”
Jeśli sądzisz, że twoją pracę da się ukończyć i zaplanować w jednej sesji, to zaplanuj ją w jednej sesji. Jeśli w zasadzie już znasz drogę do celu, nie ma potrzeby sięgać po Wayfinder — po prostu przejdziesz tę drogę w jednej sesji. Wayfinder jest do sytuacji, gdy masz mgłę wojny: nie wiesz dokładnie, dokąd iść, i musisz po prostu zacząć, a potem zobaczyć, dokąd dojdziesz. Nawiasem mówiąc, używam Wayfindera także do zadań niezwiązanych z kodem — od dawna chciałem postawić w ogrodzie biuro i użyłem go właśnie do tego: zlecenie badania działki, ustalenie, kogo skontaktować, cały research, znalezienie różnych firm, które mogłyby to zbudować. Rewelacja.
„To przecież spec-driven development, a ja nie chcę marnować czasu na budowanie specyfikacji.”
Ja myślę o specyfikacji po prostu jako o celu dla wielosesyjnej pracy. Mamy ogromne zadanie, powiedzmy zadanie numer cztery, które chcemy rozłożyć na wiele sesji agenta, bo jest zbyt duże. Potrzebujemy specu, żeby, dochodząc do końca, wiedzieć, dokąd zmierzaliśmy. Tyle w tym kontekście znaczy spec — to dokument-cel, który spina wielosesyjną pracę. A każda sesja jest realizowana w osobnym tickecie wykonawczym.
Zamieszanie: decyzja czy implementacja?
Ludzie przy pierwszym użyciu Wayfindera się gubią: „Tworzy tickety, ale przecież tickety robi się później”. Trzeba rozróżnić: w Wayfinderze masz tickety decyzyjne, a osobno tickety implementacyjne. Różnica między moim podejściem a większością innych polega na tym, że gdy inni dochodzą do końca, zachowują ten spec gdzieś na stałe. Ja zamykam issue zawierające spec i spec znika — znika z repozytorium i rzadko kiedy do niego wracam. Gdy spec jest już obecny w kodzie, można go po prostu skasować. Ludzie robiący spec-driven development wracają do specu, edytują go i modyfikują. Podejść jest wiele, więc pewnie kogoś tym irytuję, ale sedno jest takie, że u mnie te specy są nietrwałe.
(Informacja dodatkowa: spec-driven development to podejście, w którym specyfikacja jest utrzymywanym, trwałym źródłem prawdy; Pocock celowo robi odwrotnie — spec u niego jest jednorazowy).
Zakończenie
Idź więc i naszkicuj swój własny mglisty pomysł. Wayfinder jest dla mnie wyzwalający — pozwala po prostu zacząć i sam bierze na siebie te trudne decyzje. Używałem go do planowania kursów, do pracy inżynierskiej i do budowy ogrodowego biura. Fajne jest to, że cel należy w pełni do ciebie: czy chcesz, by stworzył spec, który potem przepuszczasz przez agenta działającego „na off” (Informacja dodatkowa: AFK — „away from keyboard”, czyli agent pracujący samodzielnie bez nadzoru), tak jak robię ja, czy wolisz, żeby po prostu wykonał pracę za ciebie w postaci zadań — jedno i drugie potrafi. Nie ma przyjemniejszego uczucia niż start nowej sesji Wayfindera z pewnością, że zobaczysz coś świetnego, ale bez pewności, jak tam dojdziesz.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wayfinder znosi limit pojedynczej sesji
Na czym polega: To skill, który orkiestruje planowanie dużego zadania przez wiele sesji z agentem, zamiast wciskać całość w jedno okno kontekstowe.
Jak stosować: Sięgaj po niego, gdy z góry wiesz, że pracy nie da się zmieścić w jednej sesji — rozbij ją na mapę ticketów, z których każdy jest osobną sesją.
Na co uważać: Przy małych, jasnych zadaniach to nadmiarowy proces. Jeśli znasz drogę do celu, zaplanuj to w jednej sesji.
2.Metafora mgły wojny jako narzędzie decyzyjne
Na czym polega: Planowanie to droga z mglistego startu do celu; nie da się iść w linii prostej, najpierw trzeba rozproszyć mgłę — czyli podjąć decyzje odblokowujące kolejne.
Jak stosować: Rozdziel to, o czym możesz zdecydować teraz (frontier), od tego, co czeka na badanie, prototyp lub rozmowę. Pracuj po froncie, nie po kolejności życzeń.
Na co uważać: Nie próbuj wymusić decyzji tkwiących we mgle — to marnowanie tokenów; najpierw zdobądź informację, która je odblokuje.
3.Cztery typy ticketów: research, prototype, grilling, task
Na czym polega: Każdy element mapy ma typ określający rodzaj sesji — badanie, prototyp, rozmowa lub realne zadanie do wykonania.
Jak stosować: Świadomie nadawaj typ, bo determinuje sposób pracy: research i task mogą iść w podagencie bez nadzoru, grilling i prototype wymagają twojego udziału.
Na co uważać: Nie każdy ticket agent zrobi sam — tickety typu „task” to często rzeczy w świecie realnym (telefon, konfiguracja, wizyta), które musisz wykonać osobiście.
4.Prototypy chronią przed waterfallem
Na czym polega: Dużo niskorozdzielczego planowania z góry grozi kaskadowością; prototyp to wysokorozdzielczy sposób na wczesną informację zwrotną o realnym produkcie.
Jak stosować: Wpleć tickety prototypowe wcześnie i często — im więcej prototypów, tym lepsza jakość finalnego planu.
Na co uważać: Sam plan bez prototypów łatwo staje się oderwaną od rzeczywistości specyfikacją. Traktuj prototyp jako test założeń, nie ozdobnik.
5.Cała mapa żyje w zwykłym issue trackerze
Na czym polega: Wayfinder trzyma mapę jako issue nadrzędne z podzadaniami; decyzje rozwiązywane w ticketach są dopisywane z powrotem do mapy.
Jak stosować: Używaj swojego istniejącego trackera (GitHub, Linear, Jira) — skonfiguruj go przez „setup map”. Nie potrzebujesz osobnego narzędzia.
Na co uważać: Wymaga jednorazowej konfiguracji pod dany tracker; bez niej domyślnie celuje w GitHuba.
6.Jeden skill do dwóch ról: szkicowanie mapy i przechodzenie ticketów
Na czym polega: Ten sam skill wywołujesz raz, by naszkicować mapę i wyłonić następny ticket, a potem osobno na URL-u każdego ticketu.
Jak stosować: Zacznij od promptu ogólnego (opis celu), potem iteruj: rozwiąż ticket, sprawdź, jakie nowe otworzył, i podejmij kolejny z frontu.
Na co uważać: Nie próbuj robić wszystkiego w jednym wywołaniu — sens polega na wracaniu po każdym rozwiązanym tickecie i obserwowaniu, jak przesuwa się frontier.
7.Relacje blokujące porządkują kolejność decyzji
Na czym polega: Wayfinder ustala zależności — część decyzji da się podjąć dopiero po innych, więc mapa sama pilnuje kolejności.
Jak stosować: Zaufaj blokadom: nawet gdy większość ticketów jest zrobiona, kluczowy element (np. sam budowany skill) może wciąż blokować rewizję reszty.
Na co uważać: „14 z 17 zrobione” nie znaczy „prawie koniec” — pozostałe tickety mogą być tymi, które wymuszą powrót do wcześniejszych.
8.Spec powstaje z mapy i linkuje do pierwotnych źródeł
Na czym polega: Gęsta mapa jest zamieniana w spec, a ten w tickety wykonawcze; spec zachowuje linki do oryginalnych ticketów decyzyjnych.
Jak stosować: Gdy agent czegoś nie rozumie w specu, pozwól mu sięgnąć do pierwotnego źródła decyzji — to usuwa słabość zwykłych speców będących tylko streszczeniem.
Na co uważać: Spec z gęstej mapy potrafi przekroczyć limity znaków (u autora przebił limit GitHuba) — bądź gotów podzielić go lub przenieść.
9.Spec jako nietrwały dokument-cel
Na czym polega: Autor traktuje spec wyłącznie jako cel dla wielosesyjnej pracy; po wdrożeniu w kod kasuje go i do niego nie wraca.
Jak stosować: Jeśli chcesz odchudzić repozytorium, po zaimplementowaniu specyfikacji usuwaj ją — kod staje się źródłem prawdy.
Na co uważać: To celowo sprzeczne z klasycznym spec-driven development, gdzie spec jest utrzymywany. Wybierz świadomie — nietrwały spec oznacza brak jednego trwałego dokumentu do audytu.
10.Zastosowania wykraczają poza kod
Na czym polega: Metoda opiera się na fundamentach planowania pracy, więc działa też poza inżynierią — autor planował nią budowę ogrodowego biura i tworzenie kursów.
Jak stosować: Używaj Wayfindera do każdego ambitnego, mglistego przedsięwzięcia wieloetapowego — research firm, ustalanie kontaktów, harmonogram zadań w świecie realnym.
Na co uważać: To wciąż narzędzie do sytuacji z „mgłą wojny”. Przy zadaniu, którego drogę już znasz, cały ten aparat będzie tylko zbędnym narzutem.