O czym jest ten film
- Pełny, pięcioetapowy proces przeprowadzenia pomysłu na aplikację aż do działającego produktu przy pomocy Claude Code.
- Punktem wyjścia jest realny problem: brak trackera do programu treningowego dostarczanego w tygodniowych PDF-ach.
- Etap 1 — zamiana surowych notatek w „lekki PRD” za pomocą własnego skilla, który dopytuje o niejasności.
- Etap 2 — faza deep research (domena + strona techniczna) z adwersaryjną weryfikacją wyłapanych faktów.
- Etap 3 — przełożenie PRD na koncepcję UX i konkretne ekrany, a następnie projekt w Claude Design.
- Etap 4 — podział pracy na pionowo pokrojone epiki i praca w narzędziu spec-driven (OpenSpec).
- Etap 5 — autonomiczna implementacja epików w pętli, z sub-agentami i adwersaryjnym review po każdej fazie.
- Kluczowa dyscyplina: agresywne trzymanie zakresu MVP i wybieranie zawsze lżejszej opcji.
- Pokaz realnych ograniczeń: generatywne UI bywa niedeterministyczne, część ekranów wyszła niekompletnie.
- Zamykająca praktyka: zgłaszanie błędów jako issues w GitHubie i workflow, który cyklicznie zbiera i naprawia backlog.
Redakcyjne tłumaczenie
Dlaczego warto zostać „AI builderem” i po co ten film
Zostanie osobą, która buduje z użyciem AI, to jedna z tych pokoleniowych szans — coś jak inwestowanie w Apple w latach 80. albo nauka internetu w latach 90. Problem w tym, że wielu ludzi, zwłaszcza tych bez doświadczenia programistycznego, nie ma żadnego systemu ani kontekstu, żeby budować rzeczy porządnie i w sposób uporządkowany. Jeśli należysz do osób, którym trudno przejść od świetnego pomysłu do czegoś, z czego naprawdę skorzystają inni ludzie, ten materiał jest dla ciebie. Pokażę pełny, pięcioetapowy proces prowadzący od pomysłu do w pełni zbadanej, wdrożonej i działającej aplikacji.
Plan jest następujący. Najpierw wyjaśnię problem, który rozwiążemy tą aplikacją — bo wszystkie dobre aplikacje zaczynają się od realnego problemu. Potem przełożymy surowy pomysł na funkcje, zbadamy dziedzinę, w której działamy, zaprojektujemy aplikację i pokroimy pracę tak, żeby dało się ją faktycznie zbudować, a na końcu wykonamy sam build. Na koniec będę miał działającą aplikację fitnessową, a ty — gotowy system pełen przydatnych trików, skilli i workflowów.
Problem: śledzenie treningów, którego nie ma żadna gotowa aplikacja
Zaczynamy od samego problemu, żeby wszystko było osadzone w konkretnym „dlaczego” i żebyśmy nie budowali czegoś, co już ma gotowe rozwiązania na rynku.
Osobiście korzystam z programu treningowego o nazwie Mountain Tough. Działa to tak, że od poniedziałku do piątku dostarczają zaprogramowane ćwiczenia w formie filmów „ćwicz razem ze mną”. Największy problem: nie ma żadnego systematycznego sposobu śledzenia postępów. Nie mają aplikacji. Dostajesz cały program, co jest świetne, ale żeby wiedzieć, jaki ciężar podniosłeś ostatnio, musisz w zasadzie komentować pod każdym filmem, ile powtórzeń zrobiłeś. A gdy w kolejnym tygodniu powtarzasz te ćwiczenia, przekopujesz się przez własne wątki komentarzy. To jedno z najgorszych możliwych doświadczeń użytkownika.
Sedno problemu, dla którego budujemy tę aplikację, jest takie: ich programowanie różni się istotnie z tygodnia na tydzień. Stosują dość nietypowe, niekoniecznie znormalizowane schematy powtórzeń i sposób budowania bloków. Nie ma na rynku aplikacji przygotowanych pod ten konkretny sposób programowania treningów.
Rozwiązanie, które chcę zbudować, to aplikacja, do której mogę wgrać PDF. Co tydzień dostajesz plik PDF ze wszystkimi ćwiczeniami. Chcę móc go wczytać, żeby coś — może model językowy, może coś innego — sparsowało go i zbudowało z niego rzeczywisty, trackowalny plan treningowy. Ogólny system: pobieram tygodniowy PDF, wgrywam go do aplikacji, ona go parsuje i zamienia w prawdziwy tracker treningów.
Od surowych notatek do funkcji
Zaczynamy od wypisania wszystkiego, co naszym zdaniem dotyczy tego, jak aplikacja ma działać. Na tym etapie nie rozmawiamy o konkretnych funkcjach, tylko o tym, co funkcjonalnie musi się w systemie dziać.
W naszym przypadku: użytkownik musi móc wgrać PDF, przy założeniu, że jeden plik to jeden tydzień treningów. Aplikacja parsuje i rozumie strukturę tych treningów — a to ważne, bo ona naprawdę się różni. Myśląc o tym „pod maską”, dochodzę do wniosku, że nieuchronnie będziemy potrzebować jakiegoś generatywnego UI, w którym model potrafi renderować treningi niepasujące do typowego standardu — w locie. Docelowo można by wgrać dowolny rodzaj programowania treningowego, a system zbudowałby dla niego tracker na bieżąco. Do tego zmierzamy. Ale najpierw zbuduję wąski klin (wedge) pod mój konkretny przypadek, żeby to zwalidować, a potem zacznę abstrahować i uogólniać.
(Informacja dodatkowa: „wedge” to w żargonie produktowym najwęższy możliwy pierwszy przypadek użycia, od którego zaczyna się budowę, żeby szybko zweryfikować pomysł przed rozszerzaniem go na inne scenariusze.)
System ma złożyć to, co sparsował, w tydzień treningów — bo tak właśnie dostarcza je ten konkretny program. W dniu treningowym otwieram aplikację, mam w niej wszystkie bloki, właściwą strukturę, warianty, ciężary — wszystko. Śledzę na bieżąco powtórzenia i serie. I wreszcie: mogę wrócić i przejrzeć wpisy z poprzednich tygodni.
Jednej rzeczy prawie na pewno będę w pewnym momencie chciał: system musi umieć uzgadniać ćwiczenia, żebym mógł śledzić wyniki danego ćwiczenia w czasie. Podczas parsowania będziemy więc potrzebować mechanizmu, który powie: „ten martwy ciąg ze sztangą, który właśnie parsuję, ma dopasowanie w bazie danych”. Pod maską pojawia się więc sporo logiki. Właśnie dlatego staram się to maksymalnie uprościć — wydaje się, że to banał do zbudowania w kilka sekund, ale realnie potrzeba tu dużo logiki. Nie chcę porywać się na zbyt wiele, skoro chcę mieć to gotowe w mniej więcej jeden dzień.
Etap 1: lekki PRD, który cię przepytuje
Biorę wszystkie te notatki i przechodzę do pierwszego kroku procesu — zamiany tego w coś, co nazywam „lekkim PRD”. Kopiuję notatki, schodzę do terminala i uruchamiam Claude’a (choć ten proces zastosujesz w dowolnym narzędziu). Mam własny skill o nazwie light prd — kopię znajdziesz w opisie pod filmem.
(Informacja dodatkowa: PRD to Product Requirements Document — dokument wymagań produktowych opisujący, co i po co budujemy.)
Ten skill robi dwie rzeczy. Po pierwsze, osadza się w rzeczywistym problemie i generuje bardzo lekki PRD. Po drugie — i to widać teraz — zaczyna zadawać pytania. Jeśli chcesz budować rzeczy, które faktycznie działają, kluczowe jest spędzenie dużej ilości czasu w fazie planowania: intencja funkcji i kryteria akceptacji muszą być bardzo precyzyjnie zdefiniowane, zanim cokolwiek zaczniesz budować.
Przekładamy surowy pomysł na strukturę, która później się przyda, gdy zaczniemy budować konkretne specyfikacje i robić projekty w narzędziach takich jak Claude Design. Skill pyta: kto jest głównym użytkownikiem aplikacji, czyje treningi są w tych PDF-ach? To sportowcy z nurtu functional fitness — nie kulturyści, nie trójboiści. Bardzo konkretny styl treningu. Skill jest konfigurowalny, można kazać mu drążyć głębiej. Pyta o odbiorcę, główny ból, o to, gdzie to zbudujemy. W tym przypadku robię aplikację mobilną, bo zwykle używam tego w garażu.
Skill jest tak zaprojektowany, że jeśli twoja odpowiedź rodzi nowe pytanie, on będzie schodził w dół drzewa decyzyjnego, aż rozwiąże wszystkie kluczowe niejasności. Kolejne pytania: jaki format musimy obsłużyć, jak ma działać parsowanie? Optymalizuję pod mój własny format PDF — na razie pod wedge, pod MVP. Co, jeśli parsowanie się nie uda? Początkowo chciałem połączyć autozapis z możliwością późniejszej edycji plus wskazywanie bloków, na które trzeba zwrócić uwagę — ale uznaję, że nie chcę wchodzić w logikę pewności (confidence), więc zostawiam sam autozapis i edycję później, żeby trzymać to ciasno zdefiniowane.
Ważna rzecz: wszystkie te odpowiedzi są zapisywane w projekcie, więc mamy dziennik wszystkiego, co ustaliliśmy. To bardzo cenne, gdy wracasz do pracy po godzinach i chcesz mieć pewność, że funkcja uwzględnia wcześniejsze decyzje. Gdy model „nie zawsze słucha”, ogromnie pomaga wskazanie mu tego dziennika już podjętych decyzji.
Gdyby wrzucić to pierwotne zapytanie od razu do narzędzia takiego jak Replit czy nawet Claude Code, ono po prostu podejmowałoby te decyzje za nas — i niekoniecznie zgodnie z tym, co byśmy chcieli. Dlatego lubię systemy, które cię odpytują i przyciskają w sprawie szczegółów, zanim ruszymy dalej.
Trzymam MVP bardzo ciasno. Edycja wcześniejszych wpisów byłaby fajna w przyszłości, ale to nowe powierzchnie, które trzeba zbudować i przetestować. Robienie ich na razie tylko do odczytu jest w kontekście MVP w porządku, bo używam tego dla siebie. Myślę, że taki system dałoby się kiedyś zmonetyzować, ale to nie jest teraz priorytet. Skoro to dla mnie — żadnych kont, wszystko lokalnie. Jedyne, co trzeba przemyśleć: potrzebny będzie model językowy do parsowania. Ale parsowanie danych nieustrukturyzowanych czy półustrukturyzowanych to coś, w czym model językowy jest naprawdę dobry — dlatego chcę go tu użyć.
Wybieram też dostawcę chmury dla modelu, który gdzieś będzie to parsował. Prawdopodobnie użyję czegoś jak OpenAI, bo mam tam mnóstwo kredytów. Gdybyśmy optymalizowali koszt, moglibyśmy sięgnąć po tańsze modele open source, równie skuteczne, bo zadanie jest dość proste: parsujemy PDF i formatujemy go do z grubsza znanego schematu.
Konsekwentnie wybieram lżejszą z opcji, gdziekolwiek się da. Bo te rzeczy rosną i szaleją bardzo szybko, jeśli za każdym razem wybierasz opcję bardziej agresywną. Mogłem wybrać pełny edytor bloków na wypadek nieudanego parsowania — ale takie „proste” rzeczy rosną i rosną, aż nagle masz coś, co nie jest już MVP i jest koszmarem do wdrożenia. Tego unikamy, będąc tak prostym, jak się da.
W tym przypadku przeszliśmy przez 15 pytań, ale skill jest konfigurowalny — flagą deep można pójść dalej, chyba nawet do 50 pytań. Jest open source, więc możesz to dostroić dowolnie. Na koniec skill tworzy PRD, który poniesiemy do kolejnego etapu — fazy research. To ważne, bo dużo się tu dzieje zarówno po stronie technicznej, jak i w specyfice dziedziny, i musimy przemyśleć, jak to się zejdzie.
Dostajemy dwa wyjścia: lekki PRD (który poniesiemy do researchu i do fazy projektowej w Claude Design) oraz zapis wszystkich pytań i naszych odpowiedzi. W samym PRD mamy elevator pitch i opis rozwiązywanego problemu. Taki kontekst motywacyjny jest cenny dla modeli językowych — gdy model musi sam rozstrzygnąć jakąś niejasność, znajomość motywacji za tym, co buduje, daje lepszy wynik. Dalej mamy listę funkcji: upload i parsowanie PDF, podgląd struktury tygodniowej i dziennej, śledzenie każdego dnia, przeglądanie historii, edycje, kwestie UX/UI oraz wymagania niefunkcjonalne — np. że to local-first i musi być bardzo szybkie, bo używa się tego w ruchu na siłowni.
Etap 2: deep research z adwersaryjną weryfikacją
Kolejny etap to research. W każdej sytuacji, gdzie są „nieznane niewiadome” albo „znane niewiadome”, trzeba wyjść i to zbadać. Nie mam gdzieś biblioteki każdego możliwego stylu programowania treningów functional fitness, a muszę to uwzględnić, budując parser.
Używam Claude Code, który ma wbudowany workflow deep research. Uwaga: to potrafi zjeść mnóstwo tokenów. Prosimy go: „muszę zrozumieć pełny zakres przestrzeni problemu dla tej aplikacji” — w dwóch obszarach. Pierwszy to techniczna implementacja parsera i modelu językowego oraz jego połączenie z generowaniem UI w locie; szukamy najlepszych praktyk. Często podaję miesiąc i rok wykonywania pracy, żeby dostać najświeższą wersję tych praktyk. Drugi obszar: na podstawie dwóch przykładowych PDF-ów z programu chcę zbadać prawdopodobny schemat danych — jaki będzie model danych przy tym stylu programowania, jak zaplanować bazę i jak to spiąć z parsowaniem i generowaniem potrzebnego UI.
System najpierw czyta PDF-y, potem uruchamia workflow deep research. Najpierw doprecyzowuje zakres wyszukiwań, następnie odpala wiele wyszukiwań i pobiera źródła — widać co najmniej 22 różne wyszukiwania w obu domenach. Potem uruchamia adwersaryjną weryfikację. To właśnie bardzo lubię w tym stylu pracy: jeśli w którymś pobraniu pojawi się rzekomy fakt, system nie przyjmuje go bezkrytycznie — odpala weryfikację, żeby nie brać na wiarę jakiegoś losowego wpisu na blogu i nie wbudować go w aplikację tylko po to, by później odkryć, że był błędny.
Można nałożyć ograniczniki: maksymalny budżet tokenów, limit liczby agentów, wskazanie modeli dla poszczególnych kroków.
Gdy research się skończył, uruchamiamy follow-up. Mieliśmy dwa pytania badawcze. Pierwsze — dziedzina, czyli functional fitness i to, jak zwykle wygląda takie programowanie; dostaliśmy dobre wnioski o strukturze tych dokumentów i o tym, jak to zabstrahować, by pasowało niemal do wszystkiego. Drugie — strona techniczna: kluczowe kwestie przy parsowaniu PDF. To była wartościowa faza, bo wiele twierdzeń znalezionych w blogach zostało w trakcie obalonych — i właśnie dlatego nie można polegać na samym web searchu, i dlatego dobrze mieć adwersaryjne review.
Z researchu wynikają nowe decyzje, które trzeba wprowadzić do PRD, zanim ruszymy dalej. Zakres V1: na start konkretny program, ale nie chcę, żeby zablokował się na tym jednym cyklu (nazwali go Apex 2.0) — ma działać w każdym kontekście, mam PDF-y z innych miesięcy. Research wyłapał też, że w tych PDF-ach są poziomy: ekspercki, średnio zaawansowany i początkujący — czego pierwotny PRD nie uwzględniał. Wybrałem opcję: pokaż mi te poziomy, ale bez logiki autouzupełniania, bo nie chcę się z tym mierzyć.
Etap 3: od PRD do UX i projektu w Claude Design
Kolejny etap to przygotowanie do projektowania. W idealnym świecie projekt produktu i research techniczny dzieją się równolegle w komunikujących się zespołach. U nas robi to jedna osoba, więc traktujemy to jak proces równoległy. Mam skill o nazwie PRD2UX na moim darmowym repo GitHub — to lżejsza wersja tego, co mam w płatnej społeczności. Bierze PRD i rozkłada go na coś, co da się podać narzędziu generatywnemu do projektowania: Claude Design, Google Stitch itp. Robi to wieloetapowo.
Zanim ruszymy do Claude Design, chcemy rozumieć ogólne podejście UX. Im bardziej szczegółowy PRD, tym mniej pracy tutaj. W tym przypadku PRD był dość szczegółowy, więc wiele decyzji UX już zapadło — dominujący model mentalny użytkownika, architektura informacji, sposób grupowania i prezentacji, jak wygląda biblioteka, jak startuje się ćwiczenia, jak działa nawigacja po historii, jakie są afordancje (skąd użytkownik wie, że coś jest interaktywne). Bardzo lubię robić planowanie UX z góry, bo zmusza to do przemyślenia, co sprawi, że ktoś naprawdę zechce tego używać. To lżejsza wersja, która sporo decyduje za nas na bazie wcześniejszego kontekstu — w idealnym świecie to iteracyjna wymiana tam i z powrotem.
(Informacja dodatkowa: afordancje to wizualne sygnały mówiące użytkownikowi, że dany element da się kliknąć, przesunąć czy edytować.)
Przechodzimy przez główne komponenty/ekrany i projektujemy wszystkie stany: pusty, ładowania, sukcesu, danych częściowych, błędu — dla biblioteki, dla pojedynczego tygodnia i dnia. Rozpisujemy to z góry, żeby model nie podejmował decyzji „w biegu”. Ostatni krok przed Claude Design to rozbicie tego na konkretne ekrany, tak by móc kopiować prompty z VS Code do Claude Design.
W Claude Design wybrałem szablon aplikacji mobilnej i użyłem systemu projektowego z innego projektu, bo dobrze pasuje. Daję dwa rodzaje kontekstu: kontekst aplikacji (co budujemy) oraz — ekran po ekranie — poszczególne widoki. Częstym błędem jest podanie od razu wszystkich ekranów naraz; ja daję tylko pierwszy. Projektujemy główną bibliotekę: co widzi ktoś, kto otwiera aplikację, mając już plan — to byłby np. tydzień piąty, w który można wejść, zobaczyć poszczególne dni, wejść w dzień i zacząć trening.
Na wyjściu mamy bardzo prosty projekt — i o to chodziło. Nie przeprowadzaliśmy rozbudowanego brainstormingu UX. Możesz i powinieneś to zrobić, jeśli naprawdę ci zależy i chcesz, żeby produkt był innowacyjny — ale tu robię narzędzie użytkowe dla siebie. Ekran niemal dokładnie odpowiada naszemu szkicowi. Kolejny to upload i parsowanie — wklejamy szczegóły i prosimy o nowy ekran. Powtarzamy proces dla każdego elementu z listy, wklejając nasze niskiej wierności szkice (a czasem tylko koncepcje funkcji).
Po przejściu wszystkich ekranów mamy funkcjonalny prototyp. Dodatkowo poprosiłem, żeby zamienił to w interaktywny prototyp, więc mogę zobaczyć np. fazę uploadu czy wejście w konkretny tydzień. Wszystko, co planowaliśmy, jest tu i w większości działa.
Etap 4: od PRD i projektów do epików w narzędziu spec-driven
Teraz zamieniamy projekty w coś, z czym da się pracować. Wybieram opcję wysłania tego do Claude Code i pobrania jako ZIP — plik zawiera wszystko, czego projekt potrzebuje. Kopiuję go do katalogu głównego w VS Code i wrzucam do docs.
Mam skill PRD-to-epics (również w repo). Wskazuję mu folder docs, w którym jest teraz PRD z całym kontekstem oraz same projekty. Skill tworzy pionowo pokrojone epiki (vertically sliced). Do samego budowania używam narzędzi spec-driven, takich jak OpenSpec.
(Informacja dodatkowa: „pionowo pokrojony epik” obejmuje pełen przekrój funkcji — od interfejsu przez logikę po dane — zamiast poziomej warstwy; dzięki temu każdy epik można dowieźć jako działający fragment. Narzędzia spec-driven prowadzą pracę wg jawnych specyfikacji, trzymając model „na szynach” i budując dokumentację.)
Uważam, że narzędzi spec-driven powinni używać wszyscy — szczególnie początkujący, ale też doświadczeni, bo trzymają wszystko na szynach i dokumentują. Łączymy więc funkcje, szczegóły z researchu i projekty, a wynikiem jest zestaw epików do zbudowania. Zorientowałem się, że do tego kroku używam akurat Fable 5 — więc przynajmniej będzie dobrze zaplanowane. Podobnie jak wcześniej, przechodzimy przez sesję pytań i odpowiedzi, bo zaczynamy planować fazy developmentu i chcemy mieć stuprocentową zgodność co do tego, co dokładnie się wydarzy.
Po przejściu procesu mamy siedem epików. Będziemy je robić w OpenSpec. Kopiuję komendę inicjalizującą, inicjalizuję OpenSpec z Claude Code, otwieram Claude Code i przełączam się na Opus. Uruchamiam komendę proposal: OpenSpec generuje propozycję (intencję, „dlaczego”), projekt systemu, specyfikacje funkcji oraz listę zadań — dla każdego epika. Gdy jesteśmy zadowoleni, uruchamiamy apply i system faktycznie buduje. Do prowadzenia tego procesu można użyć różnych skilli — Ora superpowers, compound engineering, materiały Matta Pococka — ale najważniejsze, żeby robić to „na szynach”.
Jak działa OpenSpec: patrzymy na artefakty. Mamy zmianę (change) — np. „upload i logowanie tygodnia”. W jej ramach są trzy specyfikacje: parsowanie PDF (z wypisanymi wymaganiami), śledzenie pojedynczych dni oraz sama biblioteka. Dalej propozycja — „co” i „dlaczego” zmiany. Modele są dużo lepsze, gdy dostają intencję motywacyjną: gdy trafią na decyzję, której nie doprecyzowałeś, znajomość „dlaczego” pozwala im łatwiej wypełnić lukę. Potem projekt systemu — cele, podjęte decyzje — i wreszcie lista zadań rozbita tu na siedem faz. Gdy wszystkie fazy są gotowe, zdolność „upload i logowanie tygodnia” uznajemy za ukończoną (choć oczywiście trzeba ją jeszcze przetestować). Takich zmian mamy siedem.
To sytuacja, w której „loop engineering” bywa cenne: tworzymy pętle, które generują propozycję, wdrażają ją i przechodzą do generowania kolejnej. Kolejność ma znaczenie, bo te rzeczy zależą od tego, co zrobiono wcześniej — nie da się wszystkiego zrównoleglić, część musi iść sekwencyjnie.
Etap 5: autonomiczna implementacja z sub-agentami i weryfikacją
Wdrażamy, uruchamiając openspec apply i podając nazwę zmiany — tu „upload i logowanie tygodnia”. Teraz można wpleść skille. Możemy skopiować to do świeżej sesji z nowym oknem kontekstu i dodać instrukcje: „użyj sub-agenta”, wskazać np. Ora superpowers (sub-agent-driven development), powiedzieć „użyj sub-agentów do każdej fazy” — każda faza dostaje własnego sub-agenta do implementacji. Do tego jeden adwersaryjny sub-agent recenzujący po każdej fazie: po jej zakończeniu inny model szybko sprawdza, czy wszystko zrobiono porządnie. Puszczamy to.
Pierwszy spec działa: da się wgrać PDF-y, pokazują się dni, można wejść i wpisywać dane. Widać drobne błędy w zarządzaniu stanem, ale to nic wielkiego. Mamy blok rozgrzewkowy, potem np. banded fire hydrant — można wpisywać swoje dane. Część ćwiczeń powinna mieć ciężary, a ich nie ma. Ale zasadnicza część działa. To dopiero pierwszy spec z całej listy epików.
Ten parser i wszystko, co budowało się w tle, zajęło jakieś dwie–trzy godziny. Nie chcę tego niańczyć przez cały ten czas. To dość prosta, niskostawkowa i dobrze zdefiniowana rzecz — jest niewiele miejsc, gdzie może pójść nie tak — więc jestem gotów puścić to autonomicznie. Ten sam proces zastosowałbym przy czymś, na czym bardzo mi zależy; różnica polegałaby na tym, że dużo więcej czasu spędziłbym w fazie propozycji, dokładnie ją recenzując i uzgadniając intencję, zanim zautomatyzuję apply, weryfikację i finalizację.
Ten workflow automatyzuje zbudowanie całości. W docs mamy epiki 1–7. Na nowym uruchomieniu skill sprawdza, które zmiany są jeszcze niewdrożone, uruchamia dla danego epika fazę propozycji, potem implementację (implementer/sub-agent na fazę, adwersaryjne review), weryfikuje pracę i finalizuje ją (synchronizacja specyfikacji, archiwizacja), po czym przechodzi do kolejnego epika. Można wpiąć fazy testowe z dostępem do serwera MCP sterującego przeglądarką lub symulatorem iOS. Schodzę do projektu i po prostu mówię: „uruchom ten dynamiczny workflow dla implementacji epików”.
Tak, to zużyje więcej tokenów — ale dlaczego? Bo działa autonomicznie godzinami, ciągle, w tle. Widzimy: faza discover znajduje wszystkie niezaplanowane epiki, potem propozycja generuje pliki proposal.md, design.md, specyfikacje i zadania, implementacja, adwersaryjne review. Teoretycznie może działać przez całą noc.
Poranek później: 20 godzin, realne rezultaty i realne braki
Jest następny dzień. To działało 20 godzin w nocy. Trwało tak długo, bo przy pracy bez nadzoru wbudowuję poważne pętle weryfikacji. Nie pozwalam, żeby przeleciało przez całość bez testów i żebym rano obudził się z niczym niesprawdzonym. Proces weryfikuje, odpala adwersaryjne review, steruje symulatorem iOS, żeby sprawdzić pracę. Dlatego siedem epików — nie największa robota — zajęło tyle. Część czasu to było czekanie: nad ranem miał do mnie kilka pytań, na które musiałem odpowiedzieć. Realnie pracy było mniej niż 20 godzin, ale sporo czasu system stał, czekając na moje odpowiedzi.
Otwieramy symulator. Ekran startowy jest pusty — nie poświęciłem prawie żadnego czasu na UX i UI, bo to podstawowe narzędzie użytkowe dla mnie. Przy realnym produkcie spędzilibyśmy w fazie UX kilka godzin, jeśli nie dni. Wybieram jeden z wgranych PDF-ów. Ładowanie ma trzy różne wskaźniki — trochę redundantne; to typowy efekt pomijania części planowania. Parsowanie poszło szybko.
Wchodzimy w dni. Zgodnie z założeniem, jeśli system nie sparsował ćwiczeń danego dnia, prosi o potwierdzenie względem PDF. Rozgrzewka: mountain climber, renegade row, wykrok w tył z masą ciała, burpees — zgadza się. Blok pierwszy: hip airplane, dumbbell pec fly i wznos na palce. Braki widać: pec fly jest ćwiczeniem z obciążeniem, a nie mamy tu pola na ciężar. Nie będę udawał, że wszystko wyszło za pierwszym podejściem.
Trudność polega na tym, że model językowy parsuje PDF, a potem — na podstawie tego, co sparsował — generuje te tygodnie w locie, używając generatywnego UI: „oto rzeczy, które umiem stworzyć, i oto, co było w PDF, więc spróbuję to złożyć”. To nie jest superdeterministyczne. Możesz przepuścić ten sam PDF kilka razy i za każdym razem dostać inną odpowiedź. To jedna z fundamentalnych słabości używania agentów i modeli językowych do rzeczy, które mają być rdzenną logiką aplikacji.
To trzeba by dopracować w dialogu z systemem. Otwieramy PDF: blok pierwszy to 5-minutowy zegar, w którym robisz tyle rund, ile zdołasz. Dumbbell pec fly musi mieć ciężar, a my musimy móc podać, ile rund przeszliśmy i ile powtórzeń w każdej — czego w interfejsie brakuje. Blok drugi jest za to dopięty: pięć rund, w każdej podajemy ciężar i liczbę powtórzeń. Więc działa w części sytuacji, a w innych nie — z natury parsowania w locie.
Prosty sposób naprawy: każde ćwiczenie mogłoby dostać opcję dodania ciężaru i powtórzeń jako specyfikacji, więc w każdej takiej sytuacji dałoby się to szybko rozwiązać. Przeglądając dalej — dzień drugi, single arm dumbbell press — też chcielibyśmy móc wpisać ciężar. To w zasadzie jedyny większy brak, ale w skali całości drobny. Są też przypadki, gdzie ciężaru być nie powinno, np. rozciąganie „frog stretch” — to raczej na czas. Drobiazgi do dostrojenia, których należało się spodziewać, bo nie spędziliśmy dużo czasu w fazie speckowania. Nie można oczekiwać, że model wypełni luki rzeczami, o których mu nie powiedzieliśmy.
Zamknięcie: systematyczny obieg naprawy błędów
Na koniec — co robię z takimi błędami. Pokazuję inny projekt: natywnie AI-owy tracker odżywiania, który buduję. Gdy trafiam na błędy takie jak powyżej, zapisuję je jako issues w GitHubie i taguję jako bug. Raz albo kilka razy dziennie — zależnie od intensywności testów — uruchamiam workflow (taki jak wcześniejszy), który przechodzi przez backlog błędów: najpierw próbuje zrozumieć, dlaczego coś jest zepsute, potem robi poprawkę. Można go skonfigurować tak, by odezwał się do ciebie, gdy trzeba coś uzgodnić. Następnie wykonuje poprawkę, sam ją testuje, klika w symulatorze czy przeglądarce. To bardzo szybki sposób naprawiania, zamiast prowizorycznego, niesystematycznego śledzenia błędów.
To tyle. Jeśli chcesz pomocy z konfigurowaniem workflowów pod twój projekt, z właściwym definiowaniem i skalowaniem MVP, budowaniem produktów gotowych do wdrożenia i wprowadzaniem ich na rynek — sprawdź link w opisie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zaczynaj od realnego problemu, nie od pomysłu na aplikację
Na czym polega: Autor osadza cały projekt w konkretnym, dokuczliwym problemie (brak trackera dla nietypowo programowanych treningów z PDF-a), zanim napisze choć linijkę specyfikacji.
Jak stosować: Zanim zaczniesz cokolwiek budować, opisz problem i sprawdź, czy nie ma gotowych rozwiązań; jeśli są, znajdź to, co je dyskwalifikuje w twoim przypadku. To „dlaczego” stanie się kontekstem motywacyjnym dla modelu na dalszych etapach.
Na co uważać: Łatwo zbudować coś, co już istnieje. Jeśli nie potrafisz wskazać, czym twój przypadek różni się od gotowców, prawdopodobnie nie potrzebujesz nowej aplikacji.
2.Przełóż surowy pomysł na funkcje przez „lekki PRD”, który cię przepytuje
Na czym polega: Skill zamienia notatki w lekki PRD i drąży drzewo decyzyjne pytaniami, aż rozwiąże kluczowe niejasności — intencję i kryteria akceptacji definiujesz przed budową.
Jak stosować: Wrzuć surowe notatki do procesu, który wymusza odpowiedzi na pytania o odbiorcę, ból, platformę, formaty i obsługę błędów. Konfiguruj głębokość (tu 15 pytań, tryb deep do ~50).
Na co uważać: Bez tej fazy narzędzie (Replit, Claude Code) samo podejmie decyzje — niekoniecznie zgodne z twoimi. Ale nie wpadaj w drugą skrajność: nadmiar pytań przy prostym MVP to strata czasu.
3.Zapisuj dziennik decyzji i wskazuj go modelowi
Na czym polega: Wszystkie odpowiedzi z fazy planowania lądują w projekcie jako trwały log ustaleń.
Jak stosować: Gdy po godzinach model „nie słucha” wcześniejszych ustaleń, skieruj go wprost do dziennika decyzji — autor uznaje to za bardzo skuteczne.
Na co uważać: Log jest wart tyle, ile jego aktualność; po każdej istotnej zmianie zakresu wprowadzaj ją do dokumentu, inaczej model będzie działał na nieaktualnych założeniach.
4.Bezwzględnie trzymaj zakres MVP i wybieraj lżejszą opcję
Na czym polega: Na każdym rozgałęzieniu autor wybiera prostszy wariant (autozapis zamiast logiki pewności, tryb tylko do odczytu, brak kont, dane lokalne).
Jak stosować: Przy każdej decyzji pytaj, czy funkcja jest niezbędna dla wersji, której użyjesz jutro. „Proste” dodatki (np. pełny edytor bloków) mają tendencję do niekontrolowanego rozrostu.
Na co uważać: Kolejne „drobne” rozszerzenia sumują się w coś, co przestaje być MVP i staje się koszmarem wdrożeniowym. Nowe powierzchnie to nowe testy i nowe utrzymanie.
5.Rób deep research z adwersaryjną weryfikacją faktów
Na czym polega: Wbudowany workflow deep research w Claude Code skanuje domenę i stronę techniczną, pobiera źródła, a potem adwersaryjnie weryfikuje rzekome fakty — część twierdzeń z blogów zostaje obalona.
Jak stosować: Uruchamiaj research tam, gdzie masz „nieznane niewiadome”. Podawaj miesiąc i rok, by dostać aktualne praktyki, i karm go realnymi przykładami (tu: dwa PDF-y) do wnioskowania o schemacie danych.
Na co uważać: To bardzo drogie w tokenach. Nakładaj ograniczniki: budżet tokenów, limit agentów, wskazanie modeli per krok. Nie ufaj samemu web searchowi bez weryfikacji.
6.Planuj UX i stany ekranów z góry, zanim odpalisz generator projektów
Na czym polega: Skill PRD2UX ustala podejście UX (model mentalny, architekturę informacji, afordancje) i rozpisuje stany każdego ekranu: pusty, ładowania, sukcesu, częściowy, błędu.
Jak stosować: Rozbij projekt na konkretne ekrany i podawaj je do narzędzia (Claude Design, Google Stitch) pojedynczo, wraz z systemem projektowym. Nie wrzucaj wszystkich ekranów naraz.
Na co uważać: Pominięcie planowania UX daje efekty widoczne później — np. trzy redundantne wskaźniki ładowania. Im lepszy PRD, tym mniej pracy tutaj, ale nie licz, że model sam „domyśli” stany brzegowe.
7.Krój pracę na pionowe epiki i prowadź build narzędziem spec-driven
Na czym polega: Skill zamienia PRD i projekty w pionowo pokrojone epiki, a build prowadzony jest w OpenSpec, który generuje propozycję, projekt systemu, specyfikacje i listę zadań.
Jak stosować: Używaj narzędzi spec-driven niezależnie od poziomu zaawansowania — trzymają pracę „na szynach” i budują dokumentację. Zatwierdzaj propozycje przed uruchomieniem apply.
Na co uważać: Epiki bywają zależne sekwencyjnie — nie wszystko da się zrównoleglić. Przy projektach, na których ci zależy, najwięcej czasu poświęć fazie propozycji, a nie automatyzacji.
8.Zawsze podawaj modelowi intencję motywacyjną („dlaczego”)
Na czym polega: Zarówno PRD, jak i propozycje OpenSpec zawierają „co” i „dlaczego”. Gdy model trafia na niedoprecyzowaną decyzję, znajomość rationale pozwala mu lepiej wypełnić lukę.
Jak stosować: W każdym dokumencie (PRD, proposal, design) jawnie zapisuj cel i uzasadnienie funkcji, nie tylko listę wymagań.
Na co uważać: Intencja nie zastąpi specyfikacji stanów brzegowych. Model wypełni luki „w duchu” celu, ale nie zgadnie rzeczy, o których w ogóle mu nie powiedziano (tu: pola na ciężar).
9.Autonomiczny build wymaga wbudowanych pętli weryfikacji
Na czym polega: Dynamiczny workflow działał 20 godzin w nocy, bo autor wpiął weryfikację, adwersaryjne review i sterowanie symulatorem iOS — sub-agent na fazę plus recenzent po każdej fazie.
Jak stosować: Jeśli puszczasz build bez nadzoru, wbuduj testy i review, a nie tylko implementację; inaczej rano obudzisz się z niesprawdzonym kodem. Do testów wepnij MCP sterujący przeglądarką lub symulatorem.
Na co uważać: To zużywa dużo tokenów i czasu — częściowo dlatego, że proces stoi, czekając na twoje odpowiedzi na pytania. Więcej tokenów to cena za godziny autonomicznej pracy w tle, nie marnotrawstwo.
10.Rozumiej granice generatywnego UI i systematyzuj naprawę błędów
Na czym polega: Parsowanie i składanie ekranów w locie przez model jest niedeterministyczne — ten sam PDF daje różne wyniki, a część ćwiczeń zgubiła pola na ciężar. Autor zgłasza takie błędy jako issues w GitHubie (tag bug) i cyklicznie odpala workflow, który je naprawia i testuje.
Jak stosować: Nie opieraj rdzennej, deterministycznej logiki aplikacji wyłącznie na modelu językowym. Błędy loguj systematycznie i przepuszczaj przez powtarzalny workflow naprawczy zamiast łatać je ad hoc.
Na co uważać: Generatywne UI świetnie radzi sobie z nieustrukturyzowanymi danymi, ale zawodzi tam, gdzie potrzebna jest powtarzalność. Braki są do przewidzenia proporcjonalnie do czasu pominiętego w fazie speckowania — nie oczekuj jakości „za darmo”.