O czym jest ten film
- Autor twierdzi, że era ręcznego promptowania agentów się kończy, a przyszłością jest „loop engineering” — budowanie pętli, w których agent pracuje autonomicznie.
- Prezentuje własną pętlę („fin loop”) złożoną z trzech umiejętności (skills): spec, build, review.
- Spec przeprowadza z tobą wywiad o pomyśle, a następnie tworzy szczegółowe zadania (issues) z kryteriami akceptacji.
- Build w pętli buduje kolejne zadania z backlogu, a review je testuje w przeglądarce i przygotowuje pull requesty.
- Do śledzenia zadań używa darmowego Linear jako „drugiego mózgu” agenta.
- Powiadomienia o gotowych zmianach trafiają na Slack (lub Discord/Telegram); zatwierdzasz merge emoji rakiety.
- Twój udział ogranicza się do dwóch momentów: rano (podanie pomysłów) i wieczorem (zatwierdzenie merge’ów).
- Setup działa z dowolnym narzędziem obsługującym własne skille — Claude Code, Codex itd. — i opiera się na darmowych narzędziach.
- Autor udostępnia gotowe prompty w Google Doc, które same konfigurują całą infrastrukturę.
- Materiał zawiera fragment sponsorski (playbook HubSpot dla Claude Code) oraz zapowiedź automatyzacji nawet etapu wymyślania pomysłów.
Redakcyjne tłumaczenie
Wszyscy mówią o pętlach, ale nikt nie mówi, jak je zbudować
Ostatnio wszyscy dookoła mówią o pętlach w vibe codingu — o tak zwanym loop engineeringu. Ludzie tacy jak Peter Steinberg powtarzają: „Przestań w kółko promptować swoje agenty, zacznij budować pętle”. Nawet Boris z Claude Code — człowiek, który stworzył Claude Code — mówi dziś wyłącznie o pętlach: „Już nie promptuję Claude’a. To, czego głównie używam teraz, to pętle. Tworzę pętle, a one wykonują całą moją pracę”.
I mówię wam: oni nie kłamią. Problem polega na czymś innym. Wszyscy mówią o pętlach, ale nikt nie tłumaczy, jak taką pętlę zbudować. Nikt nie pokazuje, czym pętla właściwie jest. Mam dla was dobrą wiadomość — właśnie to zamierzam pokazać. Zbudowałem pętlę, która zautomatyzowała mniej więcej 95% mojej pracy przy vibe codingu. W tym materiale pokażę, jak ją zbudować i jak jej używać — w możliwie najbardziej przyjazny dla początkujących sposób.
Jak wygląda vibe coding przed pętlą i po pętli
Zacznijmy od tego, jak zapewne pracujesz dzisiaj. Wchodzisz do Claude Code albo Codeksa, wysyłasz prompt: „zbuduj ten interfejs, zbuduj tę grę, dodaj tę funkcję”. Agent to buduje, a ty siedzisz i ręcznie testujesz. Gdy skończysz, wysyłasz kolejny prompt: „dobra, teraz dodaj ten przycisk”. Agent dodaje przycisk, ty znowu testujesz. Każdy krok jest ręczny. Wszystko wymaga albo tego, że ty piszesz prompt, albo tego, że ty testujesz.
Największy problem: jeśli nie siedzisz przy komputerze i aktywnie nie promptujesz ani nie testujesz, nic się nie dzieje. Nic nie posuwa się do przodu. Ja żongluję teraz sześcioma projektami naraz. Wcześniej, jeśli nie poświęcałem czasu któremuś z nich, ten projekt stał w miejscu. W danym momencie posuwał się tylko jeden projekt. To ty — człowiek — jesteś wąskim gardłem.
To była oczywiście ogromna poprawa względem ręcznego pisania kodu, którym ludzie zajmowali się jeszcze kilka lat temu. Ale to wciąż nie jest maksymalna wydajność ani maksymalna automatyzacja, bo nadal wszystko robisz ręcznie.
Fin loop — trzy umiejętności: spec, build, review
Pozwól, że przedstawię ci nową erę. To jest „fin loop”. Tak, nazwałem tę pętlę własnym nazwiskiem — skoro ją wymyśliłem, wolno mi ją nazwać.
(Informacja dodatkowa: „skill” w Claude Code to zdefiniowana przez użytkownika umiejętność — zestaw instrukcji, który agent uruchamia komendą, np. /spec. Autor nazwał swoje skille z przedrostkiem „him”, bo pracuje w projekcie o nazwie „Henry” — w tym tłumaczeniu używamy neutralnych nazw spec, build, review.)
Pętla składa się z trzech umiejętności: spec, build i review. Poświęcasz kilka minut, żeby przekazać agentowi dokładnie te pomysły, które masz w głowie, a potem on przez cały dzień je buduje, recenzuje, sam testuje — buduje, recenzuje, testuje, w kółko, całkowicie autonomicznie. Na koniec ty tylko szybko przeklikujesz i wszystko się scala (merge).
Zamiast pracować cały dzień, ręcznie promptując agenta i samodzielnie testując, robisz jedynie jedno: luźno opisujesz pomysły z głowy, a on buduje, recenzuje i testuje. Twoja praca zmienia się z siedzenia przy komputerze przez cały dzień w to, że rano wpadasz, rzucasz kilka pomysłów, a wieczorem wracasz i wszystko jest gotowe i scalone. 95% pracy jest zautomatyzowane. Nawet jeśli masz rano tylko pięć wolnych minut, wchodzisz do tej pętli, a ona pracuje za ciebie autonomicznie — wie dokładnie, co budować, jak testować i jak scalać.
Można to zrobić dowolnym narzędziem do vibe codingu: Codex, Claude Code, cokolwiek wolisz. Dochodzi do tego kilka dodatkowych narzędzi, które pokażę — wszystkie darmowe. Podłączasz je do swojego agenta i masz gotowy setup, którym możesz zarządzać z dowolnego miejsca na świecie. Nie musisz już nawet dotykać Codeksa ani Claude Code.
[Fragment sponsorski: playbook HubSpot]
(Informacja dodatkowa: poniższy akapit to reklama partnera kanału.)
Budowanie pętli sprawia, że agent staje się dużo bardziej niezawodny — ale są też inne sposoby. Moi znajomi z HubSpot przygotowali „Claude Code Playbook” o budowaniu systemów, które czynią AI niezawodnym. Dla subskrybentów kanału jest za darmo. Nauczysz się z niego, jak stworzyć mocny plik reguł Claude’a, jak lepiej promptować, jak używać hooków, żeby agent nie zjechał z torów, oraz sub-agentów, żeby mieć armie agentów pracujących dla ciebie. Wszystko to integruje się z pętlą z tego filmu. Mój ulubiony fragment to dynamiczne workflow — możesz kazać Claude’owi napisać skrypt orkiestrujący, który uruchamia do 1000 agentów, zachowując kontekst głównego agenta w czystości. Link do darmowego playbooka jest pod filmem.
Krok 1: spec — wywiad, który zamienia pomysł w zadania
Robię to w Claude Code, ale zadziała w Codeksie i dowolnym narzędziu, w którym da się budować własne skille — czyli praktycznie wszędzie.
Pierwsza umiejętność to spec. To ona pomaga agentowi uchwycić wszystkie twoje pomysły i to ona uruchamia całą pętlę. To jedyna ręczna praca, jaką musisz wykonać, żeby wyprodukować mnóstwo wysokiej jakości kodu.
Wstajesz rano, bierzesz kawę, chcesz coś zbudować. Uruchamiasz skill spec, podajesz pomysł na wysokim poziomie — co to za funkcja — a spec zadaje ci tyle pytań, aż w pełni zrozumie pomysł i będzie mógł rozpisać dużo funkcji do zbudowania. Przeprowadza z tobą wywiad i sam dopracowuje szczegóły.
Przykładowo: chcesz zbudować grę. Piszesz /spec, potem „chcę zbudować grę” i wciskasz Enter. Agent zaczyna zadawać pytania, aż nabierze pewności, że może szczegółowo rozpisać wszystko, co ma powstać. Ja odpowiedziałem na jakieś 15 pytań — dzięki temu agent dokładnie zrozumiał funkcję, którą chcę zbudować w mojej aplikacji. W efekcie przygotował pięć zadań (issues), które prześle do pętli budowania.
Zadania to szczegółowe opisy prac z kryteriami akceptacji. Spec tworzy zestaw takich zadań i wysyła je do naszej pętli: buduj–recenzuj–testuj, buduj–recenzuj–testuj. Agent obsługuje to za nas, a my wracamy wieczorem, gdy praca jest gotowa, i szybko scalamy.
Spec zgłosił pięć nowych zadań — musimy je tylko zatwierdzić. Wszystkie trafiają do Linear, darmowej aplikacji, której używamy do śledzenia zadań.
(Informacja dodatkowa: Linear to popularne narzędzie do zarządzania projektami; ma darmowy plan.)
Oto przykładowe zadanie: AI zbudowało niezwykle szczegółowy dokument opisujący wszystko, co agent ma zbudować — kryteria akceptacji, w tym „non-goals” (czego robić nie należy), zakres, notatki oraz oczekiwania co do testowania. Wszystko to powstaje automatycznie dzięki umiejętności spec.
Linear działa tu jak „drugi mózg” agenta. Pozwala agentom — Codex, Claude Code, cokolwiek używasz — pamiętać każde zadanie, nad którym pracują, tak że gdy wracasz albo uruchamiasz nowe agenty, mogą wznowić pracę od bieżącego stanu.
Krok 2: build — pętla, która buduje cały backlog
Nasza poranna praca jest skończona: wypiliśmy kawę, rzuciliśmy kilka pomysłów, odpowiedzieliśmy na parę pytań. Teraz AI przejmuje pałeczkę i wykorzystuje dwie pozostałe umiejętności — build i review.
W Claude Code wystarczy wpisać: /loop 5min /build.
(Informacja dodatkowa: /loop to komenda uruchamiająca zadanie cyklicznie; wartość „5min” oznacza interwał co pięć minut.)
Komenda /loop mówi czatowi: „rób tę rzecz w kółko”. „5min” określa, jak często — czyli co pięć minut. A robi to, że uruchamia nasz nowy skill build, który buduje dowolny spec z backlogu w Linear — czyli te pięć zadań, które właśnie powstało. W praktyce agent siedzi w pętli przez cały dzień i buduje, buduje, buduje.
Umiejętność build to po prostu instrukcja mówiąca agentowi, jak czytać i realizować każde zadanie z Linear, jak przesuwać je dalej w naszym pipelinie, jak przekazać je do umiejętności review i jak utrzymać całą pętlę w ruchu, nawet gdy nie ma cię przy komputerze.
Krok 3: review — pętla, która testuje i przygotowuje pull requesty
W tym samym czasie ustawiamy pętlę recenzji. Otwieram drugi czat i robię to samo: /loop 5min /review.
Ta pętla recenzuje każdy zbudowany spec — każdy oznaczony jako „oczekujący”. Gdy agent kończy budować dane zadanie, nadaje mu etykietę „gotowe do recenzji”. Pętla review czeka na tę etykietę i zaczyna recenzować.
Umiejętność review instruuje agenta, jak: otworzyć zmianę w przeglądarce, przetestować ją, poklikać po interfejsie, nadać etykietę po zakończeniu, utworzyć własny pull request z tym konkretnym kodem, wrzucić ten PR do środowiska testowego (sandbox), żeby dało się przetestować tylko tę jedną zmianę, oraz napisać dla użytkownika instrukcję, jak samodzielnie ją sprawdzić.
Każdą z tych umiejętności buduje się bardzo prosto — jeden prompt. To tylko instrukcje mówiące AI, jak przepychać zadania przez pętlę i jak utrzymać całość w ruchu.
Tak więc jedne agenty autonomicznie budują zadania, a inne autonomicznie je recenzują. Gdy agent zrecenzuje zadanie, przetestuje je i uzna, że działa dobrze, wysyła pull request do wybranego komunikatora. U mnie to Slack. Możesz użyć Discorda albo Telegrama — Slack jest do tego typu workflow stworzony, ale w Discordzie też zadziała bez problemu.
Ostatni krok: emoji rakiety i merge
Mam kanał „merge ready”. Pętla review pisze do mnie tam: opisuje pull request, opisuje zadanie i to, co zrobiła, daje link, jeśli chcę sam przetestować. To coś jak gałąź podglądowa (preview branch) w Vercel — zawiera tylko jedną zmianę wprowadzoną przez agenta. Dostaję instrukcję krok po kroku, jak to przetestować, jeśli chcę.
(Informacja dodatkowa: Vercel to platforma hostingowa, która automatycznie tworzy podgląd każdej zmiany na osobnym adresie.)
Kiedy jestem gotowy, wystarczy, że zareaguję emoji rakiety. Agent odpowiada: „przyjąłem, scalam”, scala zmianę i stawia zielony znaczek: „gotowe, jest na żywo w aplikacji”.
I tyle. Rano wpadliśmy, odpowiedzieliśmy na pytania agenta, agent autonomicznie zbudował, zrecenzował i przetestował wszystko, a my na koniec tylko klikamy: rakieta, rakieta, rakieta — i całość jest scalona.
Wszystko za darmo, prompty w Google Doc
Pod filmem jest Google Doc z kilkoma promptami: do skonfigurowania każdej z trzech umiejętności oraz prompt, który podajesz agentowi (Claude, Codex, cokolwiek), żeby ustawił Slacka, Discorda, Linear i połączył cały system. Nie jest to schowane za mailem ani niczym — po prostu kopiujesz i wklejasz do agenta.
AI — szczególnie ze Stable 5 oraz GPT-5/6 — stało się tak inteligentne, że nie ma już potrzeby niańczenia każdego kroku.
(Informacja dodatkowa: autor odwołuje się do kolejnych generacji modeli; nazwy „Stable 5” i „GPT-5/6” padają jako jego skrótowe określenia najnowszych systemów.)
Właściwie każdy etap powinien być zautomatyzowany, a my wciąż robimy coś ręcznie. Pracuję teraz nad tym, żeby zautomatyzować nawet tę ręczną robotę — jak zautomatyzować wymyślanie pomysłów, żeby etap spec był jeszcze prostszy i mniej angażował człowieka. W miarę jak AI mądrzeje, być może nie będziemy nawet musieli sami scalać zmian — prawdopodobnie da się już zaufać agentowi, że zrobi to za nas. Ale na razie chcę zachować te dwa ręczne momenty: początek i koniec dnia. Cała ciężka praca w środku dnia jest już załatwiona.
Podsumowanie: sześć projektów naraz
Możesz pójść dalej: uruchom pięć czy sześć różnych projektów, rano rozpisz specyfikacje dla wszystkich sześciu, one pracują autonomicznie cały dzień, a wieczorem masz sześć projektów, które ruszyły do przodu bez twojej ciągłej obecności.
Wszyscy w internecie mówią o pętlach kodowania. Teraz już wiesz, jak je wdrożyć — a jeśli to zrobisz, będziesz przed niemal wszystkimi. Nawet najbardziej zaawansowani vibe coderzy nie ustawiają takich pętli. Zablokuj sobie pół godziny, przejdź materiał jeszcze raz, weź prompty spod filmu i skonfiguruj to. Jeszcze prościej: skopiuj link do tego filmu, podaj go agentowi i powiedz: „spójrz na transkrypt tego filmu i ustaw mi to”. To pewnie najłatwiejszy sposób, żeby to uruchomić.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przejdź od promptowania do pętli
Na czym polega: Zamiast ręcznie wysyłać kolejne prompty i testować wyniki, budujesz pętlę, w której agent sam buduje, recenzuje i testuje zadania przez cały dzień. Wąskim gardłem przestaje być człowiek.
Jak stosować: Wydziel powtarzalny cykl pracy (buduj → recenzuj → testuj) i zamień go w automat uruchamiany komendą typu /loop. Twój wkład ogranicz do dwóch momentów dnia: podania pomysłów i zatwierdzenia scaleń.
Na co uważać: Pętla jest tak dobra, jak instrukcje, które w niej zaszyjesz. Bez precyzyjnych kryteriów akceptacji i testów agent może „autonomicznie” produkować kod, który przechodzi jego własną recenzję, ale nie spełnia twoich oczekiwań.
2.Rozbij pętlę na trzy umiejętności: spec, build, review
Na czym polega: Cała pętla to trzy oddzielne skille o jasno rozdzielonych rolach — spec zbiera wymagania, build realizuje, review testuje i przygotowuje PR.
Jak stosować: Zbuduj każdy skill osobno, jednym promptem, i sprawdź je pojedynczo, zanim spięsz je w pętlę. Rozdzielenie ról ułatwia debugowanie, gdy coś pójdzie nie tak.
Na co uważać: Granice między krokami muszą być czytelne (etykiety statusów w narzędziu do zadań), inaczej build i review będą się nawzajem blokować albo dublować pracę.
3.Zacznij od dobrego spec — to jedyna praca, która naprawdę wymaga ciebie
Na czym polega: Skill spec przeprowadza z tobą wywiad (u autora ok. 15 pytań), aż zrozumie pomysł, i dopiero wtedy generuje szczegółowe zadania z kryteriami akceptacji, zakresem i „non-goals”.
Jak stosować: Poświęć czas na etap spec — to on decyduje o jakości całej reszty. Wymagaj od skilla, by dopytywał aż do pełnego zrozumienia, i zawsze dodawaj „non-goals”, by ograniczyć rozjazd zakresu.
Na co uważać: Jeśli odpowiesz na pytania pobieżnie, agent zbuduje szczegółowo… niewłaściwą rzecz. Śmieci na wejściu = śmieci na wyjściu, tyle że w większej skali.
4.Użyj systemu zadań jako „drugiego mózgu” agenta
Na czym polega: Autor trzyma wszystkie zadania w Linear, dzięki czemu agenty pamiętają stan prac i mogą wznawiać go po restarcie lub przy uruchomieniu nowych instancji.
Jak stosować: Wybierz narzędzie z API i etykietami statusów (Linear, ale też GitHub Issues czy Jira). Zewnętrzny stan pozwala uruchamiać wiele agentów bez utraty kontekstu i bez zapychania okna kontekstowego głównego agenta.
Na co uważać: Uzależniasz pipeline od integracji z zewnętrzną usługą — sprawdź limity API i to, co się stanie, gdy dwa agenty spróbują zaktualizować to samo zadanie jednocześnie.
5.Uruchamiaj build i review jako osobne, równoległe pętle
Na czym polega: Autor odpala dwie pętle /loop 5min w osobnych czatach — jedna buduje z backlogu, druga recenzuje zadania oznaczone jako „gotowe do recenzji”.
Jak stosować: Rozdziel budowanie i recenzję na niezależne procesy komunikujące się przez etykiety statusów. Dzięki temu recenzja jednego zadania biegnie równolegle z budowaniem następnego.
Na co uważać: Interwał (np. 5 minut) i koszt tokenów rosną wraz z liczbą pętli i projektów. Kilka projektów naraz to również kilka razy większy rachunek za API — monitoruj zużycie.
6.Wymuś realne testowanie w przeglądarce, nie tylko „wygląda dobrze”
Na czym polega: Skill review otwiera zmianę w przeglądarce, klika po interfejsie, tworzy pull request i wrzuca go do środowiska sandbox, a także pisze instrukcję testowania dla człowieka.
Jak stosować: W instrukcji review jednoznacznie każ agentowi uruchomić aplikację i przejść przez ścieżki użytkownika, a nie tylko przeczytać kod. Środowisko podglądowe (np. preview branch w Vercel) pozwala testować pojedynczą zmianę w izolacji.
Na co uważać: Agent recenzujący własne dzieło bywa pobłażliwy. Warto zachować ludzki punkt kontrolny na zmiany krytyczne — automatyczna recenzja nie zastąpi testów bezpieczeństwa ani oceny ryzyka.
7.Zatwierdzanie sprowadź do jednego gestu — ale go zachowaj
Na czym polega: Gotowe PR-y trafiają na Slack (lub Discord/Telegram); reakcja emoji rakiety wyzwala merge, agent potwierdza scalenie zielonym znaczkiem.
Jak stosować: Zbuduj kanał powiadomień z krótkim opisem PR, linkiem do podglądu i instrukcją testu, a merge wyzwalaj prostym sygnałem. Ludzki „klik” to twój ostatni bezpiecznik przed produkcją.
Na co uważać: Autor sam sugeruje, że wkrótce można będzie zrezygnować z ręcznego merge. Nie rezygnuj z niego pochopnie — to jedyny moment, w którym człowiek widzi, co faktycznie trafia na żywo.
8.Traktuj pętlę jak mnożnik projektów, nie tylko przyspieszacz jednego
Na czym polega: Prawdziwa dźwignia pojawia się, gdy prowadzisz pięć–sześć projektów naraz: rano rozpisujesz specyfikacje dla wszystkich, a one posuwają się autonomicznie przez cały dzień.
Jak stosować: Gdy jedna pętla działa stabilnie, replikuj ją na kolejne projekty. Poranek przeznacz na batch specyfikacji, wieczór na batch merge’ów.
Na co uważać: Równoległość mnoży nie tylko produktywność, ale i chaos — bez dyscypliny w kryteriach akceptacji i przeglądzie skończysz z sześcioma backlogami wątpliwej jakości kodu.
9.Setup jest agnostyczny narzędziowo i oparty na darmowych klockach
Na czym polega: Pętla działa z Claude Code, Codeksem lub dowolnym narzędziem obsługującym własne skille; potrzebne komponenty (Linear, Slack/Discord) mają darmowe plany, a autor udostępnia gotowe prompty w Google Doc.
Jak stosować: Możesz podać agentowi prompty (lub sam transkrypt filmu) i pozwolić mu skonfigurować integracje. Zacznij od jednego stacku, który już znasz, zamiast wdrażać wszystkie narzędzia naraz.
Na co uważać: „Za darmo” ma granice — darmowe plany mają limity, a koszty przenoszą się na tokeny modelu. Prompty od zewnętrznego autora traktuj jako punkt startu do przejrzenia, nie jako czarną skrzynkę.
10.Zachowaj krytyczny dystans do marketingowej ramy
Na czym polega: Materiał jest entuzjastyczny („95% pracy zautomatyzowane”, „przed 99,99% ludzi”) i zawiera fragment sponsorski oraz obietnicę zwrotu pieniędzy — to poradnik-perswazja, nie neutralna analiza.
Jak stosować: Wyłuskaj z niego architekturę (spec → build → review + system zadań + kanał zatwierdzeń), którą można zbudować niezależnie od konkretnych marek i promptów autora.
Na co uważać: Deklaracja „koniec promptowania” jest przesadzona — pętle to nadal prompty, tyle że zaszyte w skillach i wywoływane cyklicznie. Jakość promptu w spec, build i review pozostaje decydująca.