# Inżynieria promptów nie żyje. Niech żyje inżynieria pętli.

*Dlaczego szef zespołu Claude Code w Anthropic właśnie ogłosił koniec ery „szeptacza AI” — i co jest dalej.*

> Boris Cherny, który kieruje Claude Code w Anthropic, mówi, że już nie pisze promptów do Claude — pisze pętle. Wewnątrz śmierci inżynierii promptów i narodzin inżynierii pętli: agentowe przepływy pracy AI, autonomiczne, samokorygujące się agenty, dlaczego sędzia liczy się bardziej niż prompt, i jak ta sama pętla jest wpięta w przestrzeń roboczą, którą posiadasz — bramki sprawdzane maszynowo w repozytorium, pamięć, która przeżywa sesję, i panel sterowania, który buduje i potrafi cofnąć.

— Fractera, 2026-06-14

## Cytat, który rozbił iluzję

Kilka dni temu jedno zdanie **Borisa Cherny’ego** — inżyniera kierującego rozwojem **Claude Code** w **Anthropic** — po cichu wstrząsnęło środowiskiem programistów.

Na publicznym panelu Cherny uchylił rąbka tajemnicy, jak naprawdę pracują ze swoimi własnymi modelami ludzie budujący najbardziej wyrafinowaną AI do programowania na świecie. To, co powiedział, nie tylko podważyło status quo — ogłosiło całą powstającą dyscyplinę przestarzałą:

> Już nie promptuję Claude. Mam uruchomione pętle, które promptują Claude i same decydują, co robić dalej. Moją pracą jest pisanie pętli.
>
> — Boris Cherny · Claude Code, Anthropic

Niech to do ciebie dotrze.

Człowiek z obiema rękami na kierownicy najlepszego modelu programistycznego na świecie mówi ci, że puścił kierownicę. Nie siedzi w oknie czatu, szlifując idealny akapit instrukcji. Pisze kod, który zmusza AI do rozmowy z samym sobą, oceny własnych błędów i naprawiania ich wewnątrz zamkniętego, autonomicznego obiegu. Buduje maszynę, która prowadzi model — a potem pozwala jej jechać.

Jeśli nadal spędzasz dni na dopieszczaniu promptów, żeby wyciągnąć z LLM właściwy fragment kodu, jego przekaz jest brutalnie jasny: **optymalizujesz świat, którego już nie ma.**

## Zmiana paradygmatu: od mikrozarządzania do architektury systemów

Żeby zobaczyć, dlaczego to zmiana tektoniczna, spójrz, jak nasza relacja z generatywną AI zmieniła się w zaledwie parę lat.

### Faza 1 — prompt liniowy (człowiek jako wąskie gardło)

Do niedawna cała branża była opętana **inżynierią promptów**. Traktowaliśmy LLM-y jak błyskotliwych, ale łatwo rozpraszających się juniorów. Przepływ pracy był liniowy, kruchy i całkowicie ręczny:

```
piszesz prompt  ─▶  AI pisze kod  ─▶  znajdujesz błąd  ─▶  poprawiasz prompt  ─┐
     ▲                                                                          │
     └──────────────────────────  znowu ręcznie  ◀─────────────────────────────────┘
```

W tym paradygmacie **wąskim gardłem jest człowiek.** Piszesz prompt, czytasz wynik, zauważasz błąd składni, wklejasz go z powrotem do czatu i modlisz się, żeby model nie zapomniał kontekstu pięć kroków później. To wygląda produktywnie. To wyczerpujące, nieskalowalne mikrozarządzanie — i absolutnie nie działa, gdy śpisz.

### Faza 2 — inżynieria pętli (obieg autonomiczny)

To, co opisuje Cherny, to **inżynieria pętli** — przepływy agentowe, w których człowiek całkowicie wychodzi z pętli wykonania. Przestajesz prowadzić samochód. Budujesz tor i pozwalasz maszynie okrążać go samodzielnie.

Zamiast pisać prompt rozwiązujący problem, piszesz programową **pętlę**, która osadza AI wewnątrz zautomatyzowanego cyklu wykonania i weryfikacji:

1. **Cel.** Człowiek ustala jeden cel wysokiego poziomu — „zbuduj ten endpoint API i osiągnij 98% pokrycia testami”.
2. **Działanie.** AI generuje pierwszą wersję kodu.
3. **Weryfikacja.** Zautomatyzowane środowisko — kompilatory, lintery, testy jednostkowe, twoje CI — uruchamia kod i wyłapuje każdy błąd.
4. **Samokorekta.** Przy porażce system przechwytuje ślad stosu, przekazuje go AI jako nową instrukcję i każe spróbować ponownie.

```
ustalasz cel
     │
     ▼
AI pisze kod  ─▶  CI uruchamia wszystkie testy  ─▶  zielono?  ─▶  ✦ dostarczone
     ▲                      │
     │                      ▼  (czerwono)
     └──  AI czyta logi i ponownie pyta samo siebie
```

Pętla działa z prędkością maszyny, przechodząc przez dziesiątki iteracji, samokorygując się i samoleczy, aż spełnione zostaną kryteria weryfikacji. Nigdy nie wpisałeś ani jednej dodatkowej wskazówki. Nie pisałeś promptów — zbudowałeś tor, a model sam przejechał każde okrążenie.

## Prawdziwą umiejętnością nie jest pisanie kodu. Jest nią pisanie sędziego.

Oto część, którą prawie każdy pomija — a to cała gra. Trudną częścią pętli **nie** jest generowanie kodu. Modele są w tym już przerażająco dobre. Trudną częścią jest **to, co decyduje, czy kod jest dobry.**

Daj pętli silnego, bezwzględnego weryfikatora — prawdziwe testy, analizę statyczną, kompilator, który odmawia kłamstwa — a zbiegnie się do czegoś, co naprawdę działa. Daj jej słabego, a ta sama pętla chętnie wyprodukuje nieskończoną rzekę pewnego siebie, pięknie sformatowanego śmiecia, halucynując drogę do zielonego znacznika, który nic nie znaczy.

Więc umiejętnością następnej dekady nie jest rzemiosło promptu. Jest nią **projektowanie weryfikacji** — kuloodporne systemy walidacji, które pozwalają AI bezpiecznie rozmawiać z samym sobą, nie spadając z urwiska. To trudniejszy, rzadszy i o wiele cenniejszy rodzaj inżynierii niż znajdowanie właściwych słów.

## Od filozofii do produkcji: jak zbudowaliśmy pętlę

Podczas gdy reszta świata technologii rozkłada cytat Cherny’ego w mediach społecznościowych, prawdziwe wyzwanie jest mało efektowne: **jak zbudować infrastrukturę inżynierii pętli, która naprawdę działa produkcyjnie — poza wewnętrznymi laboratoriami Anthropic?**

Zamknij pętlę wokół jednego modelu, a szybko trafisz na ściany prawdziwego świata: degradację okna kontekstu, halucynacyjne spirale śmierci i brak pamięci w skali projektu. W [%SITE%](/pl) spędziliśmy ostatni rok, traktując filozofię Cherny’ego nie jako przewidywanie, lecz jako **plan architektoniczny** — i zbudowaliśmy pętlę, na której działa ta przestrzeń robocza.

![Pętla rozwoju: właściciel ustala cel, agent edytuje repozytorium, bramki maszynowe to weryfikują, porażki wracają do agenta jako nowe instrukcje, a panel sterowania buduje, prowadzi dziennik i potrafi cofnąć](media:development-loop-2026.jpg)
*Pętla taka, jaka jest naprawdę wpięta: agent w twoim repozytorium, bramki, które nie kłamią, i panel, który zamyka obieg.*

### Anatomia pętli klasy produkcyjnej

Żeby pętle były realne w prawdziwym oprogramowaniu, trzeba przestać podziwiać model i zacząć budować wokół niego trzy mało efektowne rzeczy — sędziego, pamięć i rękę, która wysyła:

- **Weryfikator, którego nie da się przegadać.** Sędzia to nie drugi model z opinią; to zestaw skryptów, które psują build. Czy sygnały językowe istnieją na każdej publicznej stronie? Czy każdy wpis ma bliźniaka w markdown, którego potrzebuje czytnik AI? Czy jest przywołany obraz, którego nikt nie dodał? Każda kontrola istnieje, bo dokładnie ten defekt kiedyś trafił na produkcję, i każda odpowiada kodem wyjścia, nie akapitem.
- **Pamięć, która przeżywa sesję.** Efekt amnezji jest prawdziwy: piętnaście okrążeń wokół upartego błędu i agent gubi architekturę. Tutaj pamięć nie jest usługą, która może być offline — to pliki obok kodu, które podróżują z repozytorium: instrukcja robocza, lekcje dopisywane w chwili, gdy właściciel coś poprawia, lista antywzorców, potwierdzone przypadki użytkownika. Nowa sesja zaczyna się od ich przeczytania, więc piętnaste okrążenie wie to, czego nauczyło się pierwsze.
- **Akt zamykający, który nie należy do agenta.** Pętla kończy się w panelu sterowania: buduje projekt, prowadzi dziennik wdrożeń i potrafi wrócić do ostatniego działającego builda. Ustawienia, teksty i obrazy zmieniają się tam bez żadnej przebudowy — więc pętli nigdy nie każe się rozwiązywać czegoś, co nigdy nie było problemem kodu.

Zauważ, czego **nie ma** na tej liście: roju modeli nadzorujących się nawzajem. To była nasza pierwsza architektura i ją usunęliśmy. Orkiestracja jest najbardziej ekscytującą częścią diagramu agentowego i najmniej nośną częścią działającego — słabego sędziego nie naprawia druga opinia, a silny rzadko jej potrzebuje.

## Nowy opis stanowiska inżyniera oprogramowania

Odchodzimy od pisania kodu, mijamy pisanie promptów i wchodzimy prosto w **budowanie potoków poznawczych.** Rzemiosłem nie jest już instrukcja — jest nim system, w którym ta instrukcja działa.

I nie jest to za darmo. Wraz z pętlami przychodzą dwa nowe koszty. **Dług zrozumienia:** kiedy agent pisze i przepisuje plik trzysta razy w tle, twoje pojęcie o własnej bazie kodu po cichu zanika — działa, tylko już nie jesteś pewien dlaczego. I **surowe obliczenia:** pętla potrafi spalić prawdziwe pieniądze w tokenach, goniąc jeden błąd przez sto cichych prób. Inżynierowie, którzy wygrywają w tej erze, traktują koszt kontra jakość jako świadomą decyzję projektową, nie niespodziankę na fakturze.

Ta strona jest jedną z tych pętli: strony, które czytasz, to statyczne pliki, których bramka odmówiła wysłania, dopóki nie niosły swoich sygnałów językowych, swojego bliźniaka w markdown i swojego miejsca w mapie strony. — [Zobacz przestrzeń roboczą, na której to działa](/pl)

Era inżynierii promptów oficjalnie jest za nami. Pozostaje tylko jedno pytanie — to samo, na które Cherny już odpowiedział sobie sam: **wciąż próbujesz rozmawiać ze swoją AI — czy już budujesz pętle, które pozwalają jej działać?**

Źródło: szeroko udostępniany post na LinkedIn autorstwa Guillermo Flora, który ujawnił słowa Borisa Cherny’ego. Cytat jest przytoczony tak, jak krążył; architektura i analiza są nasze własne.

## FAQ

### Czym jest „inżynieria pętli” i dlaczego zastępuje inżynierię promptów?

Inżynieria pętli oznacza pisanie zautomatyzowanych przepływów pracy, które promptują AI, przepuszczają jej wynik przez weryfikator (testy, CI, kompilator), zwracają porażki jako nowe instrukcje i powtarzają — aż wynik będzie poprawny. Boris Cherny, który kieruje Claude Code w Anthropic, powiedział, że już nie tworzy promptów ręcznie: pisze pętle, które robią to za niego. Kluczowa obserwacja jest taka, że wąskim gardłem nigdy nie był prompt — był nim człowiek w cyklu sprzężenia zwrotnego.

### Jak jest tu, produkcyjnie, wpięta pętla rozwoju?

Agent programujący pracuje wewnątrz twojego własnego repozytorium, na twojej maszynie, z instrukcją roboczą projektu obok kodu. Weryfikator to zestaw bramek uruchamianych przy każdym buildzie, które go psują: sygnały językowe na każdej publicznej stronie, bliźniak markdown dla każdej opublikowanej strony, brak przywołanego obrazu, który nigdy nie został dodany, brak słownika bez klucza. Porażka wraca do agenta jako nowa instrukcja, a pętla się powtarza. Panel sterowania zamyka obieg — buduje projekt, prowadzi dziennik każdego wdrożenia i potrafi cofnąć się do ostatniego działającego builda.

### Czy muszę umieć programować, żeby uruchomić tę pętlę?

Nie w przypadku większości tego, co strona faktycznie zmienia. Nazwa, opis, obrazy, języki, analityka i teksty ustawień żyją w panelu sterowania i stosują się bez żadnej przebudowy — to dane, nie kod. Zmiany w kodzie robi agent w twoim repozytorium; ty je czytasz i zatwierdzasz, a panel buduje wynik. Uczciwa granica jest taka: nikt nie obiecuje, że nigdy nie spojrzysz na diff — obiecuje się ci, że nigdy nie musisz ręcznie uruchamiać builda, i że zepsuty można cofnąć jednym kliknięciem.