O czym jest ten film
- Trzy osoby z OpenAI zbudowały wewnętrzny produkt w około jednej dziesiątej czasu, jaki zająłby on przy pracy ręcznej: ok. 1500 pull requestów i ponad milion linii kodu, z czego ani jednej linii nie napisał człowiek.
- Przy tak długich uruchomieniach wielki plik instrukcji przestaje pomagać — wypiera zadanie i zamienia się w „cmentarzysko nieaktualnych reguł”.
- Rozwiązaniem OpenAI była krótka mapa zamiast wielkiego podręcznika: wskaźniki do aktywnych planów, logów decyzji, dokumentów projektowych i mapy architektury.
- Anthropic doszedł do bliźniaczej praktyki: plik postępu jako pamięć przenośna między sesjami, z zapisem stanu, ukończonych prac oraz nieudanych podejść wraz z przyczyną porażki.
- Autor nazywa tę praktykę „progresywnym kształtowaniem kontekstu”: zaczynasz od jasnego briefu, ale potem zmieniasz mały zestaw instrukcji rządzących tym, co ma się stać dalej.
- Przykład Arise: agent wykonał 27 wywołań modelu, prawie wszystkie na przestawianie własnej listy zadań. Naprawą było wyniesienie planu poza okno rozmowy — na dysk — i doklejanie go przed zaszumioną historią.
- Cztery warstwy kontekstu warte rozdzielenia: stała instrukcja, bieżący stan projektu, mapa materiałów, historia.
- Własny projekt autora (benchmark: 339 źródeł, ponad 1000 pytań, 250 zweryfikowanych odpowiedzi) utknął, bo pierwotna instrukcja o ciągłym testowaniu przestała być właściwa — pomogła dopiero zmiana stanu, nie zmiana promptu.
- Badanie Anthropic na ok. 400 tys. sesji Claude Code: człowiek podejmuje ok. 70% decyzji planistycznych, Claude ok. 80% decyzji wykonawczych.
- OpenAI odkryło, że inżynier komfortowo ogarnia tylko 3–5 równoległych sesji Codeksa; przeniesienie pracy na tablicę zadań (Symphony) podniosło w części zespołów liczbę zmergowanych PR-ów o 500% w pierwsze trzy tygodnie.
Redakcyjne tłumaczenie
Milion linii, których nikt nie napisał
Trzej inżynierowie w OpenAI dostarczyli wewnętrzny produkt mniej więcej w jednej dziesiątej czasu, jakiego wymagałaby praca ręczna. Około 1500 pull requestów. Zanim skończyli, baza kodu przekroczyła milion linii. Ani jedna z nich nie została napisana przez człowieka.
Kilka dni temu nagrałem materiał, w którym przekonywałem, że jeśli chcesz od agenta użytecznej pracy, musisz trzymać jego biurko w porządku. Tutaj to ciągnę dalej, ale mówię o najbardziej ambitnych rzeczach, jakie dziś robimy z agentami: o pracy długodystansowej, rozłożonej na wiele sesji, na sześć, osiem, dziesięć godzin i więcej. Powiem, na czym polega sekret dobrych inżynierów i budowniczych zarządzających takimi sesjami — i podpowiem od razu, że nie chodzi wyłącznie o metaforyczne sprzątanie biurka.
Zanim przejdę do konkretów, chcę dać zasadę, żebyś rozumiał, dlaczego to działa — niezależnie od tego, czy pracujesz z Codeksem, czy z Claude’em.
Pojedyncze uruchomienia Codeksa w tamtym zespole trwały ponad sześć godzin bez przerwy, a czasem dłużej. I w trakcie zespół napotkał problem z kontekstem, który rozpozna każdy, kto puszcza agenty. Gigantyczny plik instrukcji podany agentowi na taki przebieg wypycha z pola widzenia samo zadanie, a wielki podręcznik całego projektu zamienia się — mówiąc ich słowami — w cmentarzysko nieaktualnych reguł. Innymi słowy: jak nadać agentowi kierunek przy ogromnym projekcie tak, żeby reguły tego projektu same go nie przytłoczyły?
Pod koniec tego materiału będziesz wiedzieć, jak zaczynać takie długie projekty, zanim poznasz każdy krok; jak zmieniać kierunek bez restartowania wszystkiego; i jak sprawić, żeby korekta dosięgła pracy, której agent jeszcze nie wykonał — czyli jak sterować w locie.
Sprawniejsze agenty zwiększają zasięg twojego osądu. Zwiększają też koszt pozostawienia u steru osądu nieaktualnego. Metoda działa w Claude, w Codeksie i w zwykłych długich rozmowach z AI, bo stan bieżący może przeżyć każdą pojedynczą sesję. Uważam, że to ważniejsze niż nagłówkowa liczba opisująca rozmiar okna kontekstowego, bo zmienia to, co możesz bezpiecznie wprawić w ruch.
Krótka mapa zamiast wielkiego podręcznika
OpenAI zastąpiło ów gigantyczny podręcznik bardzo krótką mapą. Mapa kierowała Codeksa ku aktywnym planom wykonawczym, ku logom decyzji, ku dokumentom projektowym, ku mapie architektury i ocenom jakości dla każdej dotykanej części kodu. W miarę rozwoju produktu te materiały się zmieniały, więc tworzyły wierny obraz bieżącego stanu prac przy przebudowie ogromnej bazy kodu. Agent nie potrzebował, by wszystkie stare instrukcje walczyły o jego uwagę. Potrzebował niezawodnego sposobu odnalezienia najlepszej aktualnej informacji do kolejnego kawałka pracy.
Anthropic doszedł do podobnej praktyki z Claude’em. W pracach nad długotrwałymi obliczeniami naukowymi Claude Code używa pliku postępu jako przenośnej pamięci między sesjami. Plik zapisuje stan bieżący, ukończoną pracę, znane ograniczenia oraz nieudane podejścia wraz z powodem porażki. Dzięki temu nowa sesja może go przeczytać, podjąć następne zadanie i nie wchodzić po raz kolejny w tę samą ślepą uliczkę. Ten sam wzorzec — plik postępu, ustrukturyzowane przekazania i historia wersji — Anthropic stosuje w swoim harnessie do długo działającego kodowania agentowego.
(Informacja dodatkowa: „harness” to warstwa sterująca wokół modelu — pętla, która uruchamia agenta, podaje mu narzędzia i pilnuje przebiegu pracy.)
To różne firmy i różne systemy, ale reagują na tę samą zmianę. AI przechodzi od produkowania odpowiedzi do prowadzenia pracy, która rozwija się przez godziny, dni i wiele osobnych uruchomień. Gdy to następuje, kontekst nie może pozostać zamrożoną paczką z początku zadania, wystrzeloną w rakiecie. Tak to nie działa. Kontekst musi się zmieniać w miarę, jak praca uczy cię, czym to zadanie naprawdę jest.
Stawka jest wysoka. Długo działający agent potrafi ponieść użyteczny kierunek znacznie dalej niż chatbot. Ale potrafi też ponieść kierunek lekko błędny przez sześć godzin researchu, kodu, analiz i szkiców, zanim zorientujesz się, jak bardzo zboczyłeś z kursu.
Progresywne kształtowanie kontekstu
Nazywam tę praktykę progresywnym kształtowaniem kontekstu. Zaczynasz od jasnego briefu, oczywiście, ale potem zmieniasz ten niewielki zestaw instrukcji i decyzji, który ma rządzić tym, co wydarzy się dalej. Gdy praca produkuje kolejne dowody, ten mały stan bieżący dostaje pierwszeństwo przed wszystkim, co działo się po drodze.
Dobra inżynieria promptu nadal ma znaczenie. Mocny prompt otwierający powinien definiować oczekiwany rezultat, wskazywać materiały, z których agent może korzystać, wyznaczać granice tego, co wolno mu, a czego nie, i podsuwać sensowny pierwszy ruch. Jeśli wiesz, jak wygląda jakość, powiedz to w instrukcji. Jeśli publikacja, wydatek, usunięcie czegoś albo kontakt z inną osobą wymagają zatwierdzenia, to też trzeba spisać. Prompt otwierający daje agentowi dość kierunku, by zacząć użyteczną pracę, i ustawia podstawowe barierki ochronne.
Ale prompt otwierający powstaje, zanim praca się zacznie. Może wyrazić tylko to, co wiesz w tamtym momencie. Poważny projekt produkuje informacje po drodze. Research może osłabić twoją pierwotną tezę. Pierwsza implementacja może odsłonić zależność, która zmienia architekturę. Dowody od klientów mogą wskazywać na inny przypadek użycia. Pierwszych pięćdziesiąt wyników może ujawnić, że twoje pierwotne polecenie wyprodukuje ogrom objętości i znikomą wartość — a zatem że całość nie jest tym, czego chciałeś.
W tym momencie zadaniem nie jest obrona pierwotnego promptu ani uparte brnięcie naprzód. Zadaniem jest zmienić to, co agent traktuje jako aktualną wersję zlecenia. I tu prompting przestaje przypominać składanie zamówienia, a zaczyna przypominać kierowanie pracą.
Robię to w bardzo różnych narzędziach. Czasem przerywam Claude Code w trakcie. Steruję Codeksem po przejrzeniu wyniku albo pozwalam projektowi rozwijać się przez kilka tur w Claude lub ChatGPT. Zmienny stan trzymałem w pliku markdown, w planie, w JSON-ie, w trackerze zgłoszeń i w starannie aktualizowanej rozmowie. Konkretny pojemnik ma znacznie mniejsze znaczenie niż to, czy następne działanie dostanie zaktualizowany stan.
Przykład Arise: plan poza oknem rozmowy
Jeden z najczystszych publicznych przykładów pochodzi od Arise. Ich agent, Alex, miał podsumować wiele śladów wykonania. Podczas pewnego pamiętnego przebiegu wykonał 27 wywołań modelu — i niemal wszystkie poszły na reorganizowanie własnej listy zadań. Przekładał informacje z miejsca na miejsce, nie kończąc zlecenia. Czasem to brzmi bardzo znajomo, prawda?
Pierwotne polecenie zostało pogrzebane pod wyjściami z narzędzi, wynikami pośrednimi i własną aktywnością agenta. Arise nie rozwiązało tego przez dodanie bardziej stanowczego zdania na górze promptu. Zespół wyniósł bieżący plan całkowicie poza okno rozmowy i zapisał go na dysku. Przy każdym wywołaniu modelu system odbudowywał krótką wiadomość z planem na podstawie najświeższego stanu i umieszczał ją przed zaszumioną historią. Agent widział, co zrobione, co w toku i co dalej.
Przykład Arise oddziela zapis dotychczasowej pracy od kontekstu bieżącego. To naprawdę ważne — to jak ustawienie znaków drogowych na przedzie. Transkrypt wciąż zawierał realne informacje, ale utrzymywany plan miał znacznie większy autorytet niż sterta zdarzeń. Arise dało agentowi aktualną odpowiedź na bardzo praktyczne pytanie: biorąc pod uwagę wszystko, co się wydarzyło, co powinienem robić teraz?
Plik current.md w praktyce
To bardzo bliskie temu, jak używam pliku current.md we własnym workflow. To zwykły plik, nie funkcja Claude’a czy Codeksa. Każdy może go użyć — ty i agent musicie się tylko umówić, że będziecie go trzymać w aktualności.
W Claude Code plik claude.md może kazać Claude’owi przeczytać go na starcie zadania i aktualizować po każdej istotnej decyzji. W Codeksie tę samą instrukcję poniesie agents.md albo samo zadanie. W zwykłym czacie możesz dołączyć lub wkleić bieżący stan, gdy zaczynasz nową rozmowę.
W zwyczajnej rozmowie z Claude’em czy ChatGPT ta praktyka przybiera dwie formy. Dopóki wątek jest użyteczny, sterujesz nim wprost. A kiedy jakaś decyzja musi przetrwać, musi wykroczyć poza bieżący czat — prosisz o zastępczy brief projektu odzwierciedlający nowy stan, czytasz go, poprawiasz i przenosisz do następnej rozmowy. Stary wątek staje się historią, a brief mówi, co jest prawdą dzisiaj.
Nie musisz zachowywać w ten sposób każdej korekty. Zapisuj zmianę tylko wtedy, gdy wpływa na cel przebiegu albo na definicję ukończenia. Jeśli zirytowałoby cię, że świeżo uruchomiony agent przeoczy jakąś decyzję, to ta decyzja powinna trafić do stanu projektu — samodzielnie albo rękami agenta. Jeśli natomiast służy jedynie wyjaśnieniu, jak do czegoś doszedłeś, prawdopodobnie tam nie należy; jej miejsce jest w historii.
Inne agenty kodujące wystawiają reguły projektu albo pliki instrukcji, które mogą wskazywać na ten sam rodzaj stanu, a system wieloagentowy może użyć zgłoszenia, rekordu JSON albo bazy danych. System Symphony w OpenAI używa tablicy projektowej do definiowania i śledzenia realnej pracy. Czy mechanizmem jest markdown, czy zgłoszenie w Linearze — kolejne działanie agenta musi przeczytać zaktualizowaną decyzję.
Kiedy stara instrukcja zaczyna szkodzić — projekt autora
Wartość tego nauczyłem się w długim własnym projekcie na Codeksie. Budowałem benchmark na dużym zbiorze moich własnych materiałów. Przebieg odkrył 339 różnych źródeł, wygenerował ponad tysiąc pytań i wyprodukował 250 zweryfikowanych odpowiedzi. To był realny postęp.
A potem delegowany agent zaczął raz po raz wznawiać sam siebie przy synchronizacji pakietów. Wciąż był aktywny, ale przestał dodawać cokolwiek wartościowego. Pierwotny cel zachęcał do ciągłego testowania obciążeniowego i wcześnie w przebiegu ta instrukcja pomagała agentowi iść naprzód. W pewnym momencie stała się jednak instrukcją błędną. Użytecznym kolejnym ruchem nie było generowanie następnych pytań ani podtrzymywanie pętli kontynuacji — było nim pogłębienie dowodów stojących za najcenniejszymi odpowiedziami, a potem zatrzymanie się.
Zatrzymałem więc przebieg i zmieniłem stan. Zapis mówił, że projekt został zaczekpointowany po pętli ponawiania, i zabraniał wznawiania nieograniczonego przebiegu. Kolejne przejście miało wybrać 50 najcenniejszych odpowiedzi, zastąpić dowody ogólne dowodami właściwymi dla konkretnego pytania, zwalidować pakiet i zakończyć pracę. Cała dotychczasowa robota pozostała dostępna, tyle że pod nowym kierunkiem.
To jest progresywne kształtowanie kontekstu w realnym projekcie. Utknąłem, bo stara instrukcja pchała agenta w stronę nieprzydatną z punktu widzenia mojego celu. Następny przebieg potrzebował innej pracy. Zmieniłem więc stan, który agent miał odziedziczyć, i zamieniłem otwarte zadanie generacyjne w zadanie ściśle ograniczone, które miało po prostu domknąć temat. W efekcie dostałem tysiąc pytań, 250 odpowiedzi i mapę źródeł, która nadal jest użyteczna — czyli dokładnie to, co miało dla mnie największą wartość.
Pożyteczne zapominanie
Przykład Anthropic z obliczeń naukowych pokazuje ten sam ruch w mniejszej skali. W jednym projekcie solvera notatki postępu odnotowują, że próbowana metoda okazała się zbyt sztywna, i nazywają metodę, która ją zastąpiła. Nowa sesja Claude’a nie musi przeżywać od nowa całej nieudanej próby. Widzi porażkę i idzie dalej. Potrzebuje tylko konsekwencji: to podejście zawiodło z tego powodu, użyj tego zamiennika, kontynuuj od bieżącego stanu.
(Informacja dodatkowa: solver to program numerycznie rozwiązujący równania; „zbyt sztywny” — ang. stiff — to techniczny opis układu równań, przy którym dana metoda całkowania staje się niestabilna lub kosztowna.)
Tak wygląda pożyteczne zapominanie u agentów. System nie kasuje śladu starej próby — historia może zostać w jakimś changelogu — ale nieudana metoda nie ma tej samej pozycji co aktywny plan. Agent niesie ze sobą lekcję, nie niosąc każdego tokenu, który tę lekcję wyprodukował, i nie gubiąc się przy tym po drodze.
Cztery rodzaje kontekstu
Warto rozdzielić cztery rodzaje kontekstu.
Pierwszy: stała instrukcja. Jak pracować, gdzie czego szukać, jakie działania wymagają zatwierdzenia i jakie standardy obowiązują. Claude może to czytać z claude.md, Codeks z agents.md, inne narzędzie nazwie to regułami projektu.
Drugi: bieżący stan projektu. Co cel oznacza teraz, które decyzje są aktywne, co pozostaje nierozstrzygnięte, co ma się stać dalej i kiedy agent naprawdę ma się zatrzymać. To materiał często się zmieniający; może mieszkać w pliku markdown, w zgłoszeniu, w danych strukturalnych. I to coś innego niż lista działań wymagających zgody — to nie barierki, tylko kondycja celu.
Trzeci: mapa. Jakie materiały istnieją i gdzie leżą. Jak agent ma sięgnąć po zasoby: pliki researchowe, dokumenty projektowe, transkrypty, wcześniejsze szkice. Agent nie potrzebuje tego wszystkiego przed sobą. Potrzebuje pewnego sposobu na odnalezienie tego fragmentu, który ma znaczenie dla następnej decyzji. Większość ludzi pomija tę warstwę — i właśnie dlatego kończą, wklejając wszystko naraz. Zdarzyło ci się?
Czwarty: historia. Co było wcześniej, co się zmieniło, dlaczego zapadła jakaś decyzja i jak odzyskać wcześniejszą wersję. Git, changelog, log decyzji, transkrypty. Historia ma znaczenie, ale nie może udawać bieżących instrukcji. Trzymamy ją więc jako osobny zbiór danych, do którego agent może sięgnąć.
Dokładnie tego rozdzielenia użyło OpenAI w tym milionlinijkowym projekcie. Krótki agents.md mapował repozytorium, aktywne plany wykonawcze niosły postęp i logi decyzji, a dokumenty projektowe i architektoniczne trzymały głębszą wiedzę. Zespół uruchamiał nawet cykliczne zadania wyszukujące przeterminowaną dokumentację i aktualizujące ją na bieżąco. Zamiast wciskać milion linii w jeden prompt, dali agentowi sposób na lokalizowanie aktualnej wiedzy w miarę rozwoju produktu.
To samo Anthropic zrobił dla świeżych sesji Claude’a. Inicjalizator przygotowywał środowisko pracy i plik postępu. Późniejsze sesje czytały postęp, sprawdzały historię wersji, wybierały niedokończoną pracę, wprowadzały przyrostową zmianę i zostawiały zaktualizowany stan dla kolejnej. To po prostu dobra higiena pracy z agentami.
Cztery miesiące później Anthropic przebudował ten harness. Porzucili całe rusztowanie sprintów, bo nowszy model nie potrzebował już dzielenia pracy na kawałki — ale zachowali ustrukturyzowane przekazanie między sesjami, bo ono nadal było konieczne. Rusztowanie okazało się jednorazowe i znika wraz z rozwojem agentów; stan bieżący nie. Przekazanie jest częścią pracy, bo długi projekt — niezależnie od tego, jak wielkie staną się agenty — nie może zależeć od tego, że jedna rozmowa będzie żyć wiecznie.
Podział ról: kto decyduje
Badanie Anthropic na mniej więcej 400 tysiącach sesji Claude Code czyni rolę człowieka znacznie wyraźniejszą. W typowej sesji osoba prowadząca podejmowała około 70% decyzji planistycznych, a Claude około 80% decyzji wykonawczych. Wynik dotyczy konkretnie Claude Code, ale sam podział to użyteczna reguła kciuka.
Człowiek nie musi już relacjonować każdej zmiany w pliku ani każdej komendy — i każdy, kto pracuje z agentami, powie ci, że tego nie robi. Człowiek decyduje, co należy zbudować, co oznaczają nowe dowody i co liczy się jako ukończone. Steruje agentem, a agent obsługuje większość drogi między tymi decyzjami.
Progresywne kształtowanie kontekstu jest tym, dzięki czemu decyzje planistyczne przeżywają przerwy między kontrolami. Jeśli poprawisz wyłącznie szkic, który masz przed sobą, korekta może się na nim skończyć. Jeśli zmienisz bieżący stan projektu, korekta zmieni pozostały research, następną implementację, pracę przekazaną innemu agentowi i zadanie wznowione jutro.
Wiele agentów naraz
Utrzymywanie bieżącego stanu staje się ważniejsze, gdy ludzie prowadzą kilku agentów jednocześnie. OpenAI przekonało się o tym, odkrywając, że jego inżynierowie komfortowo ogarniają tylko trzy do pięciu równoległych sesji Codeksa, zanim przełączanie kontekstu staje się bolesne. Ludzie zapominali, która sesja co robi, i spędzali czas na wędrówce między terminalami.
Symphony przeniosło pracę na tablicę projektową, z której agenty pobierają zgłoszenia. W części zespołów liczba zmergowanych pull requestów wzrosła o 500% w pierwsze trzy tygodnie po wdrożeniu. Zmiana operacyjna polega na tym, że zamiast trzymać każdą sesję w głowie, ludzie pozwalają zgłoszeniu nieść deliverable, status i najświeższy kierunek. Brzmi znajomo? Zgłoszenie po prostu wygodniej niesie stan bieżący agenta — dzięki temu można prowadzić znacznie więcej agentów naraz i zmieniać pracę tam, gdzie następny agent ją znajdzie, po prostu edytując zgłoszenie.
Jak zacząć u siebie
Możesz wykorzystać tę samą ideę bez wchodzenia w Symphony. Zacznij od jednego projektu, którego droga jest niepewna, ale którego wynik ma znaczenie. Poproś agenta o wczesny rezultat, który cię czegoś nauczy: mapę researchu, pierwszą implementację MVP, diagnozę problemu. Nie zamawiaj całego projektu w jednym ślepym przebiegu. Jeśli wczesna praca prawdopodobnie zmieni twój osąd, poproś najpierw o ten punkt kontrolny.
Na starcie daj agentowi cztery rzeczy: rezultat, właściwy materiał źródłowy, granice działania i pierwszy użyteczny punkt kontrolny. Ten punkt kontrolny musi zawierać pracę, o której możesz mieć zdanie. „Przemyśl problem i zdaj raport” to bardzo słabe polecenie. Lepiej: „Porównaj źródła, wskaż, gdzie się nie zgadzają, i zaproponuj pierwszą wersję planu, który twoim zdaniem spełniłby moje wymagania”. To daje coś, w co można się wgryźć.
Potem stwórz bardzo mały zapis stanu bieżącego. Nie musi być wyszukany. Powinien mówić, co projekt próbuje osiągnąć, które decyzje obecnie rządzą pracą, jakie pytania pozostają otwarte, co agent ma zrobić dalej i jaki warunek ma go zatrzymać albo skłonić do powrotu po twoją decyzję. Dopisz też, co agent może, a czego nie może zrobić bez twojej zgody.
Mój nazywa się current.md. To zwykły plik. Jest na tyle krótki, że rzeczywiście go czytam, i leży tam, gdzie agent zajrzy i skąd może czytać oraz gdzie może pisać. Kiedy dochodzę do punktu kontrolnego, przeglądam pracę i lokalizuję miejsce w current.md, które trzeba zmienić, żeby skorygować następny przebieg. Dowody mogą nie potwierdzić stawianej tezy. Użytkownicy mogą przejmować się zupełnie innym problemem. Możliwości progresywnego odkrywania jest mnóstwo. Ostatecznie chodzi o to, żeby ludzkie decyzje stały ponad pętlą i właściwie kierowały agentami przy tych wielkich przebiegach.
Oto przykład użytecznej instrukcji: „Zaktualizuj bieżący stan projektu tak, żeby ten dowód zastąpił nasze wcześniejsze założenie o kupującym. Zastosuj nową decyzję do wciąż otwartego researchu i do planu implementacji, a potem pracuj dalej. Stare założenie zachowaj w historii decyzji, a nie jako obowiązującą wytyczną”.
Nie musisz zresztą wpisywać tego do pliku ręcznie. Możesz powiedzieć: „Pracujemy razem nad current.md. Czytam to, co zrobiłeś w tym punkcie kontrolnym. Uważam, że jest błędne w tych punktach. Zaktualizuj current.md tak, żebyś nie powtórzył tego błędu, i wracaj do większego projektu”.
Dlaczego to ważniejsze niż rozmiar okna kontekstowego
To jest zdolność, którą ludzie przeoczają, patrząc wyłącznie na rozmiar okna kontekstowego. Większe okno technicznie zatrzyma więcej zdarzeń, ale kompaktowanie i tak może zadziałać, gdy okno się zapełni, a mechanizm pamięci może wyciągnąć coś dziwnego z wcześniejszej części sesji. Te mechanizmy nie potrafią rozstrzygnąć, który nowy fakt ma zmienić twój projekt. Nie zastąpią twojego osądu.
Możesz zrobić eksperyment i przekonać się sam. Uruchom to samo zadanie agentowe kilka razy. Raz tak, jak zwykle. Raz z bardzo skupioną paczką kontekstu — z plikiem current.md, z regułami dotyczącymi dowodów i tak dalej. I raz ze wszystkim, co masz, wypełniając okno kontekstowe do maksimum. Wielu ludzi obstawia, że wygra trzeci wariant, albo przynajmniej że da agentowi pełniejszą odpowiedź. Otóż nie. Kiedy zobaczysz wyniki, w niemal każdym przypadku wygrywa skupiony pakiet kontekstu pozwalający aktualizować stan w trakcie — bo pozwala właściwie wprowadzać twój osąd w toku pracy. Wysypanie kontekstu nie zastępuje osądu.
Prompting nadal istnieje. Przeglądanie pracy nadal istnieje. Ale cały projekt nie zależy już od jednego idealnego promptu na początku ani od jednej rozmowy, którą wszyscy pamiętają jednakowo. Zamiast tego dajesz agentowi dość kierunku, by zaczął, uczysz się z tego, co wyprodukuje, i zmieniasz stan rządzący tym, co przyjdzie dalej.
Weź więc może projekt, który odłożyłeś na lód, bo nie widzisz każdego kroku i czujesz, że musisz zdefiniować całość z góry, zanim oddasz ją AI. Bądź śmielszy. Ustal, dokąd zmierzasz, jaki masz materiał źródłowy i jakie granice ma mieć AI — a potem daj agentowi małe miejsce na trzymanie stanu bieżącego. Kiedy praca zmieni twój osąd, przepisz ten stan, zanim agent ruszy dalej.
Zestaw startowy
Jeśli chcesz zestaw startowy, przygotowałem cztery zwyczajne pliki wraz z promptami: readme.md, który tłumaczy tę metodę twojemu agentowi; current.md, który trzyma stan; contextmap.md, który mówi, co istnieje i gdzie leży (agent może pomóc go wypełnić); oraz decisions.md, który przechowuje to, co już zostało zdecydowane, i dlaczego. Nic z tego nie jest funkcją konkretnego narzędzia. Działa w Claude, działa w Codeksie, działa w zwykłym czacie. Link jest na moim Substacku.
Tak właśnie korzysta się z sześciogodzinnego agenta, nie prosząc sześciogodzinnego promptu, żeby dalej prowadził twój projekt.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozdziel „stan bieżący” od transkryptu rozmowy
Na czym polega: Historia przebiegu i aktualne instrukcje to dwie różne rzeczy. Arise naprawiło zapętlonego agenta, wynosząc plan poza okno rozmowy i doklejając go z dysku przed zaszumioną historią przy każdym wywołaniu modelu.
Jak stosować: Załóż jeden krótki plik stanu (autor nazywa go current.md) i umów się z agentem, że czyta go na starcie i aktualizuje po każdej istotnej decyzji. W Claude Code wymuś to przez claude.md, w Codeksie przez agents.md.
Na co uważać: Plik musi być na tyle krótki, że sam będziesz go czytał. Gdy zacznie puchnąć, przestanie pełnić swoją funkcję i stanie się kolejnym cmentarzyskiem reguł.
2.Prompt otwierający to start, nie kontrakt
Na czym polega: Prompt powstaje przed pracą i wyraża wyłącznie to, co wiedziałeś w tamtej chwili. Poważny projekt produkuje dowody, które ten stan wiedzy unieważniają.
Jak stosować: Kiedy wynik podważa twoje założenia, nie dopisuj kolejnego zdania do promptu — zmień to, co agent traktuje jako aktualną wersję zlecenia, i wyślij korektę tam, gdzie znajdzie ją następny przebieg.
Na co uważać: Naturalny odruch to obrona pierwotnego briefu. Przy sześciogodzinnych przebiegach ta lojalność kosztuje godziny pracy w złym kierunku.
3.Krótka mapa zamiast wielkiego podręcznika
Na czym polega: OpenAI nie wcisnęło miliona linii w jeden prompt. Dało krótki agents.md wskazujący na aktywne plany, logi decyzji i dokumenty architektury.
Jak stosować: Zamiast wklejać materiał, zbuduj plik-mapę: co istnieje, gdzie leży, po co po to sięgać. To pozwala agentowi znaleźć akurat ten fragment, który jest potrzebny do następnej decyzji.
Na co uważać: Mapa też się dezaktualizuje. OpenAI uruchamiało cykliczne zadania szukające przeterminowanej dokumentacji — bez takiego odświeżania mapa zacznie kierować agenta w martwe miejsca.
4.Zapisuj porażki jako konsekwencje, nie jako opowieści
Na czym polega: W projekcie Anthropic notatki postępu zapisują, że metoda okazała się zbyt sztywna, i nazywają jej następczynię. Nowa sesja widzi wniosek, a nie całą nieudaną próbę.
Jak stosować: Do stanu wpisuj format: „to podejście zawiodło, z tego powodu, użyj tego zamiennika”. Pełny przebieg zostaw w historii, changelogu albo gicie.
Na co uważać: Nie kasuj dowodów — one bywają potrzebne. Chodzi tylko o to, żeby nieudana metoda nie miała tej samej rangi w kontekście co aktywny plan.
5.Rozdzielaj cztery warstwy kontekstu
Na czym polega: Stała instrukcja, bieżący stan projektu, mapa materiałów i historia. Każda zmienia się w innym tempie i pełni inną rolę.
Jak stosować: Trzymaj je w osobnych miejscach. Barierki i standardy — w pliku reguł. Kondycję celu — w pliku stanu. Lokalizacje materiałów — w mapie. Przeszłość — w logu decyzji.
Na co uważać: Najczęściej pomijana jest warstwa mapy, a jej brak popycha ludzi do wklejania wszystkiego naraz. Drugi typowy błąd to historia udająca aktualne instrukcje.
6.Zamawiaj punkt kontrolny, o którym możesz mieć zdanie
Na czym polega: Jeśli wczesna praca może zmienić twój osąd, żądaj jej najpierw — zamiast całego projektu w jednym ślepym przebiegu.
Jak stosować: Na starcie daj agentowi cztery rzeczy: rezultat, materiał źródłowy, granice działania i pierwszy checkpoint. Formułuj go konkretnie: „porównaj źródła, wskaż rozbieżności, zaproponuj pierwszą wersję planu”.
Na co uważać: „Przemyśl problem i zdaj raport” to polecenie puste — dostaniesz coś, czego nie da się zakwestionować, więc nie nauczysz się niczego.
7.Wiedz, kiedy instrukcja przestaje być właściwa
Na czym polega: W projekcie autora polecenie ciągłego testowania obciążeniowego początkowo pomagało, a potem zamieniło agenta w pętlę bez wartości: był aktywny, ale nic nie wnosił.
Jak stosować: Zatrzymaj przebieg, zapisz checkpoint, zabroń wznawiania nieograniczonego biegu i zamień zadanie otwarte na wąskie i domykające („wybierz 50 najlepszych, uzupełnij dowody, zwaliduj, zakończ”).
Na co uważać: Aktywność agenta łatwo pomylić z postępem. Wpisz do stanu warunek zatrzymania — kiedy agent ma stanąć albo wrócić po twoją decyzję.
8.Zapisuj tylko to, co zmienia cel
Na czym polega: Nie każda korekta zasługuje na miejsce w stanie projektu. Liczy się to, co zmienia cel przebiegu albo definicję ukończenia.
Jak stosować: Test autora: jeśli zirytowałoby cię, że świeżo uruchomiony agent przeoczy tę decyzję — wpisz ją do stanu. Jeśli tylko tłumaczy, jak do czegoś doszedłeś — to historia.
Na co uważać: Nadmiar zapisów odtwarza dokładnie ten problem, który miałeś rozwiązać — plik stanu robi się zbyt duży, żeby cokolwiek w nim ważyło.
9.Przy wielu agentach stan musi żyć poza twoją głową
Na czym polega: Inżynierowie OpenAI komfortowo prowadzili tylko 3–5 równoległych sesji Codeksa. Przeniesienie pracy na tablicę zgłoszeń zdjęło z nich obowiązek pamiętania, co robi która sesja.
Jak stosować: Niech zgłoszenie niesie deliverable, status i najświeższy kierunek. Zmiana kierunku to wtedy edycja ticketu, którą kolejny agent po prostu przeczyta.
Na co uważać: Podany wzrost o 500% zmergowanych PR-ów w części zespołów dotyczy Symphony w OpenAI — to nie jest wynik, który należy zakładać u siebie. Ważny jest mechanizm, nie liczba.
10.Duże okno kontekstowe nie zastąpi twojego osądu
Na czym polega: W teście trzech wariantów tego samego zadania skupiona paczka kontekstu z aktualizowanym stanem wygrywa niemal zawsze z wariantem wypełniającym okno do maksimum.
Jak stosować: Uruchom ten eksperyment na własnym zadaniu — normalnie, ze skupioną paczką, i z maksymalnym zrzutem — i porównaj wyniki, zanim uwierzysz w intuicję „więcej kontekstu, lepiej”.
Na co uważać: Kompaktowanie działa dalej po zapełnieniu okna, a mechanizm pamięci potrafi wyciągnąć przypadkowy fragment z wcześniejszej części sesji. Żaden z tych mechanizmów nie rozstrzyga, który nowy fakt ma zmienić projekt — to nadal twoja decyzja.