Loop development: programowanie w pętli z AI

Przesunięcie: od promptu do pętli

Przez pierwsze dwa lata pracy z modelami językowymi umiejętnością było pisanie promptów. W 2026 roku środek ciężkości przesunął się gdzie indziej: z tego, jak poprosić agenta, na to, jak zaprojektować pętlę, w której agent pracuje sam.

W trybie promptowania wydajesz polecenie, czytasz odpowiedź, wydajesz następne. W loop developmencie definiujesz sprawdzalny cel, a agent sam wykonuje krok, sprawdza, czy cel jest osiągnięty, i powtarza, aż do skutku, bez czekania na kolejne polecenie. Praktykę tę nazywa się loop engineering. Deklaracje o skokowym wzroście wydajności zostawiam bez powtarzania: nikt ich nie zmierzył, a badanie METR pokazuje, że odczuwane przyspieszenie potrafi mieć odwrotny znak niż zmierzone.

Nadzór zostaje, ale przenosi się na początek: zamiast poprawiać agenta po każdym kroku, ustalasz z góry, po czym pozna, że skończył.

Cztery typy pętli

Pętle różnią się tym, co je uruchamia i kiedy się kończą.

Dla wytwarzania oprogramowania z AI najważniejszy jest typ goal: ustawiasz warunek ukończenia, a agent iteruje aż do jego spełnienia. Typ hook jest drugi w kolejności, bo pozwala wpiąć agenta w istniejący proces: naprawa po błędzie CI, reakcja na nowy pull request, obsługa zgłoszenia.

Ralph, czyli pętla w najprostszej postaci

Najczęściej przywoływanym przykładem jest pętla Ralph, spopularyzowana przez Geoffreya Huntleya w połowie 2025 roku. Jego własny opis jest rozbrajająco prosty: „Ralph to pętla w Bashu”.

Mechanizm: agent działa w nieskończonej pętli powłoki. Przy każdym obiegu czyta ten sam plik z zadaniem, wprowadza zmiany w kodzie na dysku i przechodzi do następnego obiegu. Cały trik polega na tym, gdzie trzymana jest pamięć: w plikach i historii gita zamiast w kontekście modelu. Dzięki temu praca kumuluje się, mimo że okno kontekstu przy każdym obiegu startuje niemal od zera. Nazwa pochodzi od postaci z „Simpsonów”, znanej z niezłomnego optymizmu mimo porażek, co dobrze oddaje charakter metody: próbuj dalej, aż wyjdzie.

Wokół tego pomysłu narosły relacje o statusie anegdot: że Huntley zbudował tą metodą działający język programowania w kilka miesięcy autonomicznej pracy, albo że ktoś zrealizował kontrakt wart kilkadziesiąt tysięcy dolarów za koszt API rzędu kilkuset. Traktuję je wyłącznie jako ilustrację skali. Sam mechanizm, niezależnie od anegdot, jest realny i powtarzalny.

Model trzech pętli

Najbardziej użyteczny sposób myślenia o tym opisuje wytwarzanie oprogramowania jako trzy zagnieżdżone pętle działające z różną prędkością:

• Pętla agentowa (sekundy do minut). Prowadzi ją agent: pisze kod, uruchamia testy, iteruje, aż spełni specyfikację.
• Pętla deweloperska (kilkadziesiąt minut do godzin). Prowadzisz ją ty: oglądasz efekt, korygujesz kierunek, poprawiasz specyfikację.
• Pętla zewnętrzna (godziny do tygodni). Prowadzi ją świat: użytkownicy, rynek, rzeczywistość.

Podział pokazuje, czego pętla agentowa nie obejmuje. Agent domyka najszybszą pętlę, ale nie wie, czy buduje właściwą rzecz. To rozstrzyga się w dwóch wolniejszych pętlach, które prowadzi człowiek.

Gdzie to działa, a gdzie zawodzi

Granica jest ta sama, co przy całym wytwarzaniu oprogramowania z AI: liczy się to, czy sukces da się sprawdzić automatycznie.

Pętla działa, gdy cel jest mierzalny: „wszystkie testy przechodzą”, „aplikacja buduje się bez błędów”, „ten endpoint zwraca poprawną odpowiedź na zestawie przypadków”. Wtedy warunek stopu jest jednoznaczny, a każdy obieg pętli albo przybliża do celu, albo nie, i widać to bez oceny człowieka.

Zawodzi, gdy „gotowe” zależy od oceny, gustu albo decyzji, której nie da się zapisać jako test. Pętla bez sprawdzalnego warunku stopu kręci się dalej albo kończy na czymś, co spełniło literę warunku, ale nie jego sens. Wyjściem jest inny warunek stopu: pętla przygotowuje warianty, sprawdza ich techniczne działanie i zatrzymuje się, a ocena i rozstrzygnięcie, co właściwie zbudować, zostają po stronie człowieka.

Stąd trzy zabezpieczenia, bez których nie prowadzę pętli na produkcyjnym kodzie:

1. Sprawdzalny warunek stopu, czyli zdanie, które da się rozstrzygnąć bez człowieka: „testy X przechodzą, a build jest zielony”, w miejsce „zrób to dobrze”.
2. Testy, które ten warunek weryfikują. Przy przepisywaniu kodu najpierw powstają testy równoważności, potem pętla. Bez nich agent uzna zadanie za skończone na podstawie własnego przekonania zamiast dowodu.
3. Lista odbioru zmiany, która sprawdza także przebieg pracy. Badanie opisane niżej pokazuje, dlaczego sam zielony build mówi za mało.

Dlaczego przejście testów nie wystarcza: badanie SWE-CC

W badaniu SWE-CC z 5 października 2026 roku agenci kodujący naruszali średnio 43,1% zasad projektu, które miały zastosowanie w ich przebiegach, choć ich łatki w większości przechodziły testy. W przebiegach z poprawnie rozwiązanym zadaniem agent naruszał średnio 7,7 z 22,6 obowiązujących reguł (34,1%), a połowa tych naruszeń (50,3%) pojawiała się w trakcie pracy, przed końcowym diffem. Preprint przygotowało czterech badaczy z Singapore Management University i Singapore University of Technology and Design. Oparli go na 500 zadaniach z SWE-bench Verified, rozszerzonych o reguły projektów. Mierzy on różnicę między naprawą błędu, która przechodzi testy, a zmianą przygotowaną tak, jak wymaga tego projekt.

Autorzy zamienili dokumentację dla współtwórców 12 projektów open source, między innymi Django, Flaska, pytest, scikit-learn i Matplotliba, na 823 sprawdzalne reguły. Najwięcej dotyczy dokumentacji i docstringów (27% reguł), stylu języka (20%), testów (19%) i zmian specjalnych (13%); reszta to metadane pull requestów, konwencje gita, polityka użycia AI i jakość kodu. Każdą regułę opisuje funkcja sprawdzająca, a 150 z 823 reguł zweryfikowali recenzenci. Cztery modele (GPT-5.6 Luna, Gemini 3.7 Flash, DeepSeek V4 Flash, Kimi K2.5) pracowały w dwóch szkieletach agentowych, mini-SWE-agent i OpenHands. Każdy model pracował w dwóch ustawieniach: z adresami dokumentów z regułami i poleceniem, żeby je przeczytać przed pracą, oraz z regułami zebranymi w jednym pliku, co razem dało 8000 przebiegów.

Wskaźnik zgodności to odsetek reguł spełnionych wśród reguł, które w danym przebiegu miały zastosowanie i dały się ocenić; reguły bez wystarczających dowodów w zapisie przebiegu autorzy wyłączają z mianownika. W pierwszym ustawieniu kod przechodził testy w 74,6⁠–⁠94,4% przebiegów zależnie od modelu i szkieletu, a zgodność z regułami wynosiła od 51,8% (GPT-5.6 Luna w mini-SWE-agent) do 63,8% (DeepSeek V4 Flash w OpenHands). Praca nie podaje 43,1% z abstraktu osobno; to dopełnienie średniej zgodności w tym ustawieniu, która wyniosła 55,7% w mini-SWE-agent i 58,2% w OpenHands. Zebranie reguł w jednym pliku podniosło zgodność średnio o 8,75 punktu procentowego, w mini-SWE-agent najwięcej u GPT-5.6 Luna (o 15,8 punktu), najmniej u Kimi K2.5 (o 1 punkt).

Dwa wyniki mają dla pętli znaczenie praktyczne. Mimo adresów i polecenia 71,1% przebiegów w pierwszym ustawieniu w ogóle nie próbowało odczytać dokumentów z regułami. Ponad połowa prób odczytu nie zwróciła tekstu: szkielet ucinał długie wyjście albo agent źle obsłużył odpowiedź, na przykład przy znakach spoza ASCII. Najgorzej wypadły reguły o wkładzie z pomocą AI, które ma 11 z 12 projektów. Django wymaga na przykład ujawnienia użytych narzędzi AI i celu ich użycia, a część reguł z tej grupy poświadczenia, że osoba przeczytała i zrozumiała zmianę. W mini-SWE-agent agenci spełniali je w 15,3% przypadków, a z regułami w jednym pliku w 26,6%; w OpenHands odpowiednio w 20,6% i 30,7%. Reguły stylu języka, które model zna z treningu, spełniali w 84%.

Badanie ma granice. Przybliżeniami jest 64% funkcji sprawdzających, a ograniczenie do 294 dokładnych zmienia wyniki najwyżej o 4,7 punktu procentowego. Osiemnaście funkcji dotyczy wymogów wobec człowieka, na przykład potwierdzenia, że przeczytał zmianę; autorzy liczą je jak pozostałe, z osobną flagą. Ocena obejmuje tylko to, co zostało w zapisie przebiegu. Wyniki dotyczą konkretnych wersji czterech modeli w dwóch szkieletach z 2026 roku. Claude Code z modelem Claude Opus 5 posłużył autorom do zbudowania benchmarku, czyli do wydobycia reguł z dokumentacji oraz napisania i przeglądu funkcji sprawdzających, ale nie był oceniany jako agent; Codexa w badaniu nie ma. Moje badanie z 22 września 2026 roku sprawdzało tylko, czy instrukcje z pliku AGENTS.md trafiają do kontekstu Claude Code. Czy agent je potem wykonuje, to osobne pytanie; SWE-CC odpowiada na nie liczbami.

Warunek „testy przechodzą” potwierdza więc kod, a resztę sprawdza lista odbioru zmiany, którą stosuję po pętli:

• czy agent uruchomił testy poleceniem wymaganym przez projekt;
• czy zmiana ma opis, którego projekt wymaga w pull requeście;
• czy w zapisie przebiegu nie ma komend, których projekt zabrania, na przykład pominięcia hooków;
• czy użycie AI zostało ujawnione tam, gdzie projekt tego wymaga;
• czy człowiek przeczytał diff, zanim zmiana weszła.

Lista rozdziela trzy pytania, które łatwo zlać w jedno: czy instrukcja dotarła do agenta, czy kod działa i czy przebieg był zgodny z zasadami projektu. Na pierwsze odpowiada zapis kontekstu albo treść zwrócona przy odczycie pliku, z informacją, czy została ucięta; na drugie testy na końcowej wersji zmiany; na trzecie dziennik poleceń i opisów. Dopiero ten podział pozwala ustalić, skąd wziął się błąd.

Pętla kończy się też bez sukcesu: po wyczerpaniu limitu czasu lub kosztu, gdy agent powtarza ten sam błąd albo gdy potrzebna jest decyzja człowieka. Wtedy zostawia opis prób zamiast ogłaszać gotowość. Naprawa po fakcie nie usuwa naruszenia z przebiegu, więc do odbioru zachowuję cały zapis pracy agenta.

Jak tego używam

Wsparcie jest już natywne: Claude Code i Codex pozwalają uruchomić pętlę bez pisania własnego skryptu, w tym tryb celu, w którym ustawiasz warunek ukończenia, a agent pracuje przez wiele tur, aż go spełni.

Zasada jest ta sama, co w całej mojej pracy z AI przy kodzie: za to, co trafia do repozytorium, odpowiada człowiek, który to przeczytał. Pętla nie zdejmuje z nikogo odpowiedzialności za przegląd. Przesuwa pracę człowieka z pisania kodu na zdefiniowanie sprawdzalnego celu, dostarczenie testów, które go pilnują, i przegląd wyniku, zanim wejdzie.

Gdy kilka osób uruchamia agentów, trzeba ustalić, kto odbierze wyniki ich pracy. W tekście o zarządzaniu agentami AI pokazuję kartę, w której zapisuje się osobę odbierającą wynik, zakres uprawnień agenta i limit zadań czekających na sprawdzenie.