Inference loop: dlaczego kodowanie staje się pętlą, a nie naciśnięciem klawisza

Przez trzydzieści lat pisanie oprogramowania oznaczało produkowanie naciśnięć klawiszy. Trzymałeś model programu w głowie i tłumaczyłeś go, znak po znaku, na plik. Autouzupełnianie przyspieszyło naciśnięcia klawiszy. Copiloci uczynili je mądrzejszymi. Ale jednostka pracy nigdy się nie zmieniła: człowiek pisał kod, a maszyna go uruchamiała.

Ta jednostka właśnie się zmienia. Najważniejszym prymitywem oprogramowania tej dekady nie jest naciśnięcie klawisza — to pętla. Wywołaj model, pozwól mu uruchomić narzędzie, przekaż wynik z powrotem i powtarzaj, aż zadanie zostanie wykonane. Mieści się w około dziesięciu liniach kodu i po cichu pożera tworzenie oprogramowania. Nazwaliśmy od niej naszą firmę: inference loop.

Ten wpis jest o tym, czym ta pętla właściwie jest, dlaczego bije jednorazowy prompt, który zdefiniował pierwszą falę kodowania z AI, gdzie wciąż się rozpada i dokąd zmierza. Jeśli prowadzisz zespół inżynierski i próbujesz oddzielić sygnał od szumu, zacznij tutaj.

Czym właściwie jest agentowa pętla kodowania

Zdejmij branding, a agent kodujący AI jest niemal zawstydzająco prosty. Jak ujmuje to Simon Willison w swoim przewodniku po tym, jak działają agenty kodujące, agent LLM to „coś, co uruchamia narzędzia w pętli, aby osiągnąć cel”. Narzędzie to po prostu funkcja, którą otaczający program — harness — udostępnia modelowi: odczytaj plik, uruchom polecenie powłoki, przeszukaj bazę kodu, wykonaj testy. Model decyduje, które narzędzie wywołać; harness je uruchamia i przekazuje wynik z powrotem.

To cała sztuczka. Pętla wygląda tak:

1. Daj modelowi cel i zestaw narzędzi.
2. Model odpowiada albo rozwiązaniem, albo żądaniem wywołania narzędzia.
3. Harness uruchamia narzędzie i zwraca wynik do modelu.
4. Wróć do kroku 2, aż cel zostanie osiągnięty.

Thorsten Ball słynnie pokazał, że da się zbudować działającego agenta kodującego w kilkuset liniach kodu — bez frameworka, bez silnika orkiestracji, bez bazy wektorowej. Agenty, jak głosi powiedzenie, to „po prostu LLM-y z właściwymi narzędziami w pętli konwersacji”. Powód, dla którego to istotne, jest taki, że odczarowuje całą kategorię. Magia nie tkwi w tajemniczej architekturze. Magia polega na tym, że zdolny model, obdarzony możliwością działania, a następnie obserwowania konsekwencji swojego działania, potrafi przejść przez problem, którego nigdy nie rozwiązałby w jednym podejściu.

Willison idzie dalej w Designing agentic loops, argumentując, że prawdziwą umiejętnością nadchodzących lat jest projektowanie samej pętli: które narzędzia udostępnić, ile autonomii przyznać i jak uruchamiać pętlę bezpiecznie — nawet w tym, co pół żartem nazywa „trybem YOLO”, gdzie agent wykonuje polecenia bez pytania o pozwolenie na każdym kroku. Pętla to nowy model programowania. Dobre jej projektowanie to nowe rzemiosło.

Krajobraz narzędzi 2025–2026

Pętla to prymityw; produkty to harnessy zbudowane wokół niej. Do 2026 roku krajobraz uporządkował się w kilka wyraźnych kształtów.

Claude Code jest agent-first. Żyje w terminalu, ma bezpośredni dostęp do Twojego systemu plików i git, i zakłada, że AI prowadzi, a programista recenzuje. Dajesz mu zadanie, on czyta pliki, edytuje je, uruchamia testy, czyta błędy i próbuje ponownie — krążąc w pętli, aż skończy lub utknie. Rola człowieka przesuwa się od autora do recenzenta.

Cursor obrał przeciwny punkt wejścia: osadzić agenta wewnątrz IDE jako współpracownika, który pracuje obok Ciebie w edytorze, którego już używasz. Te dwie filozofie zbliżają się jednak do siebie — Cursor wydał CLI z trybami agentowymi w styczniu 2026, zbliżając się do modelu natywnego dla terminala, sterowanego przez agenta. Codex, Aider i Cline dopełniają stawkę, każdy obstawiając nieco inaczej, gdzie siedzi człowiek względem pętli.

Zbieżność to właśnie ta historia. Jak dokumentuje przewodnik Sourcegraph po kodowaniu agentowym z 2026 roku, granica nie leży już w pytaniu „czy agent potrafi edytować plik” — leży w uruchamianiu tych pętli na dużych, rzeczywistych bazach kodu, gdzie agent sięga po wyszukiwanie kodu, przekazanie do chmury i długotrwałe zadania w tle. Narzędzia pędzą do tego samego celu różnymi drzwiami: agenta natywnego dla CLI, któremu można powierzyć prawdziwe zgłoszenie i zaufać, że poczyni postęp na prawdziwym repozytorium.

Dlaczego pętla bije prompt

Pierwsza fala kodowania z AI to było generowanie jednorazowe: pisałeś staranny prompt, model produkował blok kodu, a Ty wklejałeś go i modliłeś się. Gdy było źle — złe API, zhalucynowana metoda, subtelny błąd o jeden — zaczynałeś od nowa z lepszym promptem. Model nigdy nie widział, czy jego kod faktycznie działa.

Pętla zmienia to całkowicie, a różnica nie jest przyrostowa. Trzy rzeczy stają się możliwe w chwili, gdy model może działać i obserwować:

Samokorekta. Agent uruchamia kod, widzi stack trace i naprawia własny błąd — dokładnie tak, jak robi to ludzki programista. Model jednorazowy jest ślepy na własne błędy. Agent w pętli ma sprzężenie zwrotne. Może napisać test, obserwować jego niepowodzenie, zmienić implementację i obserwować, jak przechodzi.

Zakotwiczenie w rzeczywistości. Zamiast generować z pamięci o tym, jak biblioteka prawdopodobnie działa, agent czyta faktyczne źródło, grepuje za faktyczną sygnaturą funkcji i sprawdza faktyczne typy w Twojej bazie kodu. Pętla zastępuje pewne siebie zgadywanie tanią weryfikacją.

Dekompozycja w czasie. Trudne problemy nie poddają się jednemu wielkiemu skokowi; poddają się wielu małym, zweryfikowanym krokom. Pętla to maszyna do robienia małych kroków. Agent może eksplorować, uderzyć w ścianę, cofnąć się i spróbować innego podejścia — kumulując postęp przez dziesiątki wywołań narzędzi, zamiast stawiać wszystko na jednej generacji.

To dlatego model ze średniej półki wewnątrz dobrej pętli rutynowo bije frontierowy model odpowiadający w jednym podejściu. Inteligencja nie tkwi tylko w wagach; tkwi w pętli owiniętej wokół nich.

Gdzie dziś się załamuje

Uczciwość jest całym sensem takiego wpisu, więc oto gdzie pętla wciąż się sypie w 2026 roku.

Zadania o długim horyzoncie. Agenty są mocne w zadaniach mierzonych w minutach i dziesiątkach wywołań narzędzi. Zadania mierzone w godzinach — rozległy refaktor przez czterdzieści plików, migracja z subtelnymi ograniczeniami kolejności — wciąż mają tendencję do dryfowania. Agent gubi wątek, robi lokalnie sensowną zmianę, która psuje coś trzy pliki dalej, i nie zawsze potrafi się pozbierać.

Przepełnienie kontekstu. Każda iteracja pętli dokłada do kontekstu modelu: odczytane pliki, wyjście poleceń, wcześniejsze rozumowanie. Na dużej bazie kodu istotne informacje w końcu przekraczają to, co mieści się w oknie, a agent zaczyna zapominać, czego nauczył się dziesięć kroków wcześniej. Zarządzanie tym, co agent pamięta — i co wolno mu zapomnieć — to nierozwiązany, aktywnie opracowywany problem.

Luki w weryfikacji. Pętla samokoryguje się tylko na tyle dobrze, na ile pozwalają jej testy i kontrole. Jeśli Twoja baza kodu ma cienkie pokrycie testami, sygnał zwrotny agenta jest słaby i pewnie ogłosi zwycięstwo na kodzie, który faktycznie nie działa. Śmieci na wejściu sprzężenia, śmieciowa pewność na wyjściu.

Te ograniczenia to właśnie powód, dla którego rozmowa przesuwa się ku harness — rusztowaniu zarządzania kontekstem, weryfikacji i guardrails wokół modelu — oraz ku uczciwym benchmarkom, które mierzą agenty na realnej pracy o długim horyzoncie, a nie na problemach-zabawkach. Pętla jest konieczna, ale niewystarczająca. To, co zbudujesz wokół niej, decyduje, czy będzie demem, czy niezawodnym kolegą.

Dokąd to zmierza

Wyceluj obecną trajektorię w przyszłość, a trzy rzeczy nabierają ostrości.

Dłuższe autonomiczne przebiegi. W miarę jak poprawia się zarządzanie kontekstem, a modele lepiej trzymają się zadania, niezawodny horyzont rozciąga się z minut ku godzinom. Agentowi, któremu dziś powierzasz błąd, jutro powierzysz funkcję.

Równoległe podagenty. Zamiast jednego agenta mielącego zadanie szeregowo, koordynator wywołuje kilka podagentów — jeden eksploruje bazę kodu, jeden pisze testy, jeden implementuje — które pracują równolegle i raportują z powrotem. Pętla staje się drzewem pętli.

Programista jako dyrygent. To najgłębsza zmiana, a Addy Osmani trafnie ją nazywa w Coding for the Future Agentic World: programiści ewoluują od „koderów” do „dyrygentów”. Twoja wartość przesuwa się w górę drabiny abstrakcji — od pisania linii do specyfikowania celu, projektowania pętli, recenzowania wyniku i posiadania osądu o tym, czy rezultat jest faktycznie poprawny. Naciśnięcie klawisza nigdy nie było tą wartościową częścią. Wartościowe było myślenie. Kodowanie agentowe zdziera pisanie i pozostawia myślenie obnażone.

To nie zagrożenie dla dobrych inżynierów. To awans. Praca, która pozostaje, to praca, która zawsze była sednem: zrozumieć problem na tyle głęboko, by wiedzieć, co oznacza „gotowe”, i mieć gust, by to rozpoznać, gdy się to widzi.

Podsumowanie

Naciśnięcie klawisza miało trzydziestoletni przebieg. Zastępuje je pętla, która mieści się w dziesięciu liniach — wywołaj model, uruchom narzędzie, przekaż wynik z powrotem, powtórz. Ta pętla jest na tyle prosta, by zbudować ją w popołudnie, i na tyle potężna, by przemodelować sposób, w jaki powstaje oprogramowanie. Bije jednorazowy prompt, bo potrafi działać, obserwować i korygować. Wciąż załamuje się na pracy o długim horyzoncie i słabej weryfikacji. I zmierza, szybko, ku dłuższym przebiegom, równoległym agentom i programiście, którego zadaniem jest dyrygować, a nie pisać.

To pętla, wokół której budujemy biznesy. Jeśli Twój zespół próbuje rozgryźć, gdzie kodowanie agentowe faktycznie pasuje — które zadania powierzyć pętli, jak zbudować wokół niej harness i guardrails oraz jak utrzymać inżynierów na fotelu dyrygenta — to właśnie ta praca, którą wykonujemy.

Porozmawiaj z nami o wprowadzeniu agentowych pętli kodowania do pracy Twojego zespołu.