Pętle agentyczne: dlaczego jednorazowe prompty to pułapka

Znasz to uczucie. Zegar wskazuje jedenastą w nocy. Musisz dostarczyć feature, a od godziny pinglujesz z AI. Prompt - odpowiedź - wklejasz. Czasem działa. Czasem nie. Nie do końca wiesz, co jest czym.

Brzmi znajomo?

Oto nieprzyjemna prawda: większość deweloperów używa AI tak, jakby musieli samodzielnie naciskać guziki kalkulatora. Owszem, liczy. Ale nie masz pojęcia, co dzieje się w środku. A kiedy AI poda coś przekonującego, ale delikatnie zepsutego — to ty debugujesz to o północy.

Zespoły, które naprawdę dostarczają kod produkcyjny z AI, odkryły coś innego. Przestały traktować AI jako grę w pytanie i odpowiedź. Zamiast tego budują systemy — pętle — które pozwalają AI wprowadzać małe, bezpieczne i weryfikowalne zmiany w sposób ciągły. Efekty mówią same za siebie: mniej regresji, mniej przepełnień kontekstu, diffy, które da się faktycznie przeczytać.

Problem z jednorazowym podejściem

Jednorazowy prompt jest podstępnie prosty. "Napisz mi system autoryzacji użytkownika." Gotowe. "Zrefaktoruj cały moduł pod nowy API." Bam. Wygląda produktywnie. Szybko.

Do momentu, kiedy przestaje.

Pomyśl, co tak naprawdę dzieje się, gdy wrzucasz duże zadanie do AI jednorazowo. Najpierw uderzasz w ścianę kontekstu. Większość codebase'ów wartych pracy jest zbyt duża, by zmieścić się w pamięci AI. Więc zaczyna zgadywać to, czego nie widzi — robi założenia o zależnościach, konwencjach nazewnictwa, wzorcach architektonicznych, które mogą być kompletnie błędne.

Potem pojawia się problem z przeglądem. Jeśli AI zwraca diff na 500 linii, co właściwie z nim robisz? Przeglądasz pobieżnie. Ufasz mu bardziej, niż powinieneś, bo AI brzmi pewnie. Mergujesz i liczysz na szczęście.

Sęk w tym, że nadzieja to nie proces kontroli jakości.

Trzeci problem jest najbardziej podstępny. Modele AI są trenowane, żeby być pomocne — czyli trenowane, żeby brzmieć pewnie. Kiedy AI zwraca kod, który wygląda rozsądnie, pewnie wygląda rozsądnie dlatego, że był trenowany na rozsądnym kodzie. To nie znaczy, że jest poprawny w twoim konkretnym kontekście. Bez bramki sprawdzającej faktyczne zachowanie, pewność staje się jedynym kryterium akceptacji — a pewność to tragiczny substytut poprawności.

Pętla wchodzi do gry

Alternatywa brzmi niemal rozczarowująco prosto: zamiast jednego dużego prompta, rób wiele małych kroków. Po każdym kroku sprawdź efekty. Potem następny.

Zrób. Sprawdź. Powtórz.

To pętla agentyczna w swojej najbardziej podstawowej formie. Jeśli brzmi zbyt oczywście, żeby się nad tym rozwodzić, weź pod uwagę, że większość zespołów nadal tego nie robi. Magia nie tkwi w koncepcji — tkwi w dyscyplinie jej rygorystycznego egzekwowania.

Jak to wygląda w praktyce? Zamiast prosić AI o "naprawienie wszystkich padających testów", robisz tak:

1. Uruchamiasz suite testowy i znajdujesz pierwszy fail
2. Prosisz AI o naprawienie tylko tego jednego
3. Uruchamiasz testy ponownie, żeby zweryfikować poprawkę
4. Jeśli przechodzi — następny fail; jeśli pada — revert zmiany
5. Powtarzasz, aż zostanie zero błędów — albo AI zgłosi, że nie może iść dalej

Zauważ, co się dzieje. Każda zmiana jest niezależnie zweryfikowana. Kiedy coś się psuje, wiesz dokładnie, który edit to spowodował. Kiedy coś działa, zostaje. Pętla buduje krok po kroku zweryfikowany postęp zamiast stosu kodu, który "mam nadzieję, że działa".

Trzy zasady, które decydują o sukcesie

Nie wszystkie pętle są równe. Pętla źle zaprojektowana jest gorsza niż brak pętli w ogóle — może chodzić w nieskończoność, robiąc kosmetyczne zmiany, albo pewnie psuć rzeczy, udając, że pracuje. Pętle, które naprawdę dostarczają, mają trzy niepodważalne cechy.

Po pierwsze: zautomatyzowana bramka, z którą nie da się negocjować. Bramka to twój detektor prawdy. Może to być suite testowy przechodzący, linter zwracający zero błędów, type checker potwierdzający brak niezgodności typów, albo automatyczne porównanie screenshotów łapiące wizualne regresje. Kluczowe jest to, że bramka jest deterministyczna i obiektywna. Nie przekonasz jej argumentami — ani ty, ani AI. Jeśli kod nie przejdzie bramki, to się nie wydarzyło — revert, nie merge.

To brzmi prosto, ale wymaga zobowiązania do budowy infrastruktury bramek. Potrzebujesz prawdziwych testów z prawdziwym pokryciem. Potrzebujesz, żeby type checker faktycznie się uruchamiał. Potrzebujesz, żeby CI/CD było traktowane jako pełnoprawny obywatel, nie dodatek.

Po drugie: jedna zmiana na iterację. Brzmi bolesnie wolno, gdy przyzwyczaisz się do jednorazowych promptów. Czemu nie naprawić wszystkich błędów typów naraz? Czemu nie zaadresować wszystkich ostrzeżeń lintingowych jednym podejściem?

Bo kiedy grupujesz zmiany i coś się psuje, nie masz pojęcia, co to spowodowało. AI może naprawić trzy rzeczy, zepsuć jedną — i wynik netto wygląda pozytywnie, więc zmiana przechodzi. Teraz masz regresję bez jasnego winowajcy.

Jedna zmiana, jedna weryfikacja, jedwerdykt. To wolniejsze na krok, ale monumentally faster overall, bo każdy krok można niezależnie przejrzeć i zrevertować. Kiedy coś się psuje w produkcji, robisz git bisect do dokładnej zmiany, która to spowodowała — zamiast debugować niedokończony bałagan powiązanych modyfikacji.

Po trzecie: uczciwy warunek stopu. Pętla bez warunku stopu to albo pętla nieskończona, albo taka, która zatrzymuje się arbitralnie. Oba scenariusze są złe. Warunek stopu powinien być mierzalnym sygnałem: liczba testów spada do zera, raport "nie ma czego poprawiać" w kolejnych rundach, evaluation score się plateauuje.

Dyscyplina polega tu na akceptowaniu uczciwych pominięć. Kiedy kod jest rzeczywiście dobry, poprawnym wynikiem jest "nic nie zmieniłem — nic nie wymagało zmiany". Pętla, która wie, kiedy skończyć, jest warta dziesięciu takich, które meldują postęp, żeby wyglądać produktywnie.

Co pętle łapią, czego prompty nie zauważą

Pozwól, że dam ci konkretny przykład, dlaczego to ma znaczenie.

Wyobraź sobie pętlę self-improvement działającą na produkcyjnym panelu admina. Pętla robi screenshoty każdej strony, prosi AI o zidentyfikowanie i naprawienie jednego problemu użyteczności na rundę, uruchamia type checki i linting, i kontynuuje, dopóki nie może znaleźć nic do poprawy.

Przez kilka rund pętla wyprodukowała dziesiątki rzeczywistych usprawnień. Ładny polishing UI. Lepsze komunikaty błędów. Sprytniejsze empty states.

Ale najcenniejsza poprawka nie była polishingiem — był błąd. W jednej rundzie harness screenshotowy zflagował, że strona ustawień renderuje pełnoekranowy crash screen frameworka. Oto haczyk: ten crash był całkowicie po stronie klienta. Health checks API były zielone przez cały czas, bo API było w porządku. Człowiek przeglądający screenshoty mógłby przewinąć tę stronę albo założyć, że to przejściowy glitch renderingu.

Zautomatyzowana pętla to złapała, wyekstraktowała faktyczny błąd ("Cannot read properties of undefined (reading 'memes')"), ztrace'owała to do buga w merge'owaniu stanu w lifecycle komponentu i naprawiła to u źródła. A ponieważ harness teraz wie, żeby sprawdzać ten wzorzec crash screena, złapie całą klasę takich bugów na zawsze.

To jest właśnie ten zwrot. Pętla nie tylko robi robotę — buduje mechanizm, który akumuluje zweryfikowane usprawnienia i zapobiega powrotowi zweryfikowanych regresji.

Dlaczego to ma znaczenie dla twojego zespołu

Jeśli budujesz startup, nie masz czasu na narzędzia AI wymagające ciągłej opieki. Jeśli jesteś deweloperem, nie masz cierpliwości do narzędzi, które wprowadzają więcej bugów niż naprawiają.

Pętle agentyczne adresują oba problemy. Sprawiają, że pomoc AI staje się naprawdę niezawodna, zastępując zaufanie weryfikacją. Sprawiają, że postęp staje się mierzalny poprzez rozliczalność każdej zmiany. Sprawiają, że debugowanie staje się wykonalne — bo kiedy coś się psuje, wiesz dokładnie kiedy i dlaczego.

Najlepsze? Ten wzorzec nie ogranicza się do generowania kodu. Ta sama struktura działa dla automatycznego testowania, szukania bugów, skanowania bezpieczeństwa, aktualizacji dokumentacji, zarządzania zależnościami — wszędzie tam, gdzie używałeś jednorazowych promptów, a ciągła weryfikacja byłaby wartościowa.

Niezależnie od tego, czy działasz solo, czy zarządzasz zespołem: pytanie nie brzmi, czy używać AI do kodowania. Pytanie brzmi, czy używasz go w sposób, który faktycznie przyspiesza pracę — czy tylko sprawia, że czujesz się zajęty, akumulując techniczny dług.

Pętle nie są jedynym sposobem pracy z AI. Ale to jedyny sposób, który widziałem skalować się do poważnej pracy produkcyjnej bez akumulowania cmentarza kodu, który brzmi rozsądnie, ale jest niepoprawny.

Twoja kolej.