O czym jest ten film
- Autor twierdzi, że dowiózł ponad 75 pull requestów, korzystając z modelu Fable 5 i systemu „pętli” (loops) sterujących agentami chmurowymi.
- Cały proces zaczyna się od opisania funkcji lub błędu w Linear — to źródło kontekstu i, co ważniejsze, definicja stanu docelowego.
- Z Linear przez integrację MCP zadanie trafia do agenta chmurowego (Cursor Cloud lub Devon), który ma dostęp do wirtualnego pulpitu.
- Pierwsza pętla: agent pisze kod, uruchamia aplikację, testuje ją przez computer use i nagrywa wideo — pętli, dopóki nie osiągnie sukcesu potwierdzonego nagraniem.
- Kluczem do taniej i skutecznej pętli jest jasne, jednoznaczne kryterium sukcesu — tu zdefiniowane w tickecie i weryfikowane wizualnie przez agenta.
- Po sukcesie agent tworzy PR w GitHubie i dołącza do niego wideo demonstrujące działanie poprawki.
- Druga pętla: agent czeka na ocenę od narzędzia code review (Greptile) i poprawia kod, dopóki nie dostanie pełnej oceny 5/5.
- Dopiero po 5/5 PR trafia do przeglądu człowieka — autor sprawdza wideo i sygnatury funkcji, nie czyta całego kodu.
- Rada praktyczna: zanim zautomatyzujesz pętlę w skill, przejdź wszystkie kroki ręcznie, by wiedzieć, co dokładnie automatyzujesz.
- Film zawiera wstawki sponsorskie (Framer Agent) i element autopromocji, ale rdzeń to konkretny, powtarzalny workflow.
Redakcyjne tłumaczenie
Punkt wyjścia: 75 PR-ów i dwie pętle
Dowiozłem ponad 75 pull requestów, korzystając z Fable 5 i pętli. Minęło osiem dni, odkąd Fable 5 w końcu do nas wrócił — dzięki Bogu — a dostępność została jeszcze przedłużona. Model wrócił 1 lipca, a 7 lipca przedłużono go do 12 lipca. Smutne jest tylko to, że wyczerpałem swoje tygodniowe limity: albo czekam 17 godzin na reset, albo biorę nową subskrypcję.
(Informacja dodatkowa: „Fable 5” to nazwa modelu językowego wykorzystywanego przez autora; opisywana czasowa dostępność i limity to realia korzystania z modeli premium.)
W tym materiale pokażę, jak dowiozłem te ponad 75 PR-ów, i rozłożę na czynniki pierwsze całą pętlę — a właściwie pętle — których do tego użyłem. Początkowo nie byłem wielkim entuzjastą pętli, zwłaszcza w sposobie, w jaki je tłumaczono. Ale po zbudowaniu własnych pętli w obszarach, które mają sens, i połączeniu ich z innymi, mam wreszcie workflow, w którym mogę dosłownie iść spać z zdefiniowaną pętlą, a rano obudzić się z gotowym do wdrożenia PR-em. Rozłożę to w najdrobniejszych szczegółach: pokażę narzędzia, wyjaśnię logikę pętli, a nawet pokażę funkcje, które w ten sposób zbudowaliśmy.
Krok pierwszy: opis funkcji lub błędu w Linear
Początek pętli to opisanie funkcji. Używam do tego platformy, w której umieszczam nie tylko prośby o nowe funkcje, ale też zgłoszenia błędów — a jest to Linear. Niektórzy pytali, czemu nie korzystam z GitHub Issues; dlatego, że to GitHub. Linear służy mi za miejsce, gdzie zapisuję prośby o funkcje i raporty o błędach.
Dobry przykład: mam tu zgłoszenie błędu — migotanie interfejsu między łączeniem z ChatGPT a oczekiwaniem na odpowiedź podczas nawiązywania połączenia z dostawcą modelu. Widzę podsumowanie, kroki reprodukcji (to będzie ważne później), oczekiwane zachowanie, faktyczne zachowanie, analizę wpływu i sugerowane kolejne kroki. Tego akurat nie pisałem ja — pisał mój wspólnik Muso, zapewne z pomocą AI, i jest to świetnie zrobione. To jest punkt startowy: Linear to miejsce, gdzie zapisujemy prośby o funkcje i błędy.
Przekazanie zadania agentowi chmurowemu
Dzięki MCP możemy przypisać agenta do konkretnej funkcji lub błędu. W tym przypadku używam Cursor Cloud albo Devona. Robię to dlatego, że potrzebuję agenta chmurowego, a potrzebuję go, bo chcę, żeby agent miał pełny dostęp do komputera. Dzięki temu może nie tylko odtworzyć błąd, ale też go naprawić, nagrać wideo z naprawy, przetestować i wystawić PR. Żeby zrobić to autonomicznie i nie zajechać własnego komputera, potrzebuję chmury. Kupiłem nawet mini-PC, żeby zbudować własną chmurę w domu — ale to temat na osobny film.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard łączenia agentów AI z zewnętrznymi narzędziami, tutaj z Linearem. Devon i Cursor Cloud to agenty programistyczne działające w chmurze, z dostępem do wirtualnego pulpitu.)
W praktyce wygląda to tak: w tickecie klikam swoje nazwisko i przypisuję zadanie agentowi — na przykład Cursorowi. Widzę wtedy, że Cursor rozpoczął analizę zgłoszenia i pracuje. Na dashboardzie Cursora widać, że agent podjął ticket z Linear i zaczyna nad nim pracować. Wszystko dzieje się w chmurze — mogę zamknąć kartę, zamknąć laptopa, robić cokolwiek. To jest pierwsza część procesu; nie doszliśmy jeszcze do właściwej pętli, ale faza budowy się zaczęła.
Pętla numer jeden: budowa i weryfikacja przez computer use
Chcę, żebyście nie kopiowali mojej pętli słowo w słowo — chcę, żebyście zrozumieli sposób myślenia i mechanikę.
Agent chmurowy zaczyna pracę nad ticketem, niezależnie od tego, czy to nowa funkcja, czy błąd. Pisze kod, planuje, myśli. Kiedy skończy, zaczyna się pętla: agent sięga po computer use, czyli korzysta z pulpitu. Zaletą Cursor Cloud i Devona jest to, że oba mają dostęp do wirtualnego komputera — mogą uruchomić moją aplikację i przetestować ją tak, jak zrobiłby to człowiek.
Chcę więc, żeby po napisaniu kodu agent użył computer use i faktycznie przetestował poprawkę. Przykład z Devona: nagranie, na którym testuje konektory. Chcieliśmy, żeby użytkownicy mogli wybierać różne uprawnienia. Na wideo widać, jak agent tworzy nowy arkusz Google przy użyciu podłączonego konta — i to robi. Potem wraca do konektorów i sprawdza uprawnienia. Uprawnienie do tworzenia arkusza było ustawione na „zawsze zezwalaj”. Widać więc, że funkcja zarządzania uprawnieniami zadziałała — a sposób, w jaki to potwierdziłem, to nagranie z computer use pokazujące test funkcji.
Najciekawsze w tej pętli nie jest to, gdy wszystko działa, lecz gdy coś się psuje. Przy pierwszym uruchomieniu tej samej funkcji agent zrobił to źle. Na nagraniu widać, jak ustawia uprawnienia konektora na „zawsze zezwalaj” — czyli gdy użytkownik o coś prosi, powinno się to po prostu wykonać. A jednak aplikacja i tak zapytała o zgodę. Agent Devona oznaczył to jako porażkę.
I o to chodzi: computer use w połączeniu z agentem chmurowym i możliwością nagrywania sprawia, że mogę kazać agentowi pętlić się, dopóki nie osiągnie stanu docelowego — dopóki nie powstanie wideo pokazujące, że agent naprawdę zrobił to, o co prosiłem. Pętla ma teraz sens: agent buduje, testuje przez computer use, ewaluuje, sprawdza, czy stan docelowy został osiągnięty. Agent ma kontekst z ticketu — wie, jakie jest oczekiwane, a jakie faktyczne zachowanie. Więc pętlimy dalej: sprawdził „zawsze zezwalaj”, nie zadziałało, oddaj z powrotem agentowi, agent pisze kod, testuje ponownie, nie działa, znów pisze, znów testuje. Kiedy pętla się domknie, przechodzimy do następnego kroku.
Dlaczego ta pętla nie przepala tokenów
Żeby pętla była skuteczna i nie spaliła twoich subskrypcji i tokenów, kryterium ewaluacji musi być jasne i jednoznaczne. Tutaj jest zdefiniowane w tickecie, a dodatkowo agent korzysta z computer use — więc naprawdę widzi: „miałem naprawić streaming czatu, a streaming nie działa”. Dlatego ta pętla jest niezawodna: pętla zwrotna, stan sukcesu i stan docelowy są łatwe do sprawdzenia, łatwe do zidentyfikowania i łatwe do opisania. Mam je w tickecie w Linear, a computer use to potwierdza.
Kolejny przykład: chciałem zbudować nowy onboarding, w którym ludzie tworzą wirtualne karty dla swoich agentów. Kiedy było gotowe, kazałem agentowi nagrać wideo — i powstało nagranie tworzenia karty agenta, pokazujące cały przepływ onboardingu oraz istniejące karty. To udany przebieg. Da się to zrobić tylko z agentami chmurowymi, bo robienie tego na własnej maszynie — o ile nie masz naprawdę mocnego sprzętu — zajedzie komputer.
Pętla numer dwa: code review aż do 5/5
Kiedy przejdziemy ten etap, agent tworzy pull request. Wszystko robię w GitHubie. Do PR-a dołącza wideo. Mam przykład zmergowanego PR-a z filmami pokazującymi stan sukcesu — więc przeglądając PR, dostaję nagranie poprawki w działaniu. To dla mnie duże ułatwienie: przegląd nabiera sensu.
Ale mimo że wideo działa, nadal używam agenta do code review — i tu zaczyna się druga pętla. Po utworzeniu PR-a agent czeka na recenzję. Narzędziem, którego używam, jest Greptile. Uwielbiam je, bo ma skill /gp loop, który pozwala agentowi pętlić się względem otrzymanego feedbacku aż do perfekcyjnej oceny.
(Informacja dodatkowa: Greptile to narzędzie do zautomatyzowanego przeglądu kodu w PR-ach na GitHubie; wystawia ocenę i komentarze. W transkrypcji nazwa pada w wielu zniekształconych formach — „GPile”, „Grapile”, „Gretile”.)
Na przykładzie zmergowanego PR-a widać ocenę pewności 5/5. Czasem agent dostaje 4/5. Z Fable jest to zawsze 4/5 albo 5/5, ale przy GPT-5.5 czy Opus 4.8 możesz dostać 3/5 lub 4/5. Skill GP Loop mówi agentowi: poczekaj na recenzję PR-a od Greptile; kiedy ją dostaniesz, jeśli to 3/5 lub 4/5, przeczytaj feedback i komentarze, wprowadź poprawki, wypchnij zmiany do PR-a i znów czekaj na recenzję.
Na tym polega pętla numer dwa: czekam na ocenę agenta review. Jeśli jest poniżej 5/5, agent poprawia kod i wysyła ponownie, czeka na nowy wynik. Jeśli znów poniżej — poprawia i wypycha. Poprawia i wypycha. Kiedy ocena osiąga 5/5, wychodzimy z pętli. I dopiero wtedy PR jest gotowy do przeglądu przez człowieka.
Dwie pętle, jedna „master loop”
Choć mówię o jednej wielkiej pętli, to w istocie połączenie dwóch. Pierwsza odpowiada za stworzenie funkcji lub naprawę błędu; feedbackiem potrzebnym do wyjścia z niej jest computer use — agent musi użyć komputera i doświadczyć sukcesu (działająca funkcja albo naprawiony błąd). Druga pętla to wypchnięcie do GitHuba, utworzenie PR-a i oczekiwanie na ocenę Greptile; jeśli poniżej 5/5, pętlimy, agent adresuje feedback, aż do 5/5. Dopiero wtedy PR jest gotowy do recenzji.
Zauważcie, że wciąż jestem w tym procesie — tam, gdzie opisuję funkcję i dbam, żeby wszystko było zrobione jak trzeba. Mój przegląd to obejrzenie całego PR-a i wideo; mogę spojrzeć na sygnatury funkcji, ale nie czytam całego kodu.
Rada: najpierw zbuduj pętlę ręcznie
Żeby zbudować to porządnie, na początku musisz być zaangażowany na każdym kroku. Przykład: błąd „strumień czatu i wywoływanie konektorów są wolne i się psują”. Opis trafił do Linear, agent go przeczytał, zaproponował plan, a ja poprosiłem, żeby odtworzył błąd i sam go doświadczył — więc dokładnie odtworzył sytuację. Musiał się zalogować, a zablokowało go 2FA; dałem mu dostęp do 2FA i dokończył reprodukcję, dostałem nagranie. Widać, że streaming nie działa — cały blok tekstu pojawia się naraz.
(Informacja dodatkowa: 2FA to uwierzytelnianie dwuskładnikowe; agent chmurowy potrzebował od autora kodu, by zalogować się do aplikacji podczas testu.)
Kazałem odtworzyć błąd, żeby agent go dobrze zrozumiał, a potem zapytałem, dlaczego tekst nie jest strumieniowany. Wyjaśnił problem, powiedziałem, że streaming musi działać, i poprosiłem o plan naprawy. Powstał plan, agent wykrył przy okazji inny problem, kazałem go zbadać, zidentyfikował go i naprawił. Kiedy skończył, poprosiłem o nagranie pokazujące naprawiony błąd — i na wideo widać, że po wpisaniu promptu streaming działa.
Pokazuję to, bo zanim zamieniłem ten proces w pętlę i w skill (nazwałem go „testing Pluto PRs”), zbudowałem tę pętlę ręcznie — sam, krok po kroku. Jeśli planujesz zbudować podobną pętlę, najpierw przejdź każdy etap samodzielnie: napisz opis, podłącz narzędzie MCP, spraw, żeby agent podjął zadanie. Kiedy powstanie wersja pierwsza, powiedz: „Przetestuj to przez computer use i przyślij mi nagranie udanego przebiegu. Jeśli się nie uda, buduj dalej, aż będzie udany. Nie przerywaj, dopóki nie masz udanego przebiegu i nagrania”. I już — masz swoją pierwszą pętlę.
Potem dokładasz część z PR-em: „Wypchnij do GitHuba, uruchom Greptile, utwórz PR”. PR powstaje, Greptile działa i daje 3/5 lub 4/5. Wtedy mówisz agentowi: „Użyj skilla GP Loop” — możesz go pobrać z internetu — i doprowadź do 5/5. Przejrzysz wszystko, wypchniesz, i masz pętlę produkującą kod produkcyjny.
Solidność pętli — gdzie można zatrzymać błąd
Rzecz w tym, że jest wiele miejsc, w których można zatrzymać coś, co poszło źle. W pierwszej pętli, jeśli nagranie jest złe, bo agent zahalucynował — możesz to zatrzymać. Jeśli nie ma 5/5, PR się nie merguje — też możesz to zatrzymać. Wierzę, że zbudowałem solidną pętlę — nazwijmy ją master loop — złożoną z dwóch pętli. To ona pozwoliła mi dowieźć ponad 75 PR-ów przy użyciu Fable 5. Uważam, że to właśnie Fable 5 sprawia, że działa; pewnie zadziałałoby też z GPT-5.5, oby doczekać się GPT-5.6.
To jest moja pętla i tak dowożę kod z Fable 5. Wkrótce pokażę projekty, które zbudowałem, oraz jak to zrobiłem, a także osobny film o agentach chmurowych. Zbliżamy się do 100 tysięcy subskrybentów. Dzięki za oglądanie. Nazywam się Ross, do zobaczenia następnym razem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Master loop = pętla budowy + pętla review
Na czym polega: Cały workflow to złożenie dwóch niezależnych pętli. Pierwsza doprowadza funkcję/naprawę do stanu działającego (kryterium: udane nagranie z computer use), druga doprowadza kod do jakości akceptowalnej w code review (kryterium: ocena 5/5).
Jak stosować: Rozdziel „czy to działa” od „czy kod jest dobry” na dwa osobne etapy z osobnymi kryteriami wyjścia. Nie mieszaj ich w jednym promptcie — każdy etap ma inny sygnał sukcesu.
Na co uważać: Bez jasnego kryterium wyjścia pętla może kręcić się w nieskończoność i przepalać tokeny. Oba kryteria muszą być binarne i sprawdzalne.
2.Kryterium sukcesu definiuj w tickecie, zanim ruszy agent
Na czym polega: Skuteczność pętli zależy od tego, czy stan docelowy jest jasny. Autor zapisuje oczekiwane i faktyczne zachowanie oraz kroki reprodukcji w Linear — to staje się „prawdą”, względem której agent się ewaluuje.
Jak stosować: Zanim przypiszesz zadanie agentowi, opisz oczekiwane zachowanie, faktyczne zachowanie i kroki reprodukcji. Użyj AI do dopracowania opisu — sam autor przyznaje, że ręcznie pisane tickety są słabe.
Na co uważać: Nieostry opis („napraw czat”) daje nieostrą ewaluację i pętlę bez końca. Im bardziej mierzalny stan docelowy, tym taniej i pewniej działa pętla.
3.Computer use jako weryfikacja, nie deklaracja
Na czym polega: Agent nie „twierdzi”, że naprawił — uruchamia aplikację na wirtualnym pulpicie, wykonuje scenariusz i nagrywa wideo. Sukcesem jest zaobserwowane działanie, nie zakończony bez błędu build.
Jak stosować: Każ agentowi odtworzyć błąd przed naprawą i nagrać dowód po naprawie. Nagranie służy zarówno jako sygnał wyjścia z pętli, jak i materiał do twojego przeglądu.
Na co uważać: Nagranie może być zahalucynowane lub testować nie to, co trzeba — to jeden z punktów, w których musisz sam zatrzymać zły przebieg. Wideo nie zwalnia z przeglądu.
4.Agenty chmurowe zamiast lokalnej maszyny
Na czym polega: Sensowne testowanie przez computer use w pętli wymaga pełnego dostępu do komputera i obciąża sprzęt. Autor używa Cursor Cloud lub Devona, bo mają wirtualny pulpit i nie zajeżdżają lokalnej maszyny.
Jak stosować: Do autonomicznych pętli z realnym uruchamianiem aplikacji wybieraj agenty chmurowe z dostępem do pulpitu. Dzięki temu możesz „iść spać z pętlą i obudzić się z PR-em”.
Na co uważać: To wiąże się z kosztem subskrypcji i limitami (autor sam wyczerpał tygodniowy limit). Rozdziel autonomię od kosztu — im dłuższa pętla, tym większe zużycie.
5.Druga pętla: code review aż do pełnej oceny
Na czym polega: Po utworzeniu PR-a agent czeka na recenzję Greptile i poprawia kod, dopóki nie osiągnie 5/5. Służy do tego skill GP Loop, który steruje cyklem: przeczytaj feedback → popraw → wypchnij → czekaj na nowy wynik.
Jak stosować: Podłącz automatyczny code review do PR-ów i ustaw próg jakości (np. 5/5) jako warunek merge’a. Niech agent samodzielnie adresuje komentarze recenzenta.
Na co uważać: Ocena zależy od modelu — Fable dawał 4–5/5, słabsze modele 3–4/5. Nie traktuj samej liczby jako gwarancji; 5/5 od automatu to nie to samo co przegląd człowieka.
6.Człowiek zostaje w pętli — ale wyżej
Na czym polega: Autor nie znika z procesu: opisuje funkcje i robi finalny przegląd (wideo + sygnatury funkcji), ale nie czyta całego kodu linijka po linijce.
Jak stosować: Przesuń swój wkład na początek (precyzyjny opis) i koniec (przegląd dowodów), oddając środek agentom. Skup uwagę tam, gdzie decydujesz o kierunku i akceptacji.
Na co uważać: Rezygnacja z czytania całego kodu to realne ryzyko — działa tylko przy silnym code review i wiarygodnych nagraniach. Nie skaluj tego na kod krytyczny bez dodatkowych zabezpieczeń.
7.Najpierw zbuduj pętlę ręcznie, potem ją zautomatyzuj
Na czym polega: Zanim autor zamienił proces w skill („testing Pluto PRs”), przeszedł wszystkie kroki manualnie, prowadząc agenta za rękę.
Jak stosować: Przy nowej pętli najpierw przejdź cykl ręcznie: opis → podłączenie MCP → pierwsza wersja → prośba o test i nagranie → część z PR-em i review. Dopiero sprawdzoną sekwencję zamień w skill.
Na co uważać: Automatyzacja procesu, którego sam nie rozumiesz, utrwala jego błędy. Skill jest tak dobry, jak ręczny przepływ, na którym go oparłeś.
8.Wiele punktów zatrzymania błędu (defensywny projekt)
Na czym polega: Pętla ma świadome „bramki”: złe/zahalucynowane nagranie zatrzymuje pierwszą pętlę, brak 5/5 blokuje merge w drugiej. To czyni master loop odpornym.
Jak stosować: Projektując autonomiczny workflow, wpisz w niego jawne warunki blokady, które nie przepuszczą wadliwego wyniku dalej. Każdy etap powinien mieć swój „stop”.
Na co uważać: Bramki działają tylko, jeśli ich kryteria są rygorystyczne. Zbyt luźne progi (np. akceptacja 3/5) przepuszczą słaby kod mimo pozornej kontroli.
9.Linear + MCP jako punkt startowy zadań
Na czym polega: Autor używa Linear do zbierania próśb o funkcje i błędów, a przez integrację MCP przypisuje zadanie agentowi chmurowemu wprost z ticketu.
Jak stosować: Zbuduj most między systemem zgłoszeń a agentem (tu: Linear → MCP → Cursor/Devon), by praca startowała jednym przypisaniem, a agent miał od razu pełny kontekst.
Na co uważać: To wybór narzędziowy, nie dogmat — działa, bo ticket niesie ustrukturyzowany kontekst. Sam Linear bez dobrego opisu i integracji nie da przewagi.
10.Wynik zależy od jakości modelu — nie tylko od pętli
Na czym polega: Autor przypisuje sukces (ponad 75 PR-ów) głównie modelowi Fable 5, zaznaczając, że słabsze modele dają niższe oceny w review. Pętla to rusztowanie, ale silnik ma znaczenie.
Jak stosować: Traktuj wybór modelu jako zmienną wpływającą na to, ile iteracji potrzeba do 5/5. Mocniejszy model skraca pętle i obniża realny koszt mimo wyższej ceny za token.
Na co uważać: To relacja jednego twórcy, nie zmierzony benchmark, plus film zawiera treści sponsorowane (Framer). Zweryfikuj liczby na własnym, mniej entuzjastycznym przypadku, zanim oprzesz na tym proces produkcyjny.