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.

Różnica jest konkretna. 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. Branża nazwała tę praktykę loop engineering i opisuje ją jako największy mnożnik wydajności dla zespołów inżynierskich w tym roku.

To nie jest magia ani autonomia bez nadzoru. To zmiana miejsca, w którym pracuje człowiek: przestajesz prowadzić agenta za rękę, a zaczynasz projektować warunki, w których może pracować bez prowadzenia.

Cztery typy pętli

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

Dla wytwarzania oprogramowania 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. Kluczowy trik polega na tym, gdzie trzymana jest pamięć: w plikach i historii gita, nie 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, które warto traktować jako anegdoty, nie zmierzone fakty: ż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 jako ilustrację skali, nie jako dane. Sam mechanizm, niezależnie od anegdot, jest realny i powtarzalny.

Model trzech pętli

Najbardziej użyteczny sposób myślenia o tym pochodzi od Andrew Nga, który opisał 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ść.

Ten podział jest ważny, bo 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. Loop development przyspiesza najszybszą pętlę, a nie zastępuje dwóch pozostałych.

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.

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 albo kręci się bez końca, albo kończy na czymś przypadkowym, co spełniło literę warunku, ale nie jego sens. To nie jest wada narzędzia, tylko jego zakres: loop development jest do celów mierzalnych, nie do rozstrzygania, co właściwie zbudować.

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

1. Sprawdzalny warunek stopu. Zdanie, które da się rozstrzygnąć bez człowieka. Nie „zrób to dobrze”, tylko „testy X przechodzą, a build jest zielony”.
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, a nie dowodu.

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 pozostaje ta sama, co w całej mojej praktyce wytwarzania oprogramowania z AI: agent przyspiesza realizację, człowiek odpowiada za to, co powstaje. Pętla nie zdejmuje z nikogo odpowiedzialności za przegląd. Przesuwa tylko pracę człowieka z pisania kodu na trzy rzeczy: zdefiniowanie sprawdzalnego celu, dostarczenie testów, które go pilnują, i przegląd wyniku, zanim wejdzie.

Ta strona jest tego przykładem. Powstała w dużej części tą metodą: małymi, sprawdzalnymi krokami, z warunkami ukończenia i przeglądem każdej zmiany przed wdrożeniem. To nie jest argument, że metoda jest cudowna. To argument, że jest zwyczajna i powtarzalna, o ile trzyma się jej granic.