O czym jest ten film
- Autor wskazuje trzy powtarzalne przyczyny, dla których budowanie z agentami nie daje efektów widocznych w cudzych demonstracjach.
- Pierwsza przyczyna: zbyt płytki proces planowania — jedno „pomóż mi to zaplanować” zamiast wielogodzinnej, wieloetapowej pracy.
- Proponuje czterofazowy proces planowania: eksploracja, propozycja (dlaczego), projekt systemu (co), specyfikacje i zadania (jak).
- Faza eksploracji obejmuje domenę biznesową, technologię (SDK, API, biblioteki), dobre praktyki oraz miejsce nowej funkcji w istniejącej aplikacji.
- Druga przyczyna: „context rot” na poziomie budowy — do planu wchodzi kontekst, który nie jest ani wartościowy, ani na teraz.
- Skutkiem nieprzyciętego kontekstu jest przeinżynierowanie: zakres puchnie, projekt nigdy się nie kończy albo kończy jako zbiór niepowiązanych elementów.
- Autor stosuje własną kombinację umiejętności: audyt przeinżynierowania plus „przesłuchanie” intencji przed rozpoczęciem planu.
- Trzecia przyczyna: opieranie budowy wyłącznie na skillach, bez systemu z fazami, artefaktami i bramkami kontrolnymi.
- Ostrzega przed przeklejaniem transkryptów filmów z YouTube do modelu z prośbą „zbuduj mi taki system”.
- Omawia dwa narzędzia spec-driven: OpenSpec (elastyczny, żywy rejestr zmian) i GitHub Spec Kit (bardziej rygorystyczny, z konstytucją projektu).
Redakcyjne tłumaczenie
Problem, który zna każdy budujący z agentami
Jeśli budujesz cokolwiek z agentami i frustruje cię, że efekt nigdy nie dorównuje twoim oczekiwaniom, prawdopodobnie wiesz, o czym mówię. Widzisz ludzi robiących demonstracje na YouTubie, widzisz posty w całym internecie, w których powstają świetne rzeczy — a u ciebie to po prostu nigdy nie działa tak, jak wygląda u nich.
Są trzy obszary, w których najczęściej idzie coś nie tak. W tym materiale rozłożę je na części i pokażę, jak ich uniknąć. Ten film jest przeznaczony w szczególności dla ciebie, jeśli w budowaniu z AI uważasz się za zaawansowanego początkującego albo osobę na poziomie średnim.
Problem pierwszy: cykl planowania
Jeśli zapytasz dowolnego poważnego twórcę, jak wygląda jego proces — a przez „poważnego” rozumiem inżynierów z zawodu albo ludzi, którzy wdrażają te rzeczy w biznesie i naprawdę mają dobre wyniki — okaże się, że ogromną ilość czasu spędzają w procesie planowania.
I nie chodzi o pierwsze podejście do pomysłu, który wrzucasz do modelu ze słowami: „pomóż mi to zaplanować”. Chodzi o godziny spędzone w wielu etapach procesu, po to, by upewnić się, że to, co zamierzasz zbudować, odpowiada twojej intencji i faktycznie zrealizuje cel, który sobie postawiłeś. To dotyczy w równym stopniu budowania aplikacji, oprogramowania, przepływów agentowych dla siebie samego czy czegoś, co sprzedajesz innym.
Twój proces planowania musi być bardzo szczegółowy i dopracowany. Konkretnie: istnieje z grubsza czterofazowy proces, którym moim zdaniem powinien podążać każdy.
Faza eksploracji
Pierwsza faza to eksploracja. Jest w niej kilka rzeczy, które trzeba naprawdę dobrze zamknąć.
Kiedy mówię „eksploruj”, mam na myśli przeglądanie bazy kodu oraz wychodzenie na zewnątrz — wyszukiwanie w sieci, głębokie badania i tym podobne. Chodzi o to, żeby naprawdę zrozumieć domenę tematyczną. Budujesz aplikację marketingową? Fitnessową? Finansową? Cokolwiek to jest, musisz być bardzo dobrze zorientowany w tym temacie w zakresie, w jakim dotyczy tego, co próbujesz zbudować. To świetny moment, żeby uruchomić deep research albo inny podobny przepływ pracy.
(Informacja dodatkowa: „deep research” to tryb dostępny w wielu asystentach AI, w którym model przez kilkanaście minut samodzielnie przeszukuje sieć i składa z tego obszerny raport ze źródłami).
Druga rzecz to technologia. Na podstawie tego, co deklarujesz, że chcesz zrobić — jakie są faktyczne kwestie techniczne? Chodzi o SDK, których być może będziesz musiał użyć, API, biblioteki.
Trzecia rzecz to dobre praktyki. Nie tylko w samej domenie tematycznej — w której, mam nadzieję, masz już doświadczenie — ale również te związane z technologią. Szczególnie jeśli budujesz narzędziami AI, czyli tworzysz faktycznych agentów i podobne rzeczy: ta przestrzeń zmienia się tak często, dostawcy modeli aktualizują swoje SDK, dobre praktyki ewoluują z czasem. Musisz naprawdę wydobyć wszystkie dobre praktyki związane z aplikacją albo — myśląc węziej — z samą funkcją, którą chcesz zbudować. Jeśli zamierzasz zbudować pętlę agentową, to jakie są współczesne dobre praktyki dotyczące używania narzędzi, promptów systemowych, pamięci, sposobu prowadzenia pętli, logiki w jej wnętrzu i całej reszty.
Ostatni element to: gdzie w twojej aplikacji. Jeśli masz już coś istniejącego, to z czym ta rzecz, którą rozważasz, styka się w twojej aplikacji? Czy masz już jakieś komponenty, jakieś usługi, do których trzeba będzie się podpiąć? Jak to wszystko mapuje się na to, o czym myślisz? To właśnie jest faza eksploracji.
Przycinanie kontekstu jako osobny krok
Drugi element — do którego wrócę, bo to drugi główny punkt tego filmu — to jeden z największych trybów awarii, jakie widzę u ludzi: przycinanie kontekstu.
Eksploracja wygeneruje ci mnóstwo materiału. I nie wszystko z tego będzie istotne, wartościowe albo zgodne z kierunkiem, w którym faktycznie chcesz to poprowadzić. Musisz zadbać o to, żeby wyciągnąć cały ten zły materiał z kontekstu, który zostanie użyty w następnej fazie. Bo jeśli tego nie zrobisz, dostaniesz wszystkie te wiszące luźno pomysły i przemyślenia o implementacji, rozważane wybory technologiczne i całą resztę — a to wykolei twój plan.
Podsumowując pierwszą fazę: czy rozumiemy temat, technologię, która wejdzie w grę, miejsce, w którym to faktycznie pasuje do tego, co mamy do tej pory, oraz dobre praktyki dotyczące implementacji czegoś takiego.
Faza planowania: cztery artefakty
Kiedy to mamy za sobą, przechodzimy do właściwej fazy planowania. Z eksploracji powinniśmy wynieść solidne rozumienie tego, co zbudujemy, jakiej technologii użyjemy, jaka jest motywacja stojąca za budową tej rzeczy, jak wpisuje się ona w naszą aplikację, dlaczego pasuje do tego, co budujemy, i jakie są dobre praktyki jej tworzenia. Ale to trzeba jeszcze zamienić w coś, z czego da się faktycznie budować. Tutaj wielu ludzi, jak sądzę, popełnia błąd i odchodzi od tego, co powinni robić.
Mój proces planowania składa się z czterech faz. Używam do tego narzędzia spec-driven, o którym opowiem później, ale przejdźmy przez każdą fazę.
(Informacja dodatkowa: „spec-driven development” to podejście, w którym przed napisaniem kodu powstaje formalna specyfikacja, a agent buduje wyłącznie względem niej).
Propozycja — dlaczego. Pierwsza faza planu to propozycja. To jest „dlaczego” stojące za tym, co robisz. Uważam, że to najważniejsza rzecz, z którą musisz się utożsamić i którą musisz mieć bardzo dopracowaną, ponieważ to do niej będzie się później odwoływać sama budowa. Możemy o tym myśleć jak o intencji motywacyjnej dla modelu. W każdym momencie, gdy model musi podjąć decyzję w sprawie, która nie została skrajnie szczegółowo określona w zadaniach, sięgnie do tego, jaka jest motywacja za tym, co buduje, i sprawdzi, czy może to wykorzystać przy wyborze.
Zadbaj więc o to, żeby twoje „dlaczego” było udokumentowane — niezależnie od tego, czy używasz narzędzia spec-driven, czy masz własny wymyślony proces. „Dlaczego” musi być spisane szczegółowo i musisz się z nim zgadzać w stu procentach, bo posłuży ci to później jako kluczowy punkt odniesienia, wręcz jako filtr. Gdy model zboczy z kursu, możesz powiedzieć: „idź, przeczytaj propozycję i powiedz mi, gdzie twoim zdaniem to poszło źle, bo to nie jest intencja tego, co budowaliśmy”.
Projekt — co. Skoro wiemy, dlaczego budujemy, musimy omówić, co właściwie budujemy. Projekt nie oznacza tu warstwy wizualnej — chodzi o projekt systemu. Jakie są modele bazy danych? Jakie elementy dodajemy? Jak to wpasowuje się w istniejący system? Czy będą nowe punkty końcowe API, czy rozszerzamy istniejące? Jakie są wszystkie decyzje architektoniczne związane z tym, co zamierzamy zrobić?
I znowu: ta faza i poprzednia ciągną kontekst z góry. Właśnie dlatego tak ważne jest, żeby przyciąć kontekst i żebyśmy naprawdę zgadzali się z wynikami fazy eksploracji.
Specyfikacje — jak. Kiedy mamy „dlaczego” i „co”, trzeba zejść poziom głębiej, bo zbliżamy się do „jak”. Jak konkretnie zbudujemy tę rzecz — i tu wchodzą specyfikacje. Zapisałem tu „specyfikacje techniczne”, ale właściwiej byłoby powiedzieć: specyfikacja funkcji. Pomyśl o dokumencie wymagań produktu z kryteriami akceptacji, który mówi: gdy zdarzy się to, ma się stać tamto; gdy zdarzy się tamto, ma się stać jeszcze coś innego; a gdy zdarzy się jedno i drugie, ta trzecia rzecz nie powinna się wydarzyć.
(Informacja dodatkowa: PRD — Product Requirements Document — to dokument wymagań produktowych opisujący, co system ma robić z perspektywy użytkownika, wraz z warunkami odbioru).
Ten styl specyfikowania służy nam poniekąd za kryteria akceptacji, gdy zadajemy pytanie: czy ta autonomiczna budowa, którą puściliśmy samopas na piętnaście godzin, faktycznie zrobiła to, czego chcieliśmy? Musi istnieć sposób zmierzenia tego względem czegoś obiektywnego — i tym czymś są właśnie specyfikacje.
Zadania. Mamy więc nasze „dlaczego”, czyli propozycję. Mamy „co”, czyli projekt i specyfikacje. A gdy to wszystko jest gotowe, ostatnim etapem procesu jest rozbicie tego na zadania.
Planowanie jako pętla
Cały proces — eksploracja, przycinanie kontekstu, planowanie — to po prostu pętla, którą będziesz powtarzać. Kiedy myślisz o pojęciach w rodzaju „loop engineering”, to właśnie ten typ przepływu pracy. Możesz wdrożyć systemy, które pomogą to zautomatyzować. Są pewne typy decyzji, które będziesz podejmować w kółko, raz za razem — takie rzeczy można skodyfikować. Ale ostatecznie to jest ta pętla planowania, przez którą będziesz się poruszać.
Nagrałem wiele filmów na ten temat, przyglądając się konkretnym narzędziom; podlinkuję jeden z nich, jeśli chcesz zobaczyć narzędzia, które robią dokładnie to za ciebie.
Sedno tej sekcji jest takie: niezależnie od tego, czy budujesz przepływy agentowe, aplikacje, czy właściwie cokolwiek innego, musisz mieć tego rodzaju bardzo szczegółowy proces planowania. W przeciwnym razie budujesz na najgorszym możliwym fundamencie i wszystko będzie się na tobie zawalać i przestawać mieć sens. Może i będzie to jakoś działać, ale nie da ci wyników, których szukasz.
Problem drugi: gnicie kontekstu i przeinżynierowanie
To prowadzi mnie do rzeczy, o której wspomniałem wcześniej: „context rot”, czyli gnicia kontekstu, oraz przycinania kontekstu.
(Informacja dodatkowa: „context rot” to określenie na degradację jakości odpowiedzi modelu w miarę zapełniania okna kontekstowego materiałem nieistotnym lub sprzecznym).
To ogromny tryb awarii i dotyczy zarówno samej budowy aplikacji, jak i właściwie każdej próby wykonania pracy umysłowej z modelem językowym — na przykład gdy prosisz AI, żeby poszło poszukać materiałów, ściągnęło je i zsyntetyzowało w coś, na czym potem oprzesz działanie albo co wpleciesz w jakiś swój proces. Ten tryb awarii nazywam gniciem kontekstu na poziomie budowy i to jest powód, dla którego mamy osobną fazę przycinania kontekstu.
Wyjaśnię bardzo konkretnie, jak się to objawia. Na początku fazy planowania, gdy jesteś w eksploracji, zwykle generujesz mnóstwo kontekstu i mnóstwo pomysłów — ale nie cały ten kontekst jest, po pierwsze, w ogóle wartościowy, a po drugie, taki, który należałoby zintegrować z tym, co budujesz właśnie teraz.
Jedną z ważnych rzeczy, które zaobserwowałem u agentów kodujących, jest to, że potrafią wygenerować tak wiele różnych pomysłów i drobiazgów — malutkich rzeczy do dodania, które uznają za lepsze — że przeinżynierują coś, co zamienia się w potwora. Albo w ogóle nigdy nie dochodzisz do końca tego, nad czym pracowałeś, bo to puchnie i puchnie jak rozszerzający się wszechświat, albo w końcu kończysz proces budowy i masz tam wszystkie te dodatkowe rzeczy, z których nic nie trzyma się spójnie kupy.
Powód jest taki: jeśli nie zdecydowałeś tego wszystkiego z wyprzedzeniem, a potem nie przyciąłeś tego w fazie generowania kontekstu, to nic nie jest spójnie powiązane z propozycją, z powodem, dla którego coś robiliśmy, z tym, czym ta rzecz miała być i jak wszystko miało się złożyć w całość. Nic z tego nie jest naprawdę obecne — więc model po prostu pójdzie i zrobi, co mu się, do licha, spodoba.
Kryterium: wartościowe czy nie, teraz czy później
Czy ten kontekst jest wartościowy? Jeśli nie — po prostu go odrzuć. Ale czasem dostaniesz pomysł, o którym myślisz: może rzeczywiście powinienem coś takiego rozważyć. Tylko czy należy go zintegrować właśnie teraz?
Dlatego uważam, że używanie narzędzia w rodzaju GitHub Issues, Lineara albo innego prawdziwego narzędzia do zarządzania projektem jest bardzo wartościowe: możesz powiedzieć „nie, przenieś to do backlogu, wrócę do tego później”. A potem możesz mieć inne przepływy albo pętle działające w tle, które przeglądają rzeczy dodane do backlogu i faktycznie je priorytetyzują. Jeśli natomiast odpowiedź brzmi „tak, chcę to zintegrować”, to właśnie wtedy przechodzisz do zaproponowania funkcji i budowania planu.
Zwykle objawia się to tak: rozmawiasz z modelem tam i z powrotem, a on mówi: „Sean, skoro refaktoryzujemy wywoływanie narzędzi, to prawdopodobnie powinniśmy też zrefaktoryzować wszystkie twoje prompty systemowe i rozważyć jeszcze te jedną czy dwie przypadkowe, egzotyczne rzeczy, bo pomogą ci w taki a taki sposób”. A ty masz to swoje narzędzie do zadawania pytań użytkownikowi i po prostu klikasz „okej, tak, akceptuję” — i tak powoli, powoli, powoli rozdmuchujesz zakres tego, co próbujesz zbudować. To koszmar.
Jak autor to rozwiązuje
Rozwiązuję to tak, że mam skilla, którego używam za każdym razem, gdy buduję coś istotnego i przechodzę przez eksplorację i przycinanie. Jest to wersja repozytorium „ponytail”. Jeśli go nie znasz — służy pomocą w unikaniu przeinżynierowania albo w audytowaniu bazy kodu pod kątem rzeczy przeinżynierowanych. Lubię umieszczać wersję tego skilla w połączeniu ze skillem typu „przesłuchaj mnie”, żeby naprawdę dotrzeć do intencji tego, co chcę zbudować, i wyrzucić wszystko, co jest przeinżynierowaniem i czego nie trzeba rozwiązywać teraz.
(Informacja dodatkowa: „skill” to w tym kontekście zapisany zestaw instrukcji, który agent wczytuje na żądanie i traktuje jak procedurę do wykonania).
Efekt jest taki, że mamy naprawdę oszczędną fazę planowania, która nie jest rozdęta. Nie trzeba budować wszystkich tych rzeczy, na których w rzeczywistości ci nie zależy albo które w ogóle nie muszą tam być. Idzie znacznie szybciej. Zużywa dużo mniej tokenów. I znowu — masz bardzo skupioną, właściwą fazę budowy.
Przeinżynierowanie — zwłaszcza jeśli nie jesteś programistą i realistycznie rzecz biorąc nawet nie wiedziałbyś, że coś przeinżynierowałeś — wymaga zabezpieczeń, które to wyłapią. To prawdopodobnie jedna z najważniejszych rzeczy, jakie możesz zrobić. A realistycznie jedynym sposobem, żeby to powstrzymać, jest strzeżenie swojego kontekstu tak, jakby zależało od tego życie tego, co budujesz — bo faktycznie zależy.
Problem trzeci: brak zdecydowanego systemu budowania
Ostatni duży tryb awarii to brak silnego, opiniotwórczego systemu budowania. Jeśli jesteś kimś, kto w budowaniu polega wyłącznie na skillach, czeka cię bardzo, bardzo ciężki czas. I to jest prawdą niezależnie od tego, czy budujesz aplikacje, przepływy agentowe, czy po prostu usprawnione przepływy w stylu n8n, czy używasz Hermesa, OpenClaw albo któregoś z innych rozwiązań open source. Jeśli nie masz uporządkowanego systemu budowania tego, co chcesz zbudować, i polegasz jedynie na skillach oraz jakimś agencie, który ma zorkiestrować całość bez barierek ochronnych — czeka cię koszmar.
Szczególnie jeśli próbujesz brać te skille i przepływy z filmów na YouTubie. Wiele osób bierze transkrypty filmów, przekazuje je modelowi językowemu i mówi: „na podstawie tego, co ten człowiek właśnie powiedział, zbuduj mi system, który zrobi to wszystko za mnie”. Próbują zamienić to w skilla i sądzą, że to coś da. To fatalny pomysł. Jeśli na przykład widziałeś film Grega Eisenberga o graph engineeringu — gdybyś spróbował po prostu wziąć transkrypt tego, co tam opisuje, wkleić do modelu językowego i kazać mu zbudować sobie system graph engineeringu, wybuchnie ci to w twarz.
Rozwiązanie: system spec-driven
Oto, co możesz z tym zrobić. Każdy system skilli, jaki masz, powinien przechodzić przez system spec-driven albo system cyklu życia wytwarzania oprogramowania — czyli faktyczny system, który ma barierki ochronne i konkretne fazy z konkretnymi artefaktami, weryfikowanymi jeden względem drugiego. Moje ulubione narzędzia to OpenSpec i GitHub Spec Kit.
Przeprowadzę cię szybko przez to, jak te rzeczy działają na wysokim poziomie, żebyś zobaczył, gdzie się wpasowują. Wartość tych narzędzi polega na tym, że naprawdę pomagają rozłożyć na części to, o czym myślisz, i upewnić się, że zintegruje się to poprawnie oraz że wszystkie mechanizmy kontroli i równowagi są na miejscu — tak, żeby gdy pójdziesz to budować, rzecz faktycznie działała.
Jak działa OpenSpec
Jeśli spojrzymy na OpenSpec i to, jak mapuje się on na wszystko, o czym mówiłem wcześniej, pierwszym etapem jest faza eksploracji — zanim jeszcze cokolwiek zaproponowaliśmy do zbudowania, po prostu wychodzimy i patrzymy na całą przestrzeń problemu. Możesz uruchomić polecenie eksploracji. Możesz przekazać własne polecenia dotyczące obszarów, którym chcesz się przyjrzeć: technologia, dobre praktyki, przeszukanie obecnej bazy kodu i wróć do mnie z tym, co o tym sądzisz.
Kiedy to masz, możesz odpalić polecenie propozycji. Ono przejdzie przez proces i wygeneruje artefakty planowania. Co to za artefakty? Dostajesz propozycję i projekt, tak jak omawialiśmy. Dostajesz właściwą specyfikację. To, co naprawdę w tym uwielbiam, to fakt, że rozbija te specyfikacje na kategorie: czy dodajemy nową funkcję, modyfikujemy istniejącą funkcjonalność, czy usuwamy coś w całości. Wartość tego polega na tym, że staje się to żywym systemem. Gdy będziesz budować w przyszłości, nie zaprzeczysz rzeczom, które już zbudowałeś, ponieważ system prowadzi bieżący dziennik wszystkiego, co zrobiłeś, i tego, dlaczego to zrobiłeś, oraz wie, jakie commity są z tym powiązane. Dużo lepszy proces.
Kiedy mamy to wszystko, generujemy zadania i całość zostaje zapisana pod jedną zmianą w OpenSpecu. Przechodzimy więc przez proces, generujemy wszystkie pliki planowania, a potem mówimy „zastosuj”. System odhacza całą listę zadań. Jeśli w trakcie, gdy to działa, wpadniemy na coś nowego i stwierdzimy, że trzeba zaktualizować to, co mamy, można to zaktualizować w miejscu — co jest wspaniałe. A potem, gdy jest po wszystkim, możemy zsynchronizować to z powrotem do naszej głównej listy specyfikacji, tak żebyśmy w przyszłości nie zaprzeczali sami sobie i nie psuli rzeczy, które już działały. Wiem, że to jest coś, co wielu ludzi bardzo frustruje.
Ten film nie dotyczy procesu budowania, bo tutaj weszłyby jeszcze inne etapy, jak przeglądy adwersarialne i poprawki — ale tak właśnie działa OpenSpec.
(Informacja dodatkowa: „przegląd adwersarialny” to celowe skierowanie osobnego agenta na wytworzony kod z zadaniem znalezienia w nim błędów, zamiast pytania „czy jest dobrze?”).
Jak działa GitHub Spec Kit
Następną rzeczą jest GitHub Spec Kit. Uchodzi za bardziej rygorystyczny — jest więcej bramek, gdy chcesz przejść między fazami. O ile w OpenSpecu można przeskakiwać między fazami, jeśli tego potrzebujesz, i po prostu bardzo dobrze wykorzystywać jego infrastrukturę, o tyle w Spec Kicie przechodzisz z fazy do fazy do fazy do fazy, a na końcu masz gotową rzecz.
Jak to działa? Po pierwsze — i to jedna z rzeczy, które lubię w nim najbardziej — ma system konstytucji. Wszelkie zasady dotyczące twojej aplikacji, tego, co rzeczy oznaczają, etosu firmy albo tworzonego produktu i tego, jak system ma o pewnych rzeczach pamiętać — to wszystko zostaje wygenerowane i zapisane, a funkcji nie da się zbudować bez walidacji względem tego dokumentu. Narzędzie wygeneruje ci dosłownie plik markdown, o ile pamiętam nazywa się constitution.md. Gdy zabierasz się do planowania funkcji, zaczynasz coś budować i generujesz zadania, system musi zajrzeć do tego pliku i upewnić się, że wszystko przechodzi walidację. Jeśli nie przechodzi, odbije ci to z komunikatem: „nie mogę iść dalej z budową, bo to narusza zasady, które ustaliłeś”.
Dalej płyniemy przez właściwy proces Spec Kita. Jest polecenie specify — zaczynamy więc od specyfikacji. Potem jest etap clarify, który upewnia się, że w twojej specyfikacji nie ma nic niejednoznacznego, że nie ma czegoś, o czym nie pomyślałeś, a co pozwoliłoby modelowi pójść i podjąć dowolną przypadkową decyzję — bo to, znowu, jest ogromny tryb awarii. Gdy mamy to za sobą, możemy zaplanować budowę; jest to odpowiednik pliku markdown z projektem, który dostałbyś z OpenSpeca. Następnie budujemy zadania. Możemy przepuścić to przez własne bramki jakości — możemy mieć listy kontrolne, przez które system musi przejść i sprawdzić, czy buduje to, co chcemy zbudować. A na końcu tego wszystkiego przechodzimy do implementacji.
Artefakty Spec Kita wyglądają więc tak: masz konstytucję, czyli wszystkie zasady, których trzeba przestrzegać. Masz wymagania i historyjki użytkownika — gdy zdarzy się to, ma się stać tamto. Masz właściwy plan tego, co zamierzamy zrobić, modele danych oraz kontrakty API, co jest bardzo ważną rzeczą: wiedza o tym, co każdy punkt końcowy powinien przyjmować i co odeśle do frontendu, żeby nie było tam żadnej niejednoznaczności i żeby system nie poszedł psuć przypadkowych rzeczy. I wreszcie zadania — rozbite na fazy, z zaznaczeniem, które można wykonywać równolegle, a które muszą iść po kolei. Ogólnie rzecz biorąc, to naprawdę solidny system.
Podsumowanie
Trzy największe tryby awarii, jeśli budowanie z agentami ci nie wychodzi. Po pierwsze: twój cykl planowania nie jest wystarczająco solidny. Po drugie: wpuszczasz o wiele za dużo kontekstu, którego nie powinno tam być, a to prowadzi budowę w złym kierunku. Po trzecie: nie masz naprawdę porządnego, uporządkowanego systemu budowania tego, co próbujesz zbudować.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Planowanie to godziny, nie jeden prompt
Na czym polega: Ludzie, którzy osiągają dobre wyniki z agentami, spędzają w planowaniu nieproporcjonalnie dużo czasu — w wielu etapach, a nie w jednym podejściu „pomóż mi to zaplanować”.
Jak stosować: Zanim uruchomisz jakąkolwiek budowę, przejdź świadomie przez cztery fazy: eksplorację, propozycję, projekt systemu, specyfikacje i zadania. Traktuj przejście do kodu jako moment, który wymaga decyzji, a nie jako domyślny kolejny krok.
Na co uważać: Ryzyko odwrotne to planowanie bez końca. Autor nie mówi, ile godzin wystarczy — sygnałem gotowości jest to, że masz spisane „dlaczego”, „co” i mierzalne kryteria akceptacji, a nie poczucie, że przemyślałeś wszystko.
2.Eksploracja ma cztery konkretne osie
Na czym polega: Faza eksploracji obejmuje domenę tematyczną, technologię (SDK, API, biblioteki), dobre praktyki oraz miejsce nowej funkcji w istniejącej aplikacji.
Jak stosować: Zrób z tego listę kontrolną i przejdź przez każdą oś osobno — na przykład uruchamiając deep research na domenę i osobno przeszukanie własnej bazy kodu pod kątem punktów styku.
Na co uważać: Oś „gdzie w mojej aplikacji” jest najczęściej pomijana, a to ona decyduje, czy nowa funkcja podepnie się do istniejących usług, czy powstanie równolegle drugi, konkurencyjny mechanizm.
3.Dobre praktyki AI dezaktualizują się szybciej niż twoja wiedza
Na czym polega: Dostawcy modeli aktualizują SDK, a dobre praktyki budowy agentów zmieniają się na tyle często, że wiedza sprzed kilku miesięcy bywa nieaktualna.
Jak stosować: Przy każdej istotnej funkcji agentowej odśwież konkretne praktyki: użycie narzędzi, prompty systemowe, pamięć, logika pętli. Rób to na świeżym wyszukiwaniu, nie z pamięci modelu.
Na co uważać: Model chętnie wygeneruje „dobre praktyki” z własnych danych treningowych, brzmiące wiarygodnie i przestarzałe. Wymuszaj odwołanie do bieżącej dokumentacji.
4.Propozycja to intencja motywacyjna dla modelu
Na czym polega: Dokument „dlaczego” staje się punktem odniesienia, do którego model sięga za każdym razem, gdy musi podjąć decyzję nieokreśloną w zadaniach.
Jak stosować: Spisz motywację szczegółowo i upewnij się, że zgadzasz się z nią w całości. Gdy budowa zboczy z kursu, zamiast poprawiać kod poproś model: przeczytaj propozycję i wskaż, gdzie odeszliśmy od intencji.
Na co uważać: Propozycja napisana ogólnikami („chcemy lepszego UX”) nie filtruje niczego. Musi być na tyle konkretna, żeby dało się na jej podstawie odrzucić jakąś sensownie brzmiącą opcję.
5.Specyfikacja to kryteria akceptacji, nie opis
Na czym polega: Specyfikacja funkcji ma mieć formę warunkową w stylu PRD: gdy zdarzy się X, ma się stać Y; a gdy zdarzy się Z, ta rzecz nie powinna się wydarzyć.
Jak stosować: Pisz w parach warunek–skutek, włącznie z zachowaniami negatywnymi. To jedyne obiektywne odniesienie, względem którego zmierzysz wynik długiej, autonomicznej budowy.
Na co uważać: Bez zapisanych zachowań negatywnych („to nie powinno się wydarzyć”) agent może spełnić wszystkie kryteria pozytywne i przy okazji zepsuć coś obok.
6.Przycinanie kontekstu to osobny etap, nie odruch
Na czym polega: Eksploracja generuje mnóstwo materiału, którego większość nie jest ani wartościowa, ani przeznaczona do realizacji teraz. Jeśli zostanie w kontekście, wykolei plan.
Jak stosować: Po eksploracji zatrzymaj się i przejdź przez wygenerowany materiał z dwoma pytaniami: czy to jest wartościowe? jeśli tak — czy na teraz? Dopiero przycięty materiał wchodzi do fazy propozycji.
Na co uważać: To dotyczy nie tylko kodowania, ale każdej pracy umysłowej z modelem, w której badanie poprzedza syntezę. Materiał odrzucony na tym etapie nie zniknie sam — musisz go świadomie usunąć z kontekstu.
7.Backlog jako zawór bezpieczeństwa dla dobrych pomysłów nie na teraz
Na czym polega: Część pomysłów z eksploracji jest wartościowa, ale nie należy do bieżącego zakresu. Bez miejsca, gdzie je odłożyć, trafiają do budowy.
Jak stosować: Trzymaj prawdziwe narzędzie do zarządzania projektem (GitHub Issues, Linear) i odsyłaj tam wszystko, co brzmi dobrze, ale nie jest teraz. Możesz uruchomić przepływy w tle, które przeglądają i priorytetyzują backlog.
Na co uważać: Backlog działa tylko wtedy, gdy naprawdę do niego wracasz. Inaczej staje się wygodnym sposobem na odkładanie decyzji zamiast ich podejmowania.
8.Klikanie „akceptuję” to mechanizm rozdmuchiwania zakresu
Na czym polega: Typowy scenariusz: model proponuje „skoro już to refaktoryzujemy, to zróbmy przy okazji jeszcze te trzy rzeczy”, a ty odruchowo akceptujesz — i zakres puchnie krok po kroku.
Jak stosować: Traktuj każdą propozycję rozszerzenia jako osobną decyzję o zakresie, którą oceniasz względem propozycji i specyfikacji. Domyślną odpowiedzią niech będzie „do backlogu”, a nie „tak”.
Na co uważać: Efekt jest kumulatywny i niewidoczny pojedynczo — każde „tak” wydaje się rozsądne. Zauważysz problem dopiero wtedy, gdy budowa nigdy się nie kończy albo kończy jako zbiór niepowiązanych elementów.
9.Zabezpieczenia przed przeinżynierowaniem, zwłaszcza jeśli nie jesteś programistą
Na czym polega: Autor łączy skilla audytującego przeinżynierowanie (wersja repozytorium „ponytail”) ze skillem typu „przesłuchaj mnie”, żeby dotrzeć do rzeczywistej intencji i wyrzucić to, czego nie trzeba rozwiązywać teraz.
Jak stosować: Wpinaj taki audyt na stałe w fazę eksploracji i przycinania, przy każdej istotnej budowie. Efekt to szczuplejszy plan, szybsza praca i mniejsze zużycie tokenów.
Na co uważać: Osoba bez zaplecza programistycznego zwykle nie rozpozna przeinżynierowania samodzielnie — dlatego mechanizm ma być automatyczny i wpięty w proces, a nie zależny od twojej czujności w danym dniu.
10.Same skille nie wystarczą — potrzebny jest system z fazami i artefaktami
Na czym polega: Poleganie wyłącznie na skillach i agencie-orkiestratorze bez barierek prowadzi do awarii. Skille powinny działać wewnątrz systemu spec-driven z fazami, artefaktami i wzajemną weryfikacją. Autor poleca OpenSpec (elastyczny, z żywym rejestrem zmian i powiązaniem z commitami) oraz GitHub Spec Kit (bardziej rygorystyczny, z konstytucją projektu, etapem usuwania niejednoznaczności i bramkami jakości).
Jak stosować: Wybierz OpenSpec, jeśli chcesz móc przeskakiwać między fazami, a najbardziej zależy ci na tym, żeby przyszłe budowy nie zaprzeczały poprzednim. Wybierz Spec Kit, jeśli chcesz twardych bramek i zasad projektu, których nie da się ominąć.
Na co uważać: Nie próbuj odtwarzać cudzego systemu przez wklejenie transkryptu filmu do modelu i polecenie „zbuduj mi to” — autor podaje to wprost jako fatalny pomysł, który wybuchnie ci w twarz. Sam materiał świadomie pomija etap budowy (przeglądy adwersarialne, poprawki), więc nie jest kompletnym opisem procesu.