Nazwaliśmy tak naszą firmę: loop engineering pożera tworzenie oprogramowania

W wywiadzie z połowy 2026 roku inżynier, który stworzył Claude Code w Anthropic, Boris Cherny, opisał, jak zmieniła się jego własna praca. Warto zacytować to sformułowanie w całości, bo robi więcej, niż się wydaje:

„Teraz to się znowu awansowało, jak sądzę, do kolejnej fali abstrakcji, w której już nie promptuję Claude’a. Mam pętle, które działają. To one promptują Claude’a i wymyślają, co robić. Moim zadaniem jest pisanie pętli.”

Klip rozszedł się szybko. W ciągu kilku dni miał nazwę — loop engineering — spopularyzowaną przez dosadne jednozdaniowe ujęcie Petera Steinbergera, że praca przesunęła się z promptowania agentów ku projektowaniu pętli, które je promptują, które samo zebrało miliony wyświetleń. Kiedy osoba, która zbudowała jeden z najczęściej używanych agentów kodujących na świecie, mówi Ci, że przestała go promptować, to nie jest porada o produktywności. To opis stanowiska całej branży zmieniającej się pod własnymi stopami.

Mamy w tym szczególny udział. Nasza firma nazywa się Inference Loops. Wybraliśmy tę nazwę, zanim termin „loop engineering” w ogóle istniał, na zakładzie o to, dokąd zmierza wartość w oprogramowaniu agentowym. To jest wpis, w którym możemy powiedzieć: zakład wszedł.

Śmierć ery promptu

Przez jakieś dwa lata dominującą umiejętnością w AI było promptowanie — rzemiosło formułowania pojedynczego żądania na tyle dobrze, by uzyskać dobrą pojedynczą odpowiedź. Prompt engineering doczekał się przewodników, ogłoszeń o pracę i drobnego kapłaństwa. I przez pewien czas była to prawdziwa praca. Ale zauważ, co zakładała: człowieka wewnątrz pętli, czytającego każdy wynik i decydującego, co wpisać następnie. Prompt był interfejsem, a Ty byłeś systemem sterowania. Każda iteracja przechodziła przez Twoją klawiaturę i Twoją uwagę.

Zdanie Cherny’ego znaczy koniec tego układu. Kolejna fala abstrakcji to nie lepszy prompt — to wyjęcie człowieka z decyzji podejmowanej tura po turze i zastąpienie go programem. Pętla czyta wynik, sprawdza go względem celu, decyduje, co zrobić dalej, i promptuje model na nowo, wszystko bez osoby w rozmowie. Prompt nie zniknął; został wygenerowany przez pętlę zamiast wpisany przez Ciebie.

To przeramowanie to cała zmiana w jednym ruchu. Prompt nigdy nie był jednostką pracy. Był zastępnikiem pętli, której jeszcze nie zbudowaliśmy. Dopóki modele były słabe, a użycie narzędzi kruche, człowiek musiał zastępować brakującą logikę sterowania — czytając na nowo, sterując na nowo, łapiąc błędy. Gdy modele stały się na tyle dobre, by zaufać im wewnątrz cyklu sprzężenia zwrotnego z weryfikowalnym celem, ten zastępnik o ludzkim kształcie stał się wąskim gardłem. Loop engineering to to, co robisz, gdy już wyjmiesz ten zastępnik.

Czym właściwie jest pętla — i dlaczego napisanie jej to ta trudna część

Pętla, mechanicznie, jest niemal żenująco prosta: wyzwalacz ją uruchamia, agent działa, coś sprawdza, czy cel został osiągnięty, a cykl się powtarza albo zatrzymuje. Rozłożyliśmy tę strukturę szczegółowo wcześniej, we wpisie o wzorcu pętli agenta — cyklu zaplanuj, działaj, obserwuj, zweryfikuj, który zamienia pojedyncze wywołanie modelu w system, który wykonuje pracę.

Pułapką jest myślenie, że trudność leży w instrukcji while. Nie leży. Instrukcja while jest trywialna. Trudne są dwie rzeczy, które człowiek dawniej dostarczał instynktownie:

• Weryfikowalny cel. Pętla musi wiedzieć, mechanicznie, czy odniosła sukces — zaliczony test, zielone CI, spec zgodny z wynikiem. To ten sam wymóg, który sprawia, że reinforcement learning działa, i ten sam, który go łamie, gdy go brakuje: pętla bez sprawdzalnej nagrody albo ogłasza fałszywe zwycięstwo, albo miele w nieskończoność. Większość inżynierii w dobrej pętli leży w zdefiniowaniu „skończone” na tyle precyzyjnie, by maszyna mogła to sprawdzić.
• Warunek zatrzymania. Wiedza o tym, kiedy przestać — kiedy praca jest naprawdę skończona, kiedy agent utknął i powinien eskalować, kiedy pali tokeny, chodząc w kółko — to osąd zakodowany jako kod. Pomyl się w jedną stronę, a pętla zatrzyma się w połowie; pomyl się w drugą, a nie zatrzyma się wcale.

Te dwie rzeczy to miejsce, gdzie mieszka rzemiosło, i są dokładnie tymi częściami, które nie przychodzą z lepszego modelu. Przychodzą ze zrozumienia problemu na tyle dobrego, by powiedzieć, co znaczy poprawne i kiedy przestać. Dlatego wciąż upieramy się, że trwała wartość siedzi w strukturze wokół modelu, a nie w samym modelu — argument, który postawiliśmy, mówiąc, że harness jest produktem. Model jest coraz bardziej towarem, który wynajmujesz. Pętla to rzecz, którą budujesz, i jest Twoja.

Dlaczego nazwaliśmy firmę Inference Loops

Kiedy wybieraliśmy nazwę, rozumowanie było wbrew prądowi. Cały rynek był zahipnotyzowany modelami — które laboratorium ma największy, który benchmark drgnął, które API jest najtańsze za token. Naszym zakładem było, że model się utowarowi, a pętla wokół niego będzie tym, gdzie praca naprawdę się wykonuje i gdzie naprawdę mieszka wyróżnienie. Inferencja bez pętli to sztuczka imprezowa: sprytna odpowiedź na jedno pytanie. Inferencja wewnątrz pętli to system, który dostarcza funkcje przez noc, recenzuje każdy pull request, prowadzi migrację dalej, gdy śpisz.

Cytat Cherny’ego to ten zakład wypowiedziany przez osobę o największym autorytecie, by go wypowiedzieć. „Moim zadaniem jest pisanie pętli” to, niemal słowo w słowo, teza, którą koduje ta nazwa. Nie przewidzieliśmy, że to powie — ale zbudowaliśmy się wokół tej samej obserwacji: pętla jest jednostką wartości w oprogramowaniu agentowym. Wszystko nad pętlą (orkiestrowanie wielu z nich) i pod nią (harness, model) ma znaczenie ze względu na to, co robi dla pętli. Nazwij firmę od warstwy, gdzie wartość się koncentruje, a jesteś zmuszony trzymać tam uwagę nawet wtedy, gdy rynek krzyczy o czymś bardziej błyszczącym.

Co się zmienia, gdy pętla jest jednostką pracy

To nie tylko słownictwo. Traktowanie pętli jako prymitywu zmienia to, co budujesz i jak to mierzysz.

Projektujesz sprzężenie zwrotne, a nie sformułowanie. Pytanie przestaje brzmieć „jak sformułować to żądanie?”, a staje się „jaki sygnał mówi tej pętli, że jest na właściwym torze, i jakie narzędzia pozwalają jej działać na podstawie tego sygnału?”. To pytanie o projektowanie systemów i o wiele trwalsza umiejętność niż dobieranie słów.

Inwestujesz w weryfikację, a nie tylko w generowanie. W erze promptu jakość wyniku była ograniczona przez model i Twoją cierpliwość. W erze pętli jest ograniczona przez Twoją weryfikację. Pętla może być tylko tak dobra, jak jej zdolność do sprawdzania samej siebie — co oznacza, że najwyższa dźwignia inżynierska przesuwa się od sprawiania, by agent generował, ku sprawianiu, by pętla oceniała. Jakość fazy weryfikacji to sufit jakości całego systemu.

Myślisz flotami, a nie sesjami. Gdy pojedyncza pętla działa niezawodnie, naturalnym kolejnym ruchem jest wiele z nich — równolegle, według harmonogramu, w potokach. Jedna pętla naprawia co noc niestabilne testy, druga porównuje specyfikacje z implementacjami, trzecia segreguje zgłoszenia. Rola człowieka znów się podnosi, z pisania jednej pętli do orkiestrowania wielu. Ale wszystko to opiera się najpierw na tym, by pętla była godną zaufania jednostką.

Wątek przewodni: praca programisty migruje od produkowania kodu do produkowania systemów, które produkują kod. To nie jest mniejsza praca. To praca o większej dźwigni, i nagradza inny mięsień — osąd dotyczący celów, weryfikacji i warunków zatrzymania, a nie szybkość pisania.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która znaczy dla nas najwięcej, i to najbardziej zachęcająca implikacja całej tej zmiany. Loop engineering to umiejętność, a nie nakład kapitałowy.

Droga, kapitałochłonna warstwa tego stosu — pretraining frontierowych modeli — to dokładnie ta warstwa, która utowarawia się w wynajmowane API. Warstwa, do której przesuwa się wartość — pętla — działa na osądzie: zdolności zdefiniowania weryfikowalnego celu, zaprojektowania cyklu sprzężenia zwrotnego i rozpoznania, kiedy praca jest skończona. Ten osąd nie wymaga klastra GPU ani tysiącosobowej organizacji. Wymaga zrozumienia problemu na tyle głęboko, by zakodować „poprawne” w kod. Loop engineer w Phnom Penh czy Dżakarcie, wynajmujący ten sam model i uruchamiający ten sam harness co ktoś w San Francisco, konkuruje na warstwie, gdzie wynik rozstrzyga talent — a nie na warstwie, gdzie rozstrzyga kapitał.

Wersję tego argumentu dla praktyka rozłożyliśmy w całości — trójwarstwowy model i dlaczego to najlepszy zakład na umiejętność, jaki regionalny programista może postawić — we wpisie o tym, co loop engineering oznacza dla programistów z Azji Południowo-Wschodniej. Krótka wersja jest taka, że to najbardziej wyrównane boisko, jakie oprogramowanie zaoferowało regionowi od pokolenia. Nacisk na juniorską pracę implementacyjną jest realny, a loop engineering jest odpowiedzią na niego, a nie jego ofiarą: ogromnie zwielokrotnia wynik jednego programisty, jest przenośny i da się go nauczyć bez frontierowego budżetu.

Więc gdy twórca Claude Code mówi, że jego praca to teraz pisanie pętli, nie słyszymy ciekawostki z wywiadu z Doliny Krzemowej. Słyszymy nazwę naszej firmy odczytaną nam z powrotem jako ogólnobranżowe stanowisko — i słyszymy otwarcie dla każdego inżyniera w tym regionie, który wolałby konkurować osądem niż mocą obliczeniową.

Era promptu się kończy. Era pętli jest tutaj i ma nazwę. Budowaliśmy pod nią przez cały czas.

Jeśli Twój zespół uczy się inżynierować pętle — albo chce inżynierów, którzy już to potrafią — porozmawiajmy.