O czym jest ten film
- Wielu ludzi pracujących z AI wpada w pułapkę pisania coraz dokładniejszych specyfikacji zamiast po prostu napisać kod.
- Spadek kosztu wytworzenia kodu sprawił, że prototypowanie i „spike’i” nigdy nie były tańsze ani skuteczniejsze.
- Kluczowe pojęcie: fidelity — niska wierność (rozmowa) wystarcza do prostych pytań, wysoka (działający kod) do pytań o wygląd i zachowanie.
- Autor prezentuje swój skill
prototype— jednorazowy kod, który odpowiada na konkretne pytanie projektowe. - Prototyp jest częścią większego skilla Wayfinder, który dzieli dużą pracę na sesje planistyczne z ticketami typu „grilling” i „prototype”.
- Demo: rozbudowa aplikacji do diagramów (na TLDraw) o pasek wyszukiwania — agent generuje kilka wariantów (A, B, C, D) do porównania.
- Iteracyjne dawanie feedbacku na żywym interfejsie prowadzi do wersji D, łączącej najlepsze elementy poprzednich.
- Prototyp zapisuje się na gałęzi jednorazowej — implementer dostaje nie tylko specyfikację, ale też realny kod frontendu do skopiowania.
- Prototypowanie działa nie tylko dla UI — dla backendu można zbudować interaktywną aplikację terminalową testującą maszynę stanów.
- Główna teza: skok od dyskusji i specyfikacji do kodu produkcyjnego jest ogromny; skok od działającego prototypu do produkcji — prosty.
Redakcyjne tłumaczenie
Obsesja na punkcie specyfikacji
Jest coś, co robi wielu ludzi pracujących z AI nad kodem i co doprowadza mnie do szału. Wybrzydzam na to już od dłuższego czasu. Zauważyłem, że ludzie zaczynają myśleć w kategoriach: „muszę stworzyć specyfikację dla AI, muszę napisać plan”. Tryb planowania, rozwój sterowany specyfikacją. Wkładają cały wysiłek w to, żeby przygotować niezwykle szczegółową specyfikację — po to, by wynik działania AI dokładnie ją odzwierciedlał. Chcą wszystko określić z góry, żeby trafić w dziesiątkę za pierwszym razem.
W tym odruchu zapominają o jednej rzeczy: że mogą po prostu napisać kod. Możesz pisać kod, jednocześnie zmierzając w stronę specyfikacji. Prototypowanie i spike’i istnieją od czasów zwinnego wytwarzania oprogramowania.
(Informacja dodatkowa: „spike” w metodykach zwinnych to krótkie, eksperymentalne zadanie mające zredukować niepewność techniczną — zwykle jednorazowy, badawczy kawałek kodu, a nie część docelowego produktu).
I nadal są to czasy Agile’a — ta metodyka wciąż jest bardzo popularna i wpływowa. Tylko ludzie po prostu przestali prototypować. W ramach mojego repozytorium ze skillami próbuję to odwrócić. Mam skill prototype. Prototyp to jednorazowy kod, który odpowiada na jakieś pytanie.
Kod jest tani — a przynajmniej jego wytworzenie
Wszyscy powtarzają, że „kod jest tani”. To po części prawda, a po części nienawidzę tego sformułowania. To, co faktycznie stało się tanie, to koszt wytworzenia kodu — spadł ogromnie. Dlatego produkowanie prototypów, szybkich jednorazowych spike’ów, nigdy nie było tańsze ani nie było skuteczniejszym narzędziem.
W tym filmie przedstawię skill prototype: kiedy go używać, do czego się nadaje i jak wpasowuje się w mój nowy skill Wayfinder.
Pojęcie wierności (fidelity)
Najpierw wyjaśnię koncepcję wysokiej i niskiej wierności. Kiedy cokolwiek projektujesz, masz w głowie pytania, które trzeba jakoś rozstrzygnąć. Niektóre są bardzo podstawowe — dotyczą samego szkieletu tego, co budujesz. „Gdy modal się otwiera, powinien mieć przycisk anulowania i przycisk potwierdzenia”. Proste sprawy. Przy takich rzeczach nie potrzebujesz wysokiej wierności, żeby znaleźć odpowiedź — wystarczy rozmowa.
Ale załóżmy, że ten modal w pewnych okolicznościach musi wyświetlić jakieś dane. Tu trzeba wejść nieco wyżej z wiernością. Jak wyświetlić te dane? Podczas planowania specyfikacji często trudno rozstrzygnąć, jak dokładnie coś ma wyglądać i jak ma się zachowywać w określonych warunkach. Upewnienie się, że przetestowałeś cały pomysł na wpół działającym kodzie, wymaga wyższej wierności. Na niektóre pytania da się odpowiedzieć tylko przez prototypowanie.
Ponieważ produkcja prototypów jest teraz tańsza niż kiedykolwiek, wolę prowadzić coraz więcej moich dyskusji na wyższym poziomie wierności. Rzeczy oczywiste rozstrzygam oczywiście w rozmowie. Agent zadaje mi pytania — zwykle w sesji przesłuchania (grilling) — a ja mówię: „OK, brzmi dobrze”. Ale gdy tylko pojawia się coś, o czym myślę „naprawdę muszę to zobaczyć w działaniu, poczuć w działaniu, popatrzeć, jak to działa” — proszę o prototyp.
Miejsce prototypu w Wayfinderze
Prototypowanie jest częścią mojego nowego skilla Wayfinder, który pozwala zaplanować ogromny kawał pracy. O samym Wayfinderze będzie osobny film. Wayfinder bierze duży fragment pracy i dzieli go na osobne sesje planistyczne. Każda taka sesja dostaje własny ticket, a gdzieś tutaj są typy ticketów, które mówią mu dokładnie, jakie typy istnieją.
Interesują nas dwa: typ „grilling”, czyli przesłuchanie z użyciem odpowiednich skillów, oraz typ „prototype”. Domyślny jest typ „grilling” — czatujesz z agentem, ustalając podstawowy zakres tego, co budujesz. Ale gdy trzeba podnieść wierność dyskusji, tworzysz tani, surowy, konkretny artefakt, na który możesz zareagować — zarys, szkic logiki interfejsu poprzez skill prototype. Prototyp linkuje się jako zasób. Używasz go wtedy, gdy kluczowym pytaniem jest „jak to ma wyglądać” albo „jak to ma się zachowywać”. Niezależnie od tego, czy korzystasz z Wayfindera, daje ci to jasne kryterium, kiedy sięgnąć po prototyp.
Demo: pasek wyszukiwania w aplikacji do diagramów
Pewnie nie możesz się doczekać, żeby zobaczyć to w akcji — oto ono. Używałem Wayfindera do rozbudowy mojej aplikacji do diagramów, zbudowanej na TLDraw.
(Informacja dodatkowa: TLDraw to otwartoźródłowa biblioteka do budowy interaktywnych aplikacji typu nieskończone płótno / tablica).
Chciałem móc przeszukiwać stare diagramy, a model danych jest tu dość skomplikowany — są diagramy i migawki (snapshoty) diagramu w czasie. Chciałem zbudować pasek wyszukiwania, ale nie byłem pewien, jak powinien wyglądać ani działać. Uruchomiłem więc prototype. Stworzył on mały przełącznik na dole z trzema wariantami. Przełączając się między nimi, dostaję opcję A, B i C, a każda z nich koduje kilka decyzji projektowych, na które mogę zareagować i je dopracować.
Zacznijmy od A — dopiero co ją wygenerowałem, jeszcze na nią nie patrzyłem. Mogę przeszukać diagramy i zobaczyć wyniki. To wariant z przepływem w miejscu i pogrupowanymi wierszami — grupuje migawki według nazwy diagramu. Bardzo podoba mi się umieszczenie pola wyszukiwania u góry, ale to grupowanie mi nie leży.
Zobaczmy B. Szukam znowu, tym razem „model”, i teraz po lewej mamy grupowanie do zawężania wyników. Całkiem miłe. A co, jeśli poszukam czegoś innego — filtr się resetuje. To w porządku, ale ciekaw jestem C.
Bardzo nie podoba mi się ten napis „search diagrams” u góry, nie wygląda ładnie, ale zobaczmy. Szukam „model” i — o, teraz wszystko jest w jednej linii, bez filtrów. To akurat naprawdę mi się podoba, choć jest kilka rzeczy, których nie lubię. Nie podoba mi się oznaczanie „current” — wygląda to na jakiś techniczny dziwoląg, ale bieżący element pokazuje się z migawką diagramu. Mam więc feedback do przekazania prototypowi.
Kompaktowanie i iterowanie
Ta sesja prototypowania zużyła około 100 tysięcy tokenów. Zamierzam wykonać kompaktowanie i powiedzieć: „zrobimy jeszcze trochę QA na tym”.
(Informacja dodatkowa: „kompaktowanie” to skrócenie/streszczenie kontekstu rozmowy z agentem, żeby zwolnić miejsce, zachowując najważniejsze informacje).
Kompaktowanie ma tu sens, bo musimy zachować wszystkie informacje o prototypie i wszystkie decyzje projektowe, które w niego weszły — chcemy tylko przekazać feedback i kontynuować rozmowę w tym samym miejscu w kodzie. Powinienem kiedyś zrobić osobny film o tym, jak decyduję między kompaktowaniem, czyszczeniem kontekstu a przekazaniem (handoff), ale to temat na inną okazję.
Teraz daję feedback: „Naprawdę podoba mi się pole wyszukiwania z A i podoba mi się układ z C”. Podyktowałem trochę więcej uwag i wysyłam. Chodzi o to, że iteruję na tym prototypie — nie mówię po prostu „ta jest najlepsza”. Tworzę konkretne decyzje projektowe, buduję bogaty zasób. Wszystkie te decyzje zostaną zakodowane w prototypie, a prototyp zapiszę zapewne na gałęzi jednorazowej. Dzięki temu, gdy przyjdzie do właściwej implementacji, agent ma nie tylko specyfikację — ma prawdziwy kod frontendu, który zwykle może po prostu skopiować i wkleić.
Koszt wyższej wierności
Tworzenie tych prototypów trochę kosztuje. Im wyższa wierność, tym większy koszt w tokenach. Gdybyśmy próbowali rozstrzygnąć to w rozmowie, bylibyśmy na niższej wierności — odpowiedzi byłyby mniej użyteczne, ale zapłacilibyśmy mniej tokenów.
Widać, że zaczyna teraz dawać mi wersję D, czyli mniej więcej to, ku czemu iterowałem. Jedna uwaga: to jest zintegrowane z żywą stroną. Nie robi tego na jednorazowej, oddzielnej trasie. Możesz tak zrobić, jeśli chcesz, ale ja wolę widzieć prototyp podpięty do realnej trasy — daje to znacznie więcej elastyczności i jest bardziej uczciwym odwzorowaniem tego, jak kod będzie naprawdę działał.
Wygląda na to, że utworzył D. Mamy pole z A, a gdy wyszukam „model”, widać, że wszystko, o co prosiłem, faktycznie zostało zrobione. Wcześniej był duplikat tego elementu, teraz jest tylko jeden. I teoretycznie, gdy w to kliknę — nie jestem pewien, czy zadziała, nie wiem, czy to część prototypu — tak, działa. Pięknie. Mnóstwo tej funkcjonalności jest już po prostu gotowe.
Co dalej po prototypie
Możesz zapytać, jaki jest następny krok. Teraz uznaję prototyp za ukończony. Ten poszedł dość szybko — zwykle robię tu znacznie więcej. Przekazałbym to agentowi działającemu w tle (AFK), żeby podpiął wszystko, usunął stary kod prototypu i upewnił się, że całość jest zgodna z pierwotną specyfikacją.
(Informacja dodatkowa: AFK — „away from keyboard” — agent pracujący autonomicznie, bez nadzoru użytkownika przy klawiaturze).
Rezultaty są rewelacyjne, bo mieliśmy dyskusję o tak wysokiej wierności — mogliśmy popatrzeć na żywą, działającą wersję i dać feedback oparty na tym, co widzieliśmy. Ten feedback jest bezcenny i jest już wpieczony w gałąź jednorazową, do której implementer może się po prostu odwołać.
Tak często widzę ludzi mówiących: „przecież to nie zbudowało tego, co chciałem. Stworzyłem wielką, piękną specyfikację, a wyszło coś zupełnie dziwnego”. Prawdopodobnie po prostu nie prowadziłeś dyskusji na wystarczająco wysokiej wierności i prawdopodobnie powinieneś był prototypować.
To nie tylko dla frontendu
Nie chcę, żebyś odszedł z przekonaniem, że to tylko dla UI czy frontendu. Frontend rzeczywiście dużo zyskuje na prototypach, bo „jak to ma wyglądać” to kluczowe pytanie, na które naprawdę trudno odpowiedzieć podczas dyskusji. Jednak przy bardziej skomplikowanych rzeczach, zwłaszcza pracy backendowej, pojawiają się pytania w rodzaju: „czy ta logika, ten model stanu, czuje się dobrze?”. Jeśli budujesz coś rozsądnie złożonego albo coś, co musi działać w prawdziwym świecie, będziesz napotykać takie pytania bez przerwy.
Często najlepszym sposobem na rozwiązanie tego rodzaju pytań — na zbudowanie czegoś, co faktycznie służy potrzebom użytkowników, zwłaszcza przy czymś złożonym — jest zbudowanie prototypu. I nie musi to być prototyp UI. Mam tu polecenie: „zbuduj maleńką interaktywną aplikację terminalową, która przepycha maszynę stanów przez przypadki trudne do przemyślenia na papierze”. Innymi słowy — czysto logiczny prototyp. Dostałem mnóstwo feedbacku od ludzi, że to bardzo fajna funkcja. Obie te ścieżki mają własne dokumenty referencyjne, które dokładnie mówią, jak zrobić każdą z nich. Jeśli buduje prototyp logiczny, zagląda tutaj; jeśli prototyp UI — tam.
Główny wniosek
Błagam cię więc: prowadź swoje dyskusje na wyższej wierności. W miarę jak agenci będą coraz lepsi w pracy z płótnami i narzędziami projektowymi, jestem pewien, że wrócą też szkice interfejsu (wireframe’y). Kluczowa myśl jest taka: skok od dyskusji i specyfikacji do kodu gotowego na produkcję jest naprawdę ogromny. Natomiast jeśli masz działający prototyp, zamiana go w produkcję jest dość prosta.
Chcę też szybko polecić książkę „Shape Up” Ryana Singera — to niezwykle dobra i bardzo wpływowa dla mnie pozycja. Czytałem ją chyba w 2019 roku i całkowicie zmieniła sposób, w jaki buduję aplikacje. Jest w całości darmowa online, link wrzucę w opisie.
(Informacja dodatkowa: „Shape Up” to książka o procesie produktowym rozwinięta w firmie Basecamp; jej autor, Ryan Singer, opisuje m.in. pracę w stałych „cyklach” i wczesne szkicowanie zamiast drobiazgowych estymacji).
Jeśli chcesz być na bieżąco z moimi skillami, mój newsletter to najlepsze miejsce. Nieustannie wysyłam kolejne rzeczy i wciąż myślę o tym, jak ulepszyć te skille — a ty możesz z tego korzystać tego samego dnia, w którym wprowadzam zmiany. Dziękuję za oglądanie, jak zawsze była to przyjemność, do zobaczenia wkrótce.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Prototyp bije specyfikację tam, gdzie chodzi o wygląd i zachowanie
Na czym polega: Zamiast szlifować drobiazgową specyfikację dla AI, buduj tani, jednorazowy kod odpowiadający na konkretne pytanie projektowe. Skok od specyfikacji do kodu produkcyjnego jest ogromny; od działającego prototypu do produkcji — mały.
Jak stosować: Gdy złapiesz się na dopracowywaniu specyfikacji dotyczącej wyglądu lub zachowania, przerwij i poproś agenta o działający prototyp, na który możesz zareagować.
Na co uważać: Prototyp to kod jednorazowy, do wyrzucenia — nie traktuj go jak fundamentu produkcji. Zapisuj go na osobnej gałęzi, a implementer niech z niego czerpie, nie rozwija go w miejscu.
2.Myśl w kategoriach wierności (fidelity)
Na czym polega: Pytania projektowe różnią się poziomem wierności potrzebnym do odpowiedzi. Proste („anuluj/potwierdź”) rozstrzygasz w rozmowie; „jak wyświetlić te dane” wymaga zobaczenia tego w działaniu.
Jak stosować: Zanim zaczniesz pisać, zapytaj siebie: „czy da się na to odpowiedzieć rozmową, czy muszę to zobaczyć w działaniu?”. Drugie to sygnał do prototypu.
Na co uważać: Wyższa wierność kosztuje więcej tokenów i czasu. Nie podnoś jej dla pytań, które spokojnie rozstrzygnie dyskusja.
3.Spadek kosztu kodu zmienia opłacalność prototypowania
Na czym polega: Tanie nie jest samo posiadanie kodu, lecz jego wytworzenie. To sprawia, że szybkie spike’i i prototypy są dziś skuteczniejszym narzędziem niż kiedykolwiek.
Jak stosować: Prototypuj częściej i wcześniej niż w epoce ręcznego kodowania — próg opłacalności eksperymentu znacząco się obniżył.
Na co uważać: „Tanie wytworzenie” nie znaczy „darmowe utrzymanie”. Jednorazowy kod, który przemyci się do produkcji, generuje realny dług — dlatego prototyp trzeba świadomie usunąć.
4.Generuj kilka wariantów naraz i porównuj na żywo
Na czym polega: W demie agent stworzył warianty A, B, C jednego paska wyszukiwania, każdy kodujący inne decyzje projektowe, między którymi można się przełączać.
Jak stosować: Proś o kilka alternatyw jednocześnie zamiast jednej „najlepszej” — łatwiej reagować na konkretne różnice niż wymyślać rozwiązanie od zera.
Na co uważać: Nie wybieraj po prostu najlepszego wariantu. Wartość tkwi w iteracji: łączeniu mocnych stron („pole z A, układ z C”) w nową wersję.
5.Podpinaj prototyp do żywej trasy, nie do atrapy
Na czym polega: Autor woli prototyp zintegrowany z realną stroną i prawdziwymi danymi niż osobną, sztuczną trasę — to uczciwsze odwzorowanie działania docelowego kodu.
Jak stosować: Buduj prototyp na realnym modelu danych i realnej ścieżce, jeśli to możliwe — ujawnia problemy, których atrapa by nie pokazała.
Na co uważać: Integracja z żywą stroną jest bardziej ryzykowna dla istniejącego kodu. Trzymaj to na gałęzi jednorazowej i pilnuj, by prototypowy kod nie został na trasie produkcyjnej.
6.Prototyp zostawia implementerowi kod, nie tylko opis
Na czym polega: Po iteracji decyzje projektowe są zakodowane w realnym frontendzie na gałęzi jednorazowej. Właściwa implementacja dostaje specyfikację i kod do skopiowania.
Jak stosować: Po zamknięciu prototypu przekaż go agentowi wykonawczemu (np. w tle) z zadaniem: podepnij, usuń stary kod prototypu, zapewnij zgodność z pierwotną specyfikacją.
Na co uważać: Wyraźnie zleć usunięcie kodu prototypowego, inaczej zostanie duplikat. Pilnuj zgodności z pierwotnymi wymaganiami — prototyp mógł od nich odbiec podczas iteracji.
7.Kompaktuj kontekst, gdy chcesz kontynuować z zachowaniem decyzji
Na czym polega: Sesja prototypu zjadła ~100 tys. tokenów. Autor kompaktuje (streszcza) kontekst, by zachować decyzje projektowe i dalej dawać feedback w tym samym miejscu kodu.
Jak stosować: Kompaktuj, gdy potrzebujesz zachować historię decyzji, ale odzyskać miejsce w kontekście. Czyść lub rób handoff, gdy zaczynasz w istocie nowe zadanie.
Na co uważać: Kompaktowanie może zgubić szczegóły — upewnij się, że kluczowe decyzje projektowe faktycznie przetrwały, zanim ruszysz dalej.
8.Prototypuj też logikę i backend, nie tylko UI
Na czym polega: Dla złożonej logiki czy maszyny stanów można zbudować małą interaktywną aplikację terminalową, która przepycha stan przez trudne przypadki — czysto logiczny prototyp.
Jak stosować: Gdy pytanie brzmi „czy ten model stanu czuje się dobrze?”, zbuduj mały interaktywny harness zamiast rozumować na papierze.
Na co uważać: Prototyp logiczny wymaga innych wskazówek niż UI — przygotuj osobny dokument referencyjny (albo jasny opis), by agent wiedział, którą ścieżkę budować.
9.„AI zbudowało coś dziwnego” to zwykle za niska wierność dyskusji
Na czym polega: Skargi „stworzyłem piękną specyfikację, a wyszło coś dziwnego” najczęściej wynikają z prowadzenia rozmowy na zbyt niskiej wierności zamiast prototypowania.
Jak stosować: Gdy wynik AI rozjeżdża się z oczekiwaniami, potraktuj to jako sygnał, że pytanie wymagało prototypu, a nie kolejnej rundy opisu.
Na co uważać: Nie leczstwo objawów jeszcze dokładniejszą specyfikacją — to często zwiększa iluzję kontroli bez rozstrzygnięcia realnych pytań o wygląd i zachowanie.
10.Fundament: prototypowanie i „Shape Up” to nie nowość, lecz powrót do korzeni
Na czym polega: Spike’i i prototypy istnieją od czasów Agile’a; autor mocno odwołuje się do darmowej książki „Shape Up” Ryana Singera jako źródła tego podejścia.
Jak stosować: Przeczytaj „Shape Up”, by osadzić prototypowanie z AI w sprawdzonym procesie produktowym, zamiast traktować je jako świeży trik na agenty.
Na co uważać: Narzędzia AI zmieniają koszt, nie zasadę. Nie wyrzucaj dyscypliny (jednorazowość, jasne pytanie, świadome sprzątanie) tylko dlatego, że kod jest teraz tani do wygenerowania.