Pętla Ralpha Wigguma, od podstaw

Jeżeli korzystałeś z agenta kodującego SI przez więcej niż kilka godzin, znasz „ścianę”: agent początkowo robi widoczne postępy, potem zatrzymuje się — i kończysz modyfikując i kończąc pracę sam.

Jak to często bywa u inżynierów AI, pojawił się wzorzec rozwiązujący ten problem: wystarczy zapętlić agenta z zewnętrznymi kontrolami, aż praca rzeczywiście zostanie wykonana.

Podejście przyjęło się na tyle mocno, że zyskało nazwę — Ralph Wiggum.

I ten mem przyjął się, ponieważ wzorzec działa. Pod koniec 2025 roku Anthropic sformalizowało to w oficjalną wtyczkę Claude Code.

Ralph reprezentuje zmianę w sposobie, w jaki programiści używają istniejących narzędzi. Zamiast traktować systemy AI jako interaktywne asystentki, są one uruchamiane jako długotrwałe procesy, kierowane przez testy, lintery i wyraźne warunki zakończenia.

Więc ten krótki przewodnik jest praktyczną wersją. Zobaczymy, czym tak naprawdę jest Ralph, dlaczego działa, jak się rozprzestrzenił i co się zmieniło, gdy został zkomercjalizowany.

Czym Jest Naprawdę „Ralph”?

W swojej istocie Ralph to działanie agenta w pętli, sprawdzanie wyników względem czegoś, co nie może kłamać, jak test, linter czy sprawdzacz typów; i kontynuowanie pętli, aż do uzyskania pozytywnego wyniku.

To wszystko.

Oryginalny przykład, który Geoffrey Huntley udostępnił w lipcu 2025 roku, był celowo bezpośredni:

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

Claude warianty kodu mają taki sam kształt, tylko z większą liczbą ograniczeń. Ale zasada się nie zmienia: wprowadzaj do agenta przytwierdzone polecenie wielokrotnie, aż rzeczywistość zewnętrzna powie, że to wszystko.

Sama pętla jest prawie nieistotna, a liczy się umowa:

• Stan znajduje się w repozytorium: Pliki, różnice, dzienniki, historia git; wszystko, co trwałe, znajduje się tutaj.
• Kompletność znajduje się poza modelem: Testy, lintery, sprawdzacze typów; agent nie decyduje, kiedy skończy; o tym decyduje otoczenie.
• Agent jest wymienialny: To pracownik wywoływany wielokrotnie, aż do przejścia przez bramkę; jeśli dzisiaj jest wolny lub głupi, jutro zamień go na coś szybszego.

Patrząc w ten sposób, Ralph staje się zasadą projektowania: przestań oczekiwać od modelu wiedzy, kiedy skończył. Przestań oczekiwać, że będzie pamiętał ograniczenia po resecie kontekstu.

Zamiast tego zbuduj system tak, aby model nie mógł zawieść w tych kwestiach.

Dlaczego Pętla Się Utrzymuje?

Kilka powodów:

1. Okna Kontekstowe Zachowują Się Jak Bufory

Huntley często przedstawia okna kontekstowe w niskopoziomowych terminach:

„Myśl jak inżynier C lub C++. Okna kontekstowe to tablice.”

Mają stały rozmiar; przesuwają się; nadpisują; zapominają.

Długotrwałe sesje zakładają ciągłość, która nie istnieje, dlatego traktowanie bufora jako trwałej pamięci prowadzi do dryfu, pomijania ograniczeń i niespójnego zachowania.

Ralph przyjmuje rzeczywistość systemu. Zamiast udawać, że okno kontekstowe jest stabilne, traktuje je jako jednorazowe.

Przestrzeń robocza agenta jest resetowana między iteracjami, podczas gdy trwały stan zachowuje się na dysku. Repozytorium akumuluje prawdę w trakcie kolejnych uruchomień. To sprawia, że restartowanie agenta jest rutynowe, a nie marnotrawne; każda pętla zaczyna się od nowa, ale buduje na tym, co faktycznie się zachowało.

2. Kontrole Zewnętrzne Przewyższają Wewnętrzne Rozumowanie

Wiele frameworków agenta reaguje na awarię poprzez dodanie struktury wewnątrz modelu: planistów, podsumowań, stanu wewnętrznego i pętli refleksyjnych.

Ralph przechowuje inteligencję poza agentem. Opiera się na:

• Przypięta specyfikacja, która się nie zmienia
• Konkretne dowody z ostatniego uruchomienia
• Deterministyczna bramka oceniająca sukces

Agent nie decyduje, kiedy praca jest zakończona – robi to uprząż.

Dlatego Ralph odnosi sukcesy w pracy mechanicznej: refaktoryzacje, migracje, porządkowanie, zadania zgodności… Wszędzie tam, gdzie sukces można zmierzyć skryptem, a nie osądem, iteracja staje się niezawodna.

Model nie może uciec od wymagań, ponieważ wymagania istnieją na zewnątrz jego rozumowania.

3. Kompaktowanie Erozuje Ograniczenia

Jedna powtarzająca się krytyka ze strony Huntleya dotyczy streszczenia i kompaktowania.

Kiedy system prosi model, by zdecydował, co jest na tyle ważne, aby zachować, informacje giną — ograniczenia stają się mniej rygorystyczne, nietypowe przypadki znikają, a pinezki wypadają.

Ralph omija to, zachowując dosłowność danych wejściowych:

• Specyfikacje pozostają dosłowne zamiast być podsumowane, 
• Informacje o błędach są prezentowane surowo i bez filtrów; oraz 
• Kuracja pamięci nigdy nie przenosi się do modelu.

Uprząż zachowuje wierność; agent działa w jej obrębie, ograniczony przez to, co faktycznie istnieje, a nie przez to, co model uważa, że powinno być.

Więc, Jak Rozprzestrzenił Się Pomysł?

Harmonogram jest dość napięty.

• 19 Czerwca 2025: Na spotkaniu w San Francisco, w którym uczestniczyło około 15 inżynierów dyskutujących o kodowaniu agentywnym, Huntley prezentuje Ralpha, Cursed (język programowania tworzony przez Ralpha) i transmituje na żywo kodowanie autonomiczne przez całą noc, śpiąc w Australii. W pomieszczeniu dochodzi do niepokojącej rozmowy na temat tego, jak łatwo jest skopiować 80%-90% SaaS i jak wiele rodzajów pracy może wkrótce całkowicie zniknąć.
• Lipiec 2025: Huntley publikuje oryginalny post na blogu z podstawową strukturą pętli bash. Artykuł zawiera lekki przykład zachęty i prośbę: „prawdopodobnie moglibyście znaleźć repozytorium języka cursed na githubie, gdybyście go szukali, ale proszę, jeszcze tego nie udostępniajcie.”
• Sierpień 2025: Odbywa się hackathon agentów YC — zespoły uruchamiają Kod Claude w ciągłych pętlach. Efektem jest wysłanie 6 repozytoriów przez noc. Dexter Horthy prowadzi eksperymentalną pętlę Ralpha na refaktoryzacji kodu React. W ciągu 6 godzin opracowuje kompletny plan refaktoryzacji i wykonuje go.
• Wrzesień 2025: Huntley oficjalnie wprowadza na rynek Cursed Lang, język programowania stworzony przez Ralpha. Istnieje w trzech implementacjach (C, Rust, Zig), posiada bibliotekę standardową oraz kompilator drugiego etapu napisany w Cursed.
• Październik 2025: Dexter prezentuje Ralpha na anonimowym spotkaniu Claude Code w San Francisco. Pytanie z publiczności: „Więc czy to polecasz?” Jego odpowiedź: „Głupie rzeczy mogą działać zaskakująco dobrze. Czego moglibyśmy się spodziewać po inteligentnej wersji?”
• Grudzień 2025: Anthropic wypuszcza oficjalną wtyczkę Ralpha Wigguma. Wtyczka przyjmuje pętlę bash Huntleya i formalizuje ją za pomocą haków zatrzymania i strukturalnych danych o błędach.
• Styczeń 2026: Huntley i Horthy przeprowadzają dogłębną dyskusję na YouTube porównując oryginalną implementację pętli bash Ralpha z implementacją haka zatrzymania Anthropic.

Bash-loop Ralph kontra Plugin Ralph

Oryginalny Ralph to pętla bashowa o 5 liniach. Wypisujesz plik zachęty, przekazujesz go do Claude, sprawdzasz, czy wynik przechodzi Twój test i kontynuujesz, dopóki się to nie stanie. Wszystko jest zapisane na dysku, wszystko jest widoczne. Jeśli coś się zepsuje, dokładnie widzisz dlaczego.

Wtyczka Anthropic odwraca ten model, więc zamiast uruchamiać pętlę z zewnątrz, instaluje Hak Zatrzymania w twojej sesji Claude. Gdy Claude próbuje wyjść, hak go przechwytuje, sprawdza warunki zakończenia i wprowadza ten sam monit ponownie, jeśli praca pozostaje. Pliki, które Claude zmodyfikował, nadal są tam.

Historia Git nadal istnieje, ale mechanizmy uprzęży są teraz nieprzejrzyste — ukryte w pliku stanu markdown, wrażliwe na uprawnienia, łatwe do uszkodzenia, jeśli nie wiesz, co robisz.

To klasyczny kompromis abstrakcji.

Wtyczka obniża koszty wdrożenia. Nie musisz pisać w bashu i nie musisz myśleć o pętlach. Ale gdy mechanizm staje się ukryty, oryginalny wgląd staje się łatwiejszy do przegapienia.

Wersja bash-loop zmusza cię do zaprojektowania szkieletu. Wersja plugin pozwala pominąć ten krok, co jest w porządku, dopóki nie natrafisz na przypadek krańcowy i nie będziesz mógł zobaczyć, co tak naprawdę się dzieje.

Dexter Horthy przetestował to i stwierdził, że umiera w tajemniczy sposób, chyba że użyjesz “–dangerously-skip-permissions”. Wtyczka instaluje haki w dziwnych miejscach, używa nieprzejrzystych plików stanu, a jeśli usuniesz plik markdown przed zatrzymaniem, uszkodzisz Claude w tym repozytorium, dopóki całkowicie nie wyłączysz wtyczki.

Więc, jaka jest lekcja? Obie metody działają, ale działają z różnych powodów. Pętla bash działa, ponieważ jest prosta i przejrzysta. Wtyczka działa, gdy abstrakcja nie ukrywa czegoś istotnego.

Czego Się Nauczysz Prowadząc To?

Ralph zakłada dystans między człowiekiem a agentem. Nie siedzisz na sesji i nie prowadzisz jej. Zamiast tego uruchamiasz ją, odchodzisz, sprawdzasz artefakty po jej zakończeniu i dostosowujesz ograniczenia na kolejną iterację.

Interakcja zachodzi na poziomie szkieletu — polecenia, testy, warunki zakończenia — nie wewnątrz konwersacji.

Z czasem pojawia się wzorzec: większość awarii to nie awarie modelu; to awarie uprzęży.

Specyfikacja była niejasna, test był zbyt ogólny, lub warunek zakończenia nie opisywał faktycznie, co oznacza „zakończone”.

Gdy zobaczysz to kilka razy, twój instynkt się zmienia. Przestajesz pytać „jak mogę sprawić, by Claude był mądrzejszy?” i zaczynasz pytać „jak mogę sprawić, by ograniczenia były bardziej rygorystyczne?”

To miejsce, gdzie specyfikacje stają się kluczowe.

Specyfikacje Jako Powierzchnie Sterowe

Huntley przedstawia specyfikacje nie jako dokumentację, ale jako stałe wejścia kontrolne. Tworzysz je poprzez rozmowę z Claude’em, edytujesz je celowo, aż staną się precyzyjne, a następnie przypinasz. Kiedy już są przypięte, nie zmieniają się przez całą pętlę.

To ma znaczenie, ponieważ specyfikacje robią trzy rzeczy jednocześnie:

1. Określają, co agent może wymyślić: Bez ścisłych specyfikacji, Claude doda warstwy obronne, abstrakcje lub funkcje, o które nigdy nie prosiłeś, rozszerzając zakres przy każdej iteracji. 
2. Stabilizują wyszukiwanie i odzyskiwanie: Dzięki temu agent nie wymyśla nowych wymagań.
3. Stabilizują zachowanie w kolejnych przebiegach: Każda iteracja rozwiązuje ten sam problem, a nie nieco inną interpretację tego problemu.

Jeśli twoja specyfikacja jest niejasna co do tego, co oznacza „ukończenie”, agent będzie to inaczej interpretować przy każdym przebiegu. Skończy się to dryfowaniem, rozszerzaniem zakresu i iteracjami, które się wzajemnie zaprzeczają.

Jak Odpowiedzialnie Obsługiwać Pętlę?

Minimalna konfiguracja Ralph często wygląda tak:

MAX_ITERS=30
for i in $(seq 1 $MAX_ITERS); do
  cat PROMPT.md | claude
  if ./ci.sh; then exit 0; fi
done
exit 1

Mechanika pętli ma znacznie mniejsze znaczenie niż zasady nią rządzące:

• Utrzymaj specyfikację niezmienną; nie dostosowuj jej w trakcie pętli w zależności od tego, co robi Claude. 
• Koduj zakończenie jako sprawdzalne wykonanie.
• Wprowadź limity iteracji i czasu, aby pętla nie mogła działać wiecznie i nie wyczerpać Twojego budżetu na tokeny. 
• Zachowaj dzienniki i różnice, abyś mógł sprawdzić, co poszło nie tak, jeśli tak się stanie. 

Ponadto, praktyka operacyjna ujawniła kilka heurystyk, które mają znaczenie:

• Preferuj małe, regularne aktualizacje niż duże refaktoryzacje, ponieważ duże zmiany sumują błędy i są trudniejsze do debugowania. 
• Uruchamiaj ponownie na aktualnym głównym branchu zamiast robić rebase, ponieważ konflikty scalania marnują iteracje.
• Unikaj używania Ralpha do pracy eksploracyjnej, ponieważ jeśli nie masz jasnych testów akceptacyjnych, otrzymasz tylko chaotyczną pętlę, która wymyśla rzeczy, o które nie prosiłeś.

Ograniczenie to funkcjonalność.

Pętla Jest Lekcją

Gdy Ralph zyskał popularność, pojawiły się różne warianty. Niektóre zespoły zbudowały strukturalne pętle zewnętrzne wokół agentów wywołujących narzędzia. Inne dodały oddzielne komponenty weryfikujące: inny model, który sprawdza wyniki pracy pracownika przed decyzją o zakończeniu pętli. Te rozszerzenia działają, tak, ale tylko jeśli respektują pierwotną ideę.

Zasada jest prosta: weryfikacja musi pozostać deterministyczna, a streszczenia nigdy nie mogą zastąpić głównych danych wejściowych.

• Jeśli dodasz weryfikator, powinien sprawdzać konkretne rzeczy: testy przechodzą, linter kończy bez błędów, git diff odpowiada oczekiwaniom. 
• Jeśli dodasz strukturyzowane pętle zewnętrzne, powinny one nadal widzieć surowe dane wyjściowe i surowe dzienniki, a nie uporządkowane podsumowanie tego, co poszło nie tak. 

Podstawowa teza Huntleya jest taka, że zawód programisty faktycznie wymarł, ale inżynieria oprogramowania — praktyka dobrze budowania systemów — jest bardziej żywa niż kiedykolwiek.