Loop engineering: gdy system sam steruje agentem AI

Przez prawie dwa lata dźwignia w pracy z agentami AI siedziała w promptcie: piszesz polecenie, czytasz wynik, poprawiasz, znowu piszesz. Trzymasz narzędzie w ręku przez cały czas. To się właśnie kończy. Loop engineering to projektowanie małego systemu, który robi tę pętlę za Ciebie, a Ty zaczynasz pilnować systemu, nie pojedynczych promptów.

Czym jest loop engineering i dlaczego to realna zmiana

Loop engineering to projektowanie systemu, który zamiast Ciebie podaje agentowi AI zadania, sprawdza efekt i wybiera kolejny krok. Dotąd dźwignią był prompt, czyli to, co wpisujesz. Teraz dźwignią staje się pętla, czyli system, który wpisuje za Ciebie. Punkt nacisku przesunął się o piętro wyżej.

Addy Osmani, inżynier znany z pracy nad wydajnością w Google, rozkłada taką pętlę na sześć części: znajdź zadanie, oddaj je agentowi, sprawdź wynik, zapisz, co się stało, zdecyduj o następnym ruchu, powtórz. Anthropic raportuje, że jego inżynierowie scalają dziś około 8 razy więcej kodu dziennie niż w 2024, choć sama firma zaznacza, że to liczba „niemal na pewno zawyżona" względem realnego zysku z produktywności.

I dobrze, że zaznacza, bo akurat ta liczba jest sporna. Mechanizm sporny nie jest: dźwignia przeniosła się z pisania promptów na projektowanie pętli, która te prompty pisze. Dla właściciela firmy to znajomy schemat. To ta sama logika, co przy każdej automatyzacji procesów, tylko z agentem AI w środku zamiast prostego scenariusza „jeśli to, zrób tamto".

Test czterech warunków: kiedy pętla się opłaca, a kiedy pali budżet

Zanim zbudujesz jakąkolwiek pętlę, sprawdź cztery warunki. Pętla zwraca się tylko wtedy, gdy spełnione są wszystkie naraz. Wystarczy, że brakuje jednego, a koszt przewyższy korzyść. To najtańszy test, jaki możesz zrobić, bo nie kosztuje ani jednego tokena.

• Zadanie się powtarza, co najmniej raz w tygodniu, więc koszt jednorazowej konfiguracji ma się z czego amortyzować.
• Weryfikacja jest automatyczna: zestaw testów, kontrola typów, linter albo build potrafią odrzucić pracę bez Ciebie w pokoju.
• Budżet tokenów udźwignie marnotrawstwo: pętle wielokrotnie czytają kontekst, ponawiają próby i eksplorują, a tokeny palą się niezależnie od tego, czy dany przebieg cokolwiek dowiezie.
• Agent ma narzędzia seniora: logi, środowisko do odtworzenia błędu, możliwość uruchomienia kodu i zobaczenia, co naprawdę się psuje.

Brzmi jak lista dla działu IT, bo nią jest. Ale wniosek jest uniwersalny i identyczny jak przy każdej automatyzacji w firmie: oddajesz maszynie to, co się powtarza i co da się sprawdzić bez człowieka. Reszta to praca dla człowieka.

Kto zyskuje, a kto powinien odpuścić

Pętle sprzyjają tym, których stać na ich karmienie. Wygrywają zespoły z powtarzalną, maszynowo sprawdzalną robotą i budżetem na nią. Tracą ci, którzy budują pętlę tam, gdzie nie ma czego sprawdzać, albo gdzie wąskim gardłem jest człowiek, nie pisanie.

Zyskują: zespoły z powtarzalnymi, weryfikowalnymi zadaniami, takimi jak triage błędów z CI, aktualizacje zależności, masowe poprawki lintera czy szkic zgłoszenia zamieniany w gotowy pull request na dobrze otestowanym kodzie. Pomagają im mocne zestawy testów i kultura pracy asynchronicznej.

Tracą: pojedynczy twórcy na tanich planach (rachunek za tokeny przychodzi przed zyskiem), kod bez automatycznej weryfikacji (pętla tylko przytakuje sama sobie) oraz zespoły, których realnym wąskim gardłem jest przegląd kodu, a nie pisanie (pętla tylko wydłuża kolejkę do przeglądu). Do zadań jednorazowych albo wymagających oceny jeden celny prompt nadal wygrywa.

To ta sama kalkulacja, którą robisz, decydując między gotowym narzędziem a rozwiązaniem szytym na miarę. Rozpisaliśmy ją w tekście o tym, kiedy opłaca się dedykowany agent AI, a kiedy gotowy chatbot.

Pięć klocków, z których składa się pętla

Każdą pętlę da się rozłożyć na pięć elementów. Nie potrzebujesz wszystkich od razu, ale warto wiedzieć, do czego służą, zanim ktoś sprzeda Ci „rój agentów", którego nie da się sprawdzić. Oto one po ludzku.

• Automatyzacje to bicie serca pętli: uruchamiają się według harmonogramu albo zdarzenia, a reszta na nich wisi.
• Izolacja pracy (w świecie kodu: osobny katalog roboczy na własnej gałęzi) sprawia, że dwóch agentów nie wchodzi sobie w pliki. Mechaniczne kolizje znikają, ale Twoja przepustowość przeglądu nadal jest sufitem dla liczby równoległych agentów.
• Umiejętności to zapisana raz wiedza o projekcie: konwencje, kroki builda, „tak nie robimy, bo raz nas to wywróciło". Bez nich pętla co cykl odtwarza kontekst od zera.
• Konektory (przez standard MCP, czyli Model Context Protocol) pozwalają agentowi dotknąć realnych narzędzi: systemu zgłoszeń, bazy, API, czatu zespołu. To różnica między „oto poprawka" a pętlą, która sama otwiera zgłoszenie i daje znać, gdy testy są zielone.
• Subagenci rozdzielają tego, kto pisze, od tego, kto sprawdza. To najważniejszy ruch strukturalny w całej układance.

Ten ostatni klocek jest kluczowy. Model, który napisał kod, jest „zdecydowanie zbyt miły, oceniając własną pracę", jak ujmuje to Osmani. Drugi agent, z innymi instrukcjami, łapie to, co pierwszy sobie wmówił. To nie jest nowe słownictwo: Anthropic opisał ten układ jako wzorzec evaluator-optimizer w swoim tekście inżynierskim z grudnia 2024, półtora roku przed modą na „loop engineering". Praktyczny wniosek: weryfikator, któremu ufasz, to jedyny powód, dla którego możesz odejść od ekranu.

Minimalna sensowna pętla i jedna liczba, którą warto mierzyć

Jeśli przeszedłeś test czterech warunków, zbuduj najmniejszą możliwą wersję, nie rój. Cztery części wystarczą: jedna automatyzacja, jedna umiejętność, jeden plik stanu i jedna bramka. Kolejność ma znaczenie i to ona zwykle decyduje o powodzeniu.

Najpierw doprowadź jeden ręczny przebieg do powtarzalności. Potem zamień go w umiejętność. Potem owiń w pętlę. Dopiero na końcu zaplanuj w harmonogramie. Plik stanu (zwykły plik tekstowy w repozytorium albo tablica zadań) jest po to, żeby jutro pętla wznawiała pracę, a nie zaczynała od zera. Zasada jest prosta: agent zapomina, repozytorium nie.

I jeszcze jedna liczba, jedyna, która się naprawdę liczy: koszt za zaakceptowaną zmianę, a nie zużyte tokeny ani liczba uruchomień. Jeśli mniej niż połowa zmian z pętli przechodzi, robisz ręcznie dokładnie tę pracę, którą pętla miała Ci oszczędzić. Wtedy pętla nie zarabia, tylko dokłada.

Gdzie pętle cicho zawodzą

Najgroźniejsza awaria pętli jest cicha: kosztuje dalej, choć nic sensownego nie dowozi. Inżynier Geoffrey Huntley nazwał ją „pętlą Ralpha Wigguma". Agent miał zgłosić koniec dopiero po skończeniu zadania, a zgłasza go za wcześnie, więc pętla zamyka się w połowie roboty i pali tokeny dalej. Oto typowe pułapki i ich lekarstwa.

• Brak prawdziwego weryfikatora: dwóch optymistów przytakuje sobie nawzajem. Lekarstwo to obiektywna bramka, która potrafi odrzucić pracę (test przechodzi albo nie, build się kompiluje albo nie), a nie recenzent z samą opinią.
• Dryf celu w długich sesjach: każde streszczenie gubi trochę kontekstu, a „nie rób X" znika gdzieś koło 47. tury. Lekarstwo to stała specyfikacja wczytywana przy każdym przebiegu.
• Stronniczość na własną korzyść: twórca jest zbyt łagodny dla swojej pracy. Lekarstwo to osobny subagent w roli weryfikatora.
• Lenistwo agenta: ogłasza „wystarczająco gotowe" przy częściowym wyniku. Lekarstwo to warunek stopu sprawdzany przez świeży, niezależny model.

Podatek od bezpieczeństwa i dług zrozumienia

Pętla działająca bez nadzoru to powierzchnia ataku bez nadzoru. Im sprawniej dowozi kod, którego nie napisałeś, tym większa luka między tym, co jest w repozytorium, a tym, co naprawdę rozumiesz. To dwa rachunki, które przychodzą później, ale potrafią zaboleć.

Podatek od bezpieczeństwa. Pętla otwiera zgłoszenia szybciej, niż człowiek je czyta. Bez bramki, która obejmuje skan podatności, audyt zależności i wykrywanie sekretów, niebezpieczny kod scala się sam. Skille bywają wektorem ataku: pętla, która sama instaluje umiejętności ze społeczności, dziedziczy każdy ukryty w nich zastrzyk poleceń. W jednym audycie 520 z 17 022 sprawdzonych skilli wyciekało dane uwierzytelniające, więc czytaj źródło, zanim cokolwiek zainstalujesz. Uważaj też na pełzanie uprawnień: pętla testowana „tylko do odczytu" dostaje „tylko ten jeden" zapis i nikt już do tego nie wraca.

Dług zrozumienia. Tu lekarstwa nie są techniczne. Czytaj diffy. Sprawdzaj wyrywkowo, czy bramka faktycznie łapie awarię, na której Ci zależy, bo bramki z czasem rdzewieją. Trzymaj pętlę z dala od decyzji architektonicznych. Osmani nazywa największe ryzyko „kapitulacją poznawczą": pokusą, żeby przestać mieć własne zdanie i brać, co pętla zwróci. Jest najtańsza do uniknięcia i najdroższa, gdy już się zdarzy.

Co to znaczy dla Twojej firmy

Dla większości firm wniosek jest prosty i uczciwy: jeszcze nie teraz. Pętla ma sens dopiero, gdy zadanie się powtarza, weryfikacja jest automatyczna, budżet udźwignie marnotrawstwo, a agent ma narzędzia seniora. Zanim ktoś sprzeda Ci „autonomicznego agenta", przejdź z nim te cztery warunki na głos.

To ta sama logika, którą stosujesz przy każdej decyzji o automatyzacji: czy to, co chcesz oddać maszynie, naprawdę się powtarza i czy da się sprawdzić wynik bez człowieka. Jeśli porównujesz narzędzia, zacznij od naszego zestawienia Make vs n8n vs Zapier. A zanim podpiszesz umowę z wykonawcą, przejdź listę kontrolną doboru firmy do wdrożeń AI.

Ta sama zmiana dotyczy widoczności w wyszukiwarkach i w AI. Powtarzalną, sprawdzalną robotę (monitoring pozycji, pilnowanie świeżości treści, kontrolę danych strukturalnych) da się oddać pętli. Ale o tym, co i po co publikować, wciąż decyduje człowiek. Jeśli wolisz oddać nam tę powtarzalną część, zacznij od bezpłatnego audytu SEO i GEO albo zerknij w cennik.

Zacznij mały: jedna automatyzacja, jedna umiejętność, jeden plik stanu, jedna bramka. Doprowadź jeden ręczny przebieg do powtarzalności, zamień go w umiejętność, owiń w pętlę, a dopiero potem zaplanuj. Praca nie zrobiła się łatwiejsza. Przesunął się punkt dźwigni.

Najczęstsze pytania o loop engineering

Czym jest loop engineering w jednym zdaniu?

To projektowanie małego systemu, który zamiast Ciebie znajduje zadanie, oddaje je agentowi AI, sprawdza wynik i wybiera następny krok. Prompt pisałeś Ty, pętlę projektujesz raz, a potem to ona promptuje agenta. Dźwignia przenosi się z pisania poleceń na projektowanie systemu, który je pisze.

Kiedy budowa pętli agentów się opłaca?

Gdy spełnione są cztery warunki naraz: zadanie powtarza się co najmniej raz w tygodniu, weryfikacja jest automatyczna (test, build, linter), budżet tokenów udźwignie marnotrawstwo, a agent ma narzędzia seniora (logi, środowisko, uruchamianie kodu). Brakuje jednego i pętla kosztuje więcej, niż daje.

Czym jest pętla Ralpha Wigguma?

To opisana przez inżyniera Geoffreya Huntleya cicha awaria: agent miał zgłosić koniec dopiero po skończeniu zadania, a zgłasza go za wcześnie, więc pętla kończy w połowie roboty i dalej pali tokeny. Lekarstwem jest twarda bramka, która potrafi obiektywnie odrzucić niegotową pracę.

Dlaczego pętla potrzebuje osobnego agenta do sprawdzania?

Bo model, który napisał kod, jest zbyt łagodny dla własnej pracy. Drugi agent z innymi instrukcjami łapie to, co pierwszy sobie wmówił. Anthropic opisał to jako wzorzec evaluator-optimizer już w grudniu 2024. Weryfikator, któremu ufasz, to jedyny powód, dla którego możesz odejść od ekranu.

Czy moja firma już teraz potrzebuje pętli agentów?

Najczęściej jeszcze nie. Jeśli zadanie się nie powtarza, nie da się go sprawdzić maszynowo albo wąskim gardłem jest przegląd, a nie pisanie, jeden celny prompt wygrywa. Pętla zwraca się dopiero przy powtarzalnej, automatycznie weryfikowalnej robocie z budżetem na marnotrawstwo.