Ralph Loop, czyli jak puścić AI w pętli i pójść spać
Jakiś czas temu trafiłem na coś, co zmieniło moje myślenie o tym, jak można pracować z Claude Code. Nazywa się Ralph Loop i jest pluginem, który robi jedną prostą rzecz: pozwala AI pracować nad zadaniem w pętli, iteracyjnie, aż do skutku. Albo do limitu iteracji, żeby nie wyczerpać abonamentu czy tokenów.
Skąd się wziął pomysł
Ralph Loop to implementacja tzw. Ralph Wiggum technique, nazwanej od postaci z Simpsonów. Spopularyzował ją Geoffrey Huntley i sprowadza się do absurdalnie prostego pomysłu:
while true; do
cat PROMPT.md | claude
done
Czyli: daj AI prompt, niech spróbuje. Jak się nie uda, niech spróbuje ponownie. I ponownie. I ponownie.
Na pierwszy rzut oka wygląda to prymitywnie. Ale działa, bo modele językowe naprawdę dobrze radzą sobie z iteracyjnym poprawianiem własnych błędów, pod warunkiem że widzą, co zrobiły wcześniej i dostają jakiś feedback. Huntley ujął to tak: lepiej failować przewidywalnie niż osiągać sukces w nieprzewidywalny sposób.
Jak to działa technicznie
Plugin implementuje ten mechanizm wewnątrz Claude Code przy użyciu tzw. stop hooka. To funkcja, która przechwytuje moment, w którym Claude chce zakończyć sesję. Zamiast pozwolić mu wyjść, hook blokuje exit i ponownie wstrzykuje ten sam prompt. Workflow wygląda tak:
- Uruchamiasz komendę z promptem.
- Claude pracuje nad zadaniem.
- Claude próbuje zakończyć sesję.
- Stop hook przechwytuje exit i sprawdza, czy w odpowiedzi pojawił się ustalony sygnał zakończenia.
- Jeśli nie, ten sam prompt jest podawany ponownie.
- Claude widzi swoje poprzednie zmiany w repo i poprawia błędy.
- Powtarza, aż spełni warunek zakończenia albo wyczerpie limit iteracji.
Kluczowe jest to, że kod pozostaje w repozytorium między iteracjami. Git history działa jak pamięć modelu. Claude widzi, co zrobił w poprzednim podejściu i może się z tego uczyć. Pętla działa wewnątrz bieżącej sesji Claude Code, nie potrzebujesz zewnętrznego bash loopa.
Instalacja i konfiguracja
Plugin ralph-wiggum jest dostępny w oficjalnym marketplace pluginów Claude Code. Instalacja to dwie komendy wpisane bezpośrednio w terminalu Claude Code:
/plugin marketplace add anthropics/claude-code
/plugin install ralph-wiggum@claude-plugins-official
Pierwsza dodaje oficjalne repozytorium pluginów Anthropic. Druga instaluje sam plugin. Po instalacji dostępne są dwie nowe komendy: /ralph-loop do uruchamiania pętli i /cancel-ralph do jej przerywania.
Jak używać Ralph Loop
Podstawowa komenda składa się z trzech elementów: opisu zadania, limitu iteracji i frazy zakończenia:
/ralph-loop "Twoje zadanie" \
--max-iterations 20 \
--completion-promise "DONE"
Parametr --completion-promise to fraza, którą Claude musi wypisać, żeby pętla uznała zadanie za zakończone. Ważna rzecz: to jest exact string matching, więc nie można zdefiniować kilku różnych fraz zakończenia. Dlatego --max-iterations jest tak naprawdę głównym zabezpieczeniem i należy go ustawiać zawsze, bo nigdy nie wiadomo, czy AI prawidłowo zinterpretuje nasze polecenia.
Dobry prompt powinien zawierać jasne kryteria sukcesu i explicite powiedzieć modelowi, co ma zrobić, gdy utknie. Na przykład:
/ralph-loop "Implement REST API for todos.
Requirements:
- CRUD endpoints working
- Input validation in place
- Tests passing with >80% coverage
- README with API docs
After 15 iterations, if not complete:
- Document what's blocking progress
- List what was attempted
- Suggest alternative approaches
Output DONE when complete." \
--max-iterations 20 \
--completion-promise "DONE"
Przerwać pętlę w dowolnym momencie można komendą /cancel-ralph albo zwykłym Ctrl+C.
Kiedy to ma sens
Najlepsze scenariusze to te, w których istnieje automatyczna walidacja. Testy, lint, build, CI, cokolwiek, co daje modelowi jednoznaczny feedback: działa albo nie działa.
Przykładem może być typowe wdrożenie funkcjonalności w TDD (Test-Driven Development, technika oparta na testach, w której najpierw piszesz testy, dopiero potem funkcjonalność), gdzie AI pisze kod, testy failują, AI poprawia, aż testy przejdą. Inny dobry przykład to refactoring i migracje frameworków. Możesz jasno określić kryteria sukcesu i AI będzie w stanie je zweryfikować.
Filozofia jest taka: zamiast prowadzić AI za rękę krok po kroku, definiujesz warunki sukcesu z góry i pozwalasz agentowi iterować w ich kierunku. Porażki stają się danymi. Każda iteracja poprawia podejście na podstawie tego, co się zepsuło.
Kiedy to nie działa
Nie jest to magiczne rozwiązanie. Są sytuacje, w których Ralph Loop po prostu się nie sprawdza. Gdy zadanie wymaga kreatywnych decyzji architektonicznych, a nie mechanicznego iterowania, albo specyfikacja jest niejasna i AI nie ma jak zwalidować, czy robi dobrze, to przepis na porażkę. AI nie dostanie automatycznego, klarownego feedbacku, więc model będzie kręcił się w pętli bez postępu albo wdroży coś, co tylko będzie udawało oczekiwany efekt końcowy.
Generalnie zasada jest prosta: jeśli nie potrafisz opisać warunku sukcesu w sposób, który da się sprawdzić automatycznie, Ralph Loop nie będzie działał dobrze.
Moje doświadczenie: Ralph Loop i metoda BMad
Teoria teorią, ale chcę opowiedzieć o tym, jak sam użyłem Ralph Loop na istniejącym projekcie. I dlaczego uważam, że to nie plugin jest tu kluczowy, a to, co mu dasz na wejściu.
Stosuję metodę BMad (Build More Architect Dreams), o której pisałem osobno na blogu. W skrócie: to uporządkowany proces prowadzenia projektu z AI, w którym zanim ktokolwiek zacznie kodować, przechodzisz przez fazy analizy, burzy mózgów czy planowania i dopiero potem implementacji. Każda faza kończy się dokumentacją w repozytorium: brief produktowy, PRD, projekt UX, architektura, epiki i stories z kryteriami akceptacji, na końcu jeszcze dodatkowa walidacja gotowości do implementacji.
Kiedy przeszedłem przez wszystkie te etapy BMad i miałem naprawdę szczegółowy plan wdrożenia, ze wszystkimi wymaganymi dokumentami, z epikami rozbitymi na stories, z kryteriami akceptacji dla każdego elementu i z zaprojektowaną architekturą, wtedy odpaliłem Ralph Loop.
Zostawiłem włączony komputer na noc. Ralph Loop brał kolejne stories z planu, implementował je, przechodził przez code review, poprawiał błędy, szedł dalej. Przez wszystkie epiki, przez wszystkie stories, przez cały cykl sprintowy, jaki zaprojektowałem w BMad.
Obudziłem się rano i aplikacja była gotowa. Przez całą noc agenci sami wszystko budowali, iterowali, poprawiali. I aplikacja działała! Nie "trochę", nie "może być", nie "na demo może być". To był naprawdę dobrej jakości kod.
To doświadczenie przekonało mnie o jednej rzeczy: Ralph Loop jest tak dobry, jak plan, który mu dajesz. Bez BMad, bez szczegółowej dokumentacji, bez przemyślanej architektury i jasnych kryteriów, ten sam plugin kręciłby się w kółko i spalał tokeny. Z dobrym planem potrafi naprawdę zrealizować overnight coding, o którym tak wielu marzy.
Praktyczne wskazówki
Z tego, co wyciągnąłem z community, blogów i własnego doświadczenia, kilka rzeczy się powtarza.
Prompt jest najważniejszy. To nie jest narzędzie, które myśli za ciebie. Community powtarza to jak mantrę: sukces zależy od pisania dobrych promptów, nie od samego modelu. Lepiej napisać dobrą dokumentację i prompt i skorzystać z tańszego i szybszego modelu, niż próbować stworzyć całą aplikację jednym promptem z nawet najmądrzejszym modelem. Im bardziej precyzyjne wymagania, checklista i warunki zakończenia, tym lepiej.
Zawsze ustawiaj max-iterations. Bez tego możesz zrobić nieskończoną pętlę. Completion promise opiera się na exact string matching i nie jest niezawodne, więc limit iteracji to twoje ostateczne zabezpieczenie.
Dziel zadania na fazy. Zamiast jednego promptu "zbuduj aplikację SaaS", lepiej rozbić to na etapy i uruchamiać osobny loop dla każdej fazy:
/ralph-loop "Phase 1: User authentication (JWT, tests).
Output PHASE1_DONE when complete." \
--max-iterations 20 \
--completion-promise "PHASE1_DONE"
Zawsze pracuj w katalogu z gitem. Jeśli coś pójdzie nie tak, możesz cofnąć zmiany. Każda iteracja zostawia ślad w historii commitów.
Zacznij bez guardrails. To rada prosto z dokumentacji pluginu: pozwól Ralph'owi najpierw spróbować, a potem dodawaj ograniczenia tam, gdzie failuje. Każdy fail uczy cię, jakie guardrails dodać do prompta.
Można jeszcze lepiej
Jest jedna istotna kwestia, którą podnoszą krytycy. Plugin działa w ramach jednej sesji, co oznacza, że context window rośnie z każdą iteracją. Po kilkunastu przejściach model może zacząć działać gorzej, bo kontekst jest za duży. To zjawisko nazywane jest context rot.
Oryginalna technika Ralpha (ten prosty bash loop) działa inaczej: każda iteracja to nowa sesja z czystym kontekstem, a stan jest zapisany w plikach i git history. Dzięki temu model zawsze operuje w optymalnym zakresie context window. Plugin jest wygodniejszy w użyciu, ale ta różnica może mieć znaczenie przy dłuższych zadaniach.
Istnieją też alternatywne implementacje, jak np. ralph-claude-code, które startują każdą iterację jako świeżą instancję z czystym kontekstem, a pamięć między iteracjami utrzymują przez pliki progress.txt i historię gita. Warto mieć to na uwadze, szczególnie przy zadaniach wymagających wielu dziesiątek iteracji.
Na koniec
Idea "daj specyfikację i wróć rano" jest kusząca. I z tego, co opisują ludzie w community, i z mojego własnego doświadczenia, naprawdę działa. Pod warunkiem, że zadanie jest dobrze zdefiniowane i ma automatyczną walidację. A jeszcze lepiej, jeśli wcześniej przejdziesz przez porządny proces planowania, taki jak BMad, który da agentowi pełny kontekst tego, co i jak ma budować.
Jeżeli chcesz lepiej poznać BMad i dowiedzieć się, jakie prompty stosuję w połączeniu BMad i Ralph Loop, zapraszam do kontaktu, opowiem Ci, jak szkolę zespoły programistyczne w wykorzystaniu AI w ich pracy.