O czym jest ten film
- Pętla agenta to powtarzalny cykl: rozumowanie → działanie → obserwacja wyniku, trwający do spełnienia warunku zakończenia.
- „Inżynieria pętli” to zastąpienie człowieka w roli osoby, która wystawia prompty — zamiast tego projektujesz system sterujący agentami.
- Dwa filary skutecznej pętli: obiektywny cel oraz weryfikacja, czyli jasne kryterium, po którym agent wie, że skończył.
- Autor ironizuje wobec mody na roje agentów 24/7: bez zrozumienia skaluje się problemy i błędy, a nie zyski.
- Większość zadań nie wymaga rozbudowanej architektury — wystarczy jedna sesja terminala i dobry prompt (solo-pętla).
- Trzy podstawowe wzorce: solo-pętla, układ wykonawca–recenzent oraz kierownik z zespołem pomocników.
- Trzy dema z Claude Code: miniatura YouTube (27 minut), model samolotu w three.js (37 minut) i rekonstrukcja okładki „Abbey Road” w czystym HTML/CSS (siedem wersji).
- Najlepsze kryterium ukończenia jest mierzalne („iteruj, aż metryka X osiągnie wartość Y”); kryterium „aż będziesz zadowolony” to najsłabsze ogniwo.
- Weryfikację dobiera się do rodzaju zadania: grafika — zrzuty ekranu, gra — testy funkcjonalne i przechodzenie poziomów, skrypt — logika i ton wypowiedzi.
- Rady ekspertów obowiązują w ich kontekście: autor zamiast wielodniowych przebiegów uruchamia pętle na 35 minut do 8 godzin, najczęściej na noc.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przestań promptować — zacznij projektować pętle
Na czym polega: Sednem inżynierii pętli jest to, że zamiast ręcznie wystawiać kolejne prompty i uwagi, budujesz system, który sam iteruje do celu. Boris Cherny i Peter Steinberger publicznie przyznali, że przestali promptować swoje agenty — piszą pętle.
Jak stosować: Gdy zadanie powtarza się lub wymaga wielu poprawek, raz opisz cel, kryterium ukończenia i sposób weryfikacji — zamiast karmić agenta uwagami po każdej próbie.
Na co uważać: Nie każde zadanie zasługuje na pętlę. Przy prostej, jednorazowej robocie zwykły prompt wypada szybciej i taniej.
2.Pętla to wyzwalacz, działanie i warunek stopu
Na czym polega: Konstrukcyjnie pętla ma trzy elementy: coś ją uruchamia, agent wykonuje pracę, a jasny warunek mówi mu, kiedy przestać.
Jak stosować: Zanim odpalisz pętlę, dopisz warunek zakończenia wprost w poleceniu — np. próg metryki albo limit przebiegów.
Na co uważać: Pętla bez warunku stopu kręci się w nieskończoność i spala budżet — czasem przez wiele godzin bez żadnego użytecznego wyniku.
3.„Gotowe” definiuj metryką, nie uczuciem
Na czym polega: W demie z miniaturą kryterium brzmiało „aż będziesz zadowolony” — czyli subiektywnie. Najlepsze pętle mówią wprost: „iteruj, dopóki metryka X nie osiągnie wartości Y”, ewentualnie z twardym limitem przebiegów.
Jak stosować: Tam, gdzie da się mierzyć (testy, progi ocen, liczba błędów), zamień ocenę na liczbę. Tam, gdzie się nie da — rozważ osobnego agenta-sędziego.
Na co uważać: Oceny estetyczne trudno w pełni uprościć do liczb; nieudolna „metryka” potrafi być gorsza niż szczery, opisany przepis jakości.
4.Weryfikację dopasuj do rodzaju zadania
Na czym polega: HTML i grafika weryfikują się zrzutami ekranu w przeglądarce, kod — testami, skrypt — logiką i tonem wypowiedzi, gra — przejściem poziomów. Twoim zadaniem jest wyposażyć agenta w narzędzia do tych sprawdzeń.
Jak stosować: Przy każdym nowym typie zadania zapytaj: „skąd agent ma wiedzieć, że wyszło dobrze?” — i dopiero potem dobieraj narzędzia (przeglądarka, testy, parser transkrypcji).
Na co uważać: Zła weryfikacja usztywnia błędy: agent poprawia wynik według kryterium, które nie łapie rzeczywistego problemu.
5.Nie potrzebujesz armii agentów — zacznij od solo-pętli
Na czym polega: Większość zadań nie wymaga rozbudowanej architektury. Wystarczy jedna sesja terminala i porządny prompt: pojedynczy agent, który rozumuje, działa, obserwuje i powtarza.
Jak stosować: Opanuj najpierw jedną, prostą pętlę na jednym zadaniu — to wzorzec, z którego autor korzysta najczęściej.
Na co uważać: Nie doskakuj do rojów i „menedżerów agentów”, dopóki nie rozumiesz pojedynczego cyklu — inaczej po prostu skalujesz własne problemy.
6.Oddziel wykonawcę od recenzenta
Na czym polega: Wzorzec „wykonawca–recenzent”: jeden agent robi robotę, drugi ją ocenia i zwraca uwagi. W demie z miniaturą oceny były subiektywne, więc naturalnym ulepszeniem jest dedykowany podagent oceniający, skalibrowany na przykładach.
Jak stosować: Przy zadaniach jakościowych stwórz osobnego agenta-sędziego z własnym promptem i przepuść go przez serię prób, zanim zaufasz jego ocenom.
Na co uważać: Recenzent dziedziczy ograniczenia modelu — bez kalibracji będzie oceniał według własnych upodobań, a nie twoich.
7.Pętla ma cię przybliżyć do celu, nie dawać perfekcji
Na czym polega: Samolot w three.js wciąż wymaga poprawek, a rekonstrukcja „Abbey Road” po siedmiu wersjach i tak daleko odbiega od oryginału — ale oba wyniki są o klasę lepsze, niż byłyby bez celu i kryteriów.
Jak stosować: Oceniaj pętlę po tym, ile oszczędza ci iteracji przy pierwszym podejściu, a nie po tym, czy wynik jest bez skazy.
Na co uważać: Nie przyjmuj rezultatu tylko dlatego, że agent zameldował „gotowe” — jego kryterium bywa głupsze niż twoje oko.
8.Zabezpiecz pętlę: twardy limit, koszt, logi
Na czym polega: Działającą pętlę tworzą: mierzalny cel, twarde zatrzymanie, dobre narzędzia, pamięć, osobny sprawdzający, planowanie na starcie, logowanie i rachunek, który się spina z kosztami.
Jak stosować: Łącz próg metryki z twardym limitem przebiegów (np. „maksymalnie osiem podejść”) i loguj kroki, żeby po fakcie wiedzieć, co agent robił.
Na co uważać: Trudny cel plus nierealne kryterium równa się przebieg wielogodzinny bez wyniku — autor miał pętle powyżej 12 godzin, które nic mu realnie nie dały.
9.Przenieś pętlę uwag z siebie na agenta
Na czym polega: Poprawki i tak nastąpią — pytanie brzmi, kto je wydaje. Gdy zamiast człowieka iteruje agent z własną weryfikacją, jakość rośnie znacznie szybciej w pierwszych próbach.
Jak stosować: Tam, gdzie dotąd pisałeś ręcznie „popraw to i to”, włącz do pętli automatyczną ocenę i iterowanie — np. przy montażu wideo czy dopracowywaniu dokumentów.
Na co uważać: Pętla jest dokładnie tak dobra, jak jej kryterium ukończenia — słaby warunek, słaby wynik.
10.Nie kopiuj setupów ekspertów bez kontekstu
Na czym polega: Peter Steinberger to zawodowy programista budujący agentów — w jego pracy pętle mogły pomnożyć produktywność kilkukrotnie. Autor, pracujący głównie nad wiedzą, nie robota z kodem, używa pętli oszczędnie: 35 minut do kilku godzin, duże cele na noc.
Jak stosować: Dopasuj rytm pętli do własnego toku pracy — uruchamiaj je według harmonogramu lub zdarzeń, a przy dużych celach odpalaj „porcję na noc” i rano dopracowuj wynik dalej, sam lub kolejną pętlą.
Na co uważać: Presja, że „bez pięciu agentów orkiestrujących pięciu agentów zostajesz w tyle”, to nie prawda o twojej pracy — to FOMO.
Redakcyjne tłumaczenie
Wstęp: comiesięczne przypomnienie (z przymrużeniem oka)
Mam tu na ekranie cztery agenty, które kręcą się w pętli, wywołują kolejne podagenty, piszą za mnie prompty i projektują systemy. Tylko czy to jest realnie produktywne, czy po prostu efektowne demo?
Oto comiesięczne przypomnienie: nie powinieneś już promptować agentów do kodowania. Powinieneś projektować pętle, które promptują twoich agentów. Boris Cherny i Peter Steinberger publicznie przyznali, że sami już nie wystawiają promptów swoim agentom — piszą pętle. Pętla to trzy rzeczy: wyzwalacz, działanie i warunek zakończenia. A jeśli nadal piszesz pętle, które promptują agentów do kodowania, to zostajesz w tyle. Musisz zbudować metaagenta, który na podstawie twojego „vibe’u” sam wywnioskuje, jakie pętle chciałbyś mieć — i to on je napisze.
(Informacja dodatkowa: Boris Cherny to twórca Claude Code w Anthropic, a Peter Steinberger — znany niezależny deweloper aplikacji, który przeszedł do OpenAI. Wstęp filmu jest celowo ironiczny — autor parodiuje ton hiperbolizujących wpisów na X.)
W ostatnim czasie mówi się mnóstwo o pętlach agentów, o „loop engineering” — jak zwał, tak zwał. Dlatego postanowiłem nagrać materiał, który uporządkuje, o co w tym naprawdę chodzi. Każdy ma tu własną interpretację i inną definicję, a do każdego to dociera w zupełnie innym punkcie. Moim zdaniem najlepiej podsumowuje to następujące ujęcie: inżynieria pętli to zastąpienie siebie w roli osoby, która promptuje agenta. Zamiast tego projektujesz system, który robi to za ciebie. Samą pętlę można rozumieć jako rekurencyjny cel: definiujesz, po co to wszystko, a sztuczna inteligencja iteruje, dopóki zadanie nie zostanie ukończone.
Są przy tym dwa najważniejsze filary. Pierwszy to cel: jakie jest faktyczne zadanie? Najlepiej coś mierzalnego, a nie subiektywnego. Drugi to weryfikacja: skąd agent wie, kiedy ma przestać? Jak sprawdza i poprawia?
Rój agentów 24/7 — czy to cokolwiek daje?
No dobrze. Jeśli przyjmiesz tę całą radę i zaczniesz budować roje i floty agentów pracujących bez przerwy, siedem dni w tygodniu, warto się zatrzymać i zadać sobie pytanie: co ja tu właściwie robię? I czy to realnie cokolwiek daje?
Najpierw pomyślałem sobie: jak ja właściwie używam tych pętli? Bo gdy czyta się wpisy, które pokazałem na początku, łatwo wpaść w myślenie: skoro nie mam pięciu agentów, które non stop orkiestrują po pięć własnych agentów, to zostaję w tyle albo marnuję pieniądze wydane na subskrypcję Claude. I to jest moim zdaniem kompletna nieprawda. Bo jeśli nie rozumiesz, co robisz, to najpewniej po prostu skalujesz problemy — i po jakimś czasie zostaje ci stos błędów do naprawienia.
Poza tym nie każdy z nas jest w sytuacji, w której agenci harujący całą dobę realnie mu pomagają. Ja na przykład nie jestem. Mam agentów, którzy robią rzeczy w określonym rytmie, i agentów reagujących na konkretne zdarzenia — ale samo to, żeby pracowały dla mnie bez przerwy, nic mi nie daje. Gdybym pracował z zespołem nad jednym kodem, budował produkt i nieustannie coś do niego dokładał, może miałoby to większy sens. U mnie — nie.
Dlatego chcę to wyjaśnić tak prosto, jak potrafię, i pokazać, gdzie wy możecie wpleść pętle we własne procesy — po co i w jaki sposób.
Nawiasem mówiąc: HTML, na który za chwilę spojrzymy, powstał właśnie w pętli agenta. Przeszukała ona 45 źródeł — artykułów, transkrypcji filmów z YouTube, postów z X — i kręciła się w kółko, dopóki nie ułożyło jej się w głowie, co właściwie zbudować. A to, co ostatecznie powstało, nie było wersją pierwszą. Raczej siódmą. Agent musiał sprawdzać, robić zrzuty ekranu, przeglądać, poprawiać — aż w końcu stwierdził: dobra, koniec, to jest wynik.
Pętla krok po kroku: rozumuj, działaj, obserwuj
Pętla agenta to po prostu AI, które zastanawia się, co zrobić, działa — zaczyna wdrażać — a potem przygląda się rezultatowi. I powtarza ten cykl w kółko, dopóki nie osiągnie celu, dopóki nie uzna: kryterium spełnione, jest dobrze, kończę.
Lubię to sobie wizualizować tak: AI nigdy nie jest idealne. Nie zrobi czegoś za pierwszym podejściem tak, żebyś po prostu zaakceptował wynik. Wyobraźmy więc wykres: na osi poziomej kolejne próby, na osi pionowej jakość. Przy prostym zadaniu pierwsza próba daje powiedzmy 50 procent. Patrzysz na to i mówisz: dobrze, popraw to i to. Druga próba dokłada może pięć, dziesięć procent. I tak z każdą porcją uwag jakość rośnie, aż dochodzisz tam, gdzie wynik cię satysfakcjonuje — 90, 95 procent.
Cały pomysł sprowadza się więc do pytania: czemu nie zlecić agentowi tego fragmentu — pętli informacji zwrotnej i iteracji — zamiast robić to samemu? Przecież te iteracje i tak się wydarzą. A jeśli zamiast człowieka robi je agent, to już pierwsza próba może wyskoczyć wysoko. Dorzucamy jeszcze odrobinę uwag i gdzieś około trzeciej–czwartej iteracji jesteśmy znacznie wyżej, niż gdyby tego agentowego etapu weryfikacji w ogóle nie było.
Dlatego każdy opisuje to inaczej. Jedni mówią o schemacie „pomyśl–zadziałaj–zobacz”, czyli w praktyce: rozumuj, działaj, obserwuj — i od nowa. Inni pokazują model, który raz po raz sięga po narzędzia i wraca z wynikiem. Jeszcze inni mają cel realizujący się całkowicie bez nadzoru. A są wreszcie floty agentów, w których kierownicy promptują agentów, a ci z kolei promptują kolejnych — matrioszka w matrioszce.
Dlatego chciałem to sprowadzić do głównych filarów, którymi moim zdaniem są: rozumuj, działaj, obserwuj. Wyobraź sobie uzdolnionego stażystę, którego nie musisz pilnować krok po kroku. Dajesz mu cel, on sam ustala, co robić dalej, sprawdza własną robotę, bierze się za nią ponownie — i wraca do ciebie dopiero po to, żeby powiedzieć: gotowe. I to po tym, jak kilka razy sprawdził wynik i coś poprawił.
Cel i kryterium ukończenia — dwa filary
Mówisz więc: „Claude Code, oto czego od ciebie chcę”. My, ludzie, bardzo dobrze umiemy określić, czego chcemy — świetnie definiujemy cel końcowy. Do tego musimy jednak dodać: a skąd będziesz wiedział, że jest zrobione? Gdy pieczesz ciasto, wbijasz w nie widelec — jeśli wyjmujesz go czystego, ciasto jest gotowe. Jak zakomunikować agentowi, tak obiektywnie, jak się da, kiedy ma przestać? Jaka jest definicja ukończenia?
Agent z kolei rozumuje, układa plan i zaczyna wdrażać. Po wdrożeniu obserwuje: może to być weryfikacja wzrokowa, może odpalenie testów kodu. Cokolwiek oznacza tu sprawdzanie — sprawdzić musi. Potem patrzy na wyniki i pyta: czy spełniłem kryterium ukończenia? Jeśli nie — działa znowu, obserwuje znowu, rozumuje znowu. Jeśli tak — kończy i melduje: drogi człowieku, zrobiłem.
Prawda niewygodna: większość zadań nie potrzebuje pętli
I tu ciekawostka: większość zadań wcale nie potrzebuje pętli. Ja sam buduję jakąś pętlę do większości swoich zadań, ale wyłącznie ze względu na weryfikację — ten element jest kluczowy. Zazwyczaj nie potrzebujesz wielkiej architektury agentów, żeby uruchomić taką dynamiczną, zapętlającą się pracę. Załatwisz to w jednej sesji terminala, z porządnym promptem.
Możesz mieć po prostu solo-pętlę — na tym najczęściej pracuję ja: jeden agent, który rozumuje, działa, obserwuje i powtarza. Możesz mieć układ wykonawca–recenzent: jeden agent robi robotę, a drugi ją ocenia i zwraca uwagi. Możesz wreszcie mieć kierownika z garścią pomocników. Dopóki masz jednego głównego agenta orkiestrującego całość, pętle da się składać na bardzo wiele sposobów.
Demo 1: miniatura w stylu MrBeasta
Pokażę kilka przykładów. Pierwsze dwa pochodzą z biblioteki pętli, którą opublikował Matthew Berman. To lista pętli agentów gotowych do użycia, do których każdy może dorzucić własne — fajne miejsce, żeby po pogrzebać i zobaczyć, co ludzie wymyślili. Stamtąd wziąłem prompty do obu pierwszych demonstracji.
(Informacja dodatkowa: Matthew Berman to znany twórca treści o sztucznej inteligencji; wspomniana „biblioteka pętli” to otwarta, społecznościowa lista gotowych pętli agentów.)
Pierwszy przykład: prompt /goal w Claude Code z poleceniem zrobienia miniatury. Powiedziałem mu w zasadzie tylko, czego użyć. Treść: „Stwórz 10 koncepcji miniatury i oceń każdą, porównując z miniaturami MrBeasta, według rubryki: czytelność w małym rozmiarze, ciekawość, ładunek emocjonalny, kontrast wizualny” — i tak dalej. Po stworzeniu dziesiątki wybiera najlepszą trójkę, wskazuje najsłabszy element każdej koncepcji, poprawia, ocenia ponownie, a potem dalej iteruje na najmocniejszym pomyśle — dopóki nie będzie zadowolony.
I tu wypada zwrócić uwagę na słabość tego promptu: kryterium ukończenia brzmiało „aż będziesz zadowolony”. Czasem subiektywne kryteria oceny są nieuniknione, ale dążyć trzeba do maksymalnej obiektywności. Najlepsze pętle to te, w których możesz dosłownie napisać: iteruj, dopóki metryka X nie osiągnie wartości Y.
Na ekranie widać, jak to przebiegło: powstało dziesięć koncepcji. Agent uznał, że do ścisłej czołówki należą koncepcje pierwsza, druga i ósma — i na nich pracował. Mamy oryginał numeru jeden i jego drugą wersję, oryginał numeru dwa i jego poprawkę, oryginał numeru osiem i jego poprawkę. A kiedy miał już te ulepszone warianty, stwierdził: ósemka jest najlepsza — i zrobił jej trzecią wersję. To właśnie finalna miniatura. Całe zadanie zajęło Claude Code 27 minut.
To szybki przykład pętli w akcji: oceniał każdą koncepcję i na tej podstawie wyłonił zwycięzcę. Haczyk w tym, że te oceny były subiektywne. Gdybym chciał ulepszyć ten proces, poszukałbym sposobu, jak uczynić punktowanie obiektywnym — na przykład stworzyłbym osobnego podagenta, dedykowanego ocenie, napisałbym dla niego prompt i przepuścił go przez serię prób, żeby mieć większą pewność, że jego oceny są wiarygodne.
Demo 2: samolot w three.js
Kolejny przykład to znów /goal. Tym razem 37 minut. Prompt, widać go na ekranie, też pochodzi wprost z biblioteki Bermana — nie będę czytał całości, możesz zatrzymać film i przejrzeć go sam. Rzecz w tym, że zadaniem było zbudowanie samolotu w three.js.
Otwieram: oto obracający się samolot. Można przybliżyć, obrócić, poruszać. Z perspektywy pętli agent musiał go zbudować, a potem zweryfikować: otworzyć przeglądarkę, zakręcić modelem, sprawdzić, czy działa, czy dobrze się renderuje — i tak w kółko, aż wyszła ta wersja.
I wciąż, jak widać, nie jest idealnie — są rzeczy do poprawienia. Chyba miało być przezroczyste, żeby można było zajrzeć do środka. Ale to i tak o klasę lepiej, niż wyszłoby, gdybym zamiast /goal z kryteriami napisał po prostu: zrób mi samolot 3D w three.js. I to jest jeden z kluczowych wniosków całego materiału: pętle agentów i cele nie mają dawać stuprocentowo idealnego wyniku. Mają cię po prostu znacznie bliżej celu doprowadzić już za pierwszym razem.
Demo 3: „Abbey Road” bez generowania obrazów
Jeszcze jeden świetny przykład, znowu w temacie subiektywności. Ostatnie zadanie: prompt /goal, który kazałem napisać Claude Code. Punkt odniesienia: słynne zdjęcie Beatlesów z okładki „Abbey Road”. Polecenie: odtwórz je bez generowania obrazów — czystym HTML-em, CSS-em, czym chcesz. Agent wziął się do pracy: wersja pierwsza, druga, trzecia… i zakończył po wersji siódmej.
W prompcie widać: „Jeśli średnia ocen wynosi dziewięć lub więcej — zatrzymaj się”. To był warunek zakończenia. Był też twardy limit ośmiu przebiegów — i tak czy inaczej agent zbliżał się do tego limitu. Szczerze mówiąc: te obrazy nie są dobre.
Widać jednak, że weryfikacja działała. Za każdym razem, po napisaniu kodu, agent musiał otworzyć go w przeglądarce i zrobić zrzut ekranu. Oto zrzut z wersji pierwszej, z drugiej, trzeciej, czwartej — widać na żywo, jak z każdą iteracją wychodzi coraz lepiej. Ale ostateczna wersja i tak nie ma wiele wspólnego z oryginałem. Są: samochód, drzewa, droga — biel, czerń, ciemna szarość, jasny błękit, dokładnie jak na zdjęciu. Zaraz… czy ja mówiłem o żółci? Chodziło mi o biel. Biel, czerń, ciemna szarość, jasny błękit. No i oczywiście: podobieństwa jak nie było, tak nie ma.
Gdyby sięgnąć po generowanie obrazów, wynik pewnie byłby znacznie bliższy. Ale chciałem sprawdzić, jak to wyjdzie w czystym kodzie. Sedno jest takie: agent miał narzędzia weryfikacji, potrafił robić zrzuty ekranu, przeglądać każdą swoją iterację i odpowiedzieć sobie na pytanie — czemu to wciąż nie wygląda jak obrazek odniesienia i co zmienić w kolejnym podejściu? Dlatego pętla jest dokładnie tak dobra, jak dobre jest jej kryterium ukończenia.
Dwa pytania przed pierwszą pętlą
Zanim zbudujesz pierwszą pętlę albo pierwszy cel, musisz przemyśleć dwie rzeczy: co znaczy „gotowe”? I jak to zostanie sprawdzone?
Bo inaczej weryfikuje się grę na komputerze, inaczej skrypt. Grę trzeba sprawdzić na wielu poziomach: wzrokowo, funkcjonalnie, i trzeba przejść poziomy, żeby zobaczyć, czy coś się nie wysypuje. Skryptu nie trzeba sprawdzać wzrokowo — trzeba sprawdzić rytm, logikę wypowiedzi, to, czy brzmi jak ty, i tak dalej. Weryfikacja zawsze wygląda inaczej, zależnie od tego, co budujesz, i twoim zadaniem jest dopilnować, żeby agent miał do niej odpowiednie narzędzia.
A z drugiej strony: co znaczy „gotowe”? Jak już mówiłem, najlepiej, gdy da się to wyrazić konkretną metryką — tak obiektywnie, jak tylko się da. Czasem się nie da. Czasem trzeba napisać: pracuj, dopóki nie będziesz w stu procentach pewien.
Najczęściej sam sięgam po te pętle przy montażu filmów — używam wtedy Hyperframes w Claude Code. Wrzucam materiał, odpalam /goal i agent robi wszystko: pobiera transkrypcję, wycina błędy i pauzy, tworzy cięcia, synchronizuje je, renderuje, a na koniec przepuszcza całość przez masę weryfikacji — czy wszystkie cięcia mieszczą się w granicach, czy zgadzają się z transkrypcją. I właśnie dlatego tylu ludzi może powiedzieć: „zrobiłem to jednym promptem, za jednym razem”. Bo to była pętla. Bo była weryfikacja i iteracja.
Co sprawia, że pętla działa
Co więc tworzy działającą pętlę? Mierzalny cel. Twarde zatrzymanie. Dobre narzędzia. Pamięć. Osobny recenzent. Planowanie na starcie. Logowanie. No i rachunek ekonomiczny, który się spina.
Bo te pętle potrafią biec bardzo długo. Zwłaszcza gdy cel jest trudny i wymaga wielu iteracji, a kryterium ukończenia jest jeszcze trudniejsze — na tyle, że agent może w ogóle nigdy go nie osiągnąć — to takie zadanie będzie się wlokło godzinami. Miałem kilka pętli, które kręciły się ponad dwanaście godzin, i szczerze mówiąc niewiele mi dały. Zazwyczaj moje dłuższe pętle wyglądają raczej jak te z dzisiejszych przykładów: trzydzieści–czterdzieści minut, może parę godzin. Pętli, która ma mi pracować cztery dni bez przerwy, po prostu nie potrzebuję.
Nie kopiuj ślepo ekspertów
I jeszcze jedna myśl, którą chcę tu przemycić: to, że ktoś taki jak Peter Steinberger coś mówi, nie oznacza, że dotyczy to bezpośrednio ciebie i twojego zastosowania. On jest twardym programistą, buduje agentów, pracuje w OpenAI. W jego sposobie pracy to prawdopodobnie ma duży sens i pewnie pomnożyło jego produktywność kilkukrotnie. A to jest właśnie fajne w AI: ponieważ wcisnie się w każdą branżę i każdą rolę, nie każdy będzie z niego korzystał tak samo. Warto śledzić, co mówią ludzie tacy jak Steinberger — ale nie znaczy to, że masz teraz rzucić wszystko i natychmiast tego próbować. Albo inaczej: może warto spróbować, tylko nie musisz od dziś wpinać tego na stałe w każdą sesję Claude Code.
Perspektywa nieprogramisty
Mówię to wszystko z pozycji osoby spoza programowania. Używam Claude Code cały czas, na okrągło — ale do pracy z wiedzą, a nie do wielkich refaktoryzacji baz danych czy codziennego budowania aplikacji. Tak właśnie widzę te pętle agentów. Widziałem ostatnio o nich mnóstwo treści, więc uznałem, że trzeba się podzielić własnym zdaniem. Niektórzy z was mogą się ze mną nie zgadzać — ale tak ich używam. Używam ich naprawdę, po prostu nie puszczam tych efektownych przebiegów na trzy doby.
Kiedy mam duży cel, często odpalam solidną pętlę przed pójściem spać i budzę się z czymś, co kręciło się cztery, może osiem godzin — i to bywa naprawdę wartościowe. Choć spora część tego to u mnie wciąż eksperymenty: biorę wynik nocnego przebiegu i wrzucam go do kolejnych pętli albo dopracowuję sam, po ludzku.
Więcej szczegółów jest w prezentacji, którą pokazywałem, oraz w pełnym raporcie z audytu — znacznie bardziej rozwlekłym i, nie ukrywajmy, brzydkim. Obie te rzeczy udostępniam w darmowej społeczności; link znajdziecie w opisie filmu. Wejdźcie w zakładkę classroom, potem „wszystkie materiały z YouTube” — wszystko będzie tam na miejscu.
Na dziś to tyle. Jeśli wynieśliście z tego materiału coś nowego, zostawcie łapkę w górę — bardzo mi to pomaga. Jak zawsze dziękuję, że dotrwaliście do końca. Do zobaczenia następnym razem. Dzięki!