Słownik sztucznej inteligencji

Ruchoma etykieta, a nie technologia. „AI” nie oznacza czegoś stałego, tak jak model czy token — wskazuje to, co komputery potrafią właśnie robić w nowy, imponujący sposób. Obecnie oznacza duże modele językowe. W przeszłości wskazywało zupełnie inne rzeczy:

Ta etykieta przesuwa się według znanego mechanizmu, czasem nazywanego efektem AI: gdy technika zaczyna działać niezawodnie, zmienia nazwę — staje się „po prostu” wyszukiwaniem albo „po prostu” statystyką — a „AI” przesuwa się na kolejną nierozwiązaną rzecz. To spostrzeżenie jest stare. Bertram Raphael ujął je w 1971 roku tak: „AI to zbiorcza nazwa problemów, których nie umiemy jeszcze właściwie rozwiązywać za pomocą komputera”. Larry Tesler około 1979 roku sformułował to tak: „Inteligencja to wszystko, czego maszyny jeszcze nie potrafią”.

Dlatego rozmowy o AI tak często mijają się ze sobą. Stwierdzenie „AI nie potrafi rozumować” albo „AI jest przereklamowana” zawiera ukryty znacznik czasu — może dotyczyć systemów eksperckich, klasyfikatorów obrazów z lat 2010. albo modelu językowego z zeszłego miesiąca, a każdy z tych przykładów prowadzi do innego wniosku. Gdy rozmowa o AI utknie, zwykle wystarczy zastąpić to słowo dokładniejszym terminem: modelem, harnessem, agentem albo kontekstem, który otrzymał.

Unikaj: słowa „AI” w twierdzeniach technicznych — zamiast tego nazywaj konkretny element. „Programowanie z AI” jako określenie praktyki jest w porządku; „AI ma halucynacje” — nie.

Użycie:

"Dyrektor techniczny chce wiedzieć, czy AI może obsługiwać kolejkę zgłoszeń do wstępnej analizy."

"Doprecyzuj to, zanim określisz zakres — chodzi jej o model językowy w harnessie z dostępem do systemu zgłoszeń. Samo „AI” nie jest specyfikacją."

Parametry. Bezstanowy — wykonuje przewidywanie następnego tokenu i nic więcej. „Claude Opus 4.x” i „GPT-5.x” to modele. Sam model nie potrafi działać jak agent; musi zostać wyposażony w środowisko.

Modele nie potrafią czytać plików, uruchamiać poleceń, przeglądać sieci ani pamiętać wczorajszego dnia — przyjmują tokeny i przewidują tokeny wyjściowe, raz na żądanie do dostawcy modelu. Wszystko, co przypomina pracę agenta — wybieranie narzędzi, odczytywanie wyników i powtarzanie działań do ukończenia zadania — to środowisko koordynujące wiele takich prognoz jedna po drugiej.

Dostawcy modeli oferują modele w różnych poziomach: duży, najmądrzejszy, ale powolny i drogi, oraz mniejsze, szybsze i tańsze, lecz mniej zdolne. Wybór poziomu ma znaczenie — ciężki model do planowania i trudnego debugowania, lekki do mechanicznych zmian — a środowiska pozwalają przełączyć model w trakcie sesji.

Precyzyjne używanie tego słowa ułatwia też diagnozę. „Model sobie z tym nie radzi” to konkretne twierdzenie — ten sam model w innym środowisku lub z innym kontekstem często zachowuje się zupełnie inaczej. Zanim obwinisz model, sprawdź, co otrzymał: większość rozczarowujących wyników wynika z kontekstu lub środowiska, nie z parametrów.

Użycie:

„Czy powinniśmy przełączyć model z Sonnet na Opus na etapie planowania?”

„Spróbuj — ale w tym zadaniu większość pracy wykonuje środowisko. Zmiana modelu nie pomoże, jeśli błędne są prompt systemowy i narzędzia.”

Liczby wewnątrz modelu — często liczone w miliardach — dostrajane podczas trenowania. To w nich znajduje się wszystko, co model „wie”. Trenowanie je ustala, a wnioskowanie wykorzystuje bez zmian. Nazywa się je też wagami.

W praktyce parametry zamieniają dane wejściowe na wyjściowe. Przewidywanie następnego tokenu to ogromne obliczenie: tokeny z okna kontekstu trafiają do parametrów, są przez nie przemnażane, a wynikiem jest przewidywanie kolejnego tokenu. W modelu nie ma bazy faktów ani tabeli wyszukiwania kodu — są tylko te liczby, ułożone tak, by obliczenia zwykle dawały użyteczny wynik. Fakty zapamiętane z trenowania, takie jak API biblioteki standardowej, tworzą wiedzę parametryczną: są przechowywane w parametrach, a nie pobierane z zewnętrznego źródła.

Warto zapamiętać, że parametry zostają zamrożone po trenowaniu. Nic, co zrobisz w sesji, ich nie zmieni — żadna korekta, pokazana baza kodu ani błąd, na którym model miałby się uczyć. Każda sesja działa na tych samych liczbach. Dlatego model jest bezstanowy, jego wbudowana wiedza kończy się na granicy wiedzy, a informacje specyficzne dla projektu muszą trafiać do kontekstu. Parametry zmienia dopiero kolejne trenowanie — w efekcie powstaje wtedy inny model.

Użycie:

„Czy możemy dostroić go na naszej bazie kodu?”

„To zaktualizowałoby parametry — później mielibyśmy inny model. W przypadku jednego projektu prawie zawsze taniej jest załadować bazę kodu jako kontekst niż ponownie trenować model.”

Proces, który ustawia parametry modelu, udostępniając mu ogromne ilości tekstu i korygując parametry w celu poprawy przewidywania następnego tokenu. Jednorazowy, kosztowny proces wykonywany przez dostawcę modelu. Obejmuje zarówno wstępne trenowanie (główną serię), jak i trenowanie następcze (późniejsze udoskonalenia, takie jak wykonywanie instrukcji i bezpieczeństwo); na poziomie tego słownika to rozróżnienie nie ma znaczenia.

Mechanizm polega na wielokrotnym powtarzaniu tego na dużą skalę: model otrzymuje fragment tekstu, przewiduje kolejny token, jego parametry są przesuwane w stronę rzeczywistego następnego tokenu, a proces powtarza się dla bilionów tokenów. Nic nie jest zapisywane jako fakty ani reguły — wszystko, co model „wie”, jest skutkiem doskonalenia przewidywań i zostaje skompresowane w parametrach jako wiedza parametryczna.

Na co dzień ważne są dwie konsekwencje. Trenowanie kończy się w konkretnym momencie, dlatego model ma granicę wiedzy — nie zna wersji biblioteki, którą zaktualizowałeś w zeszłym miesiącu. Trenowania nie można też wykonać samodzielnie: gdy model nie zna Twojej bazy kodu, konwencji ani wewnętrznych API, rozwiązaniem nigdy nie jest „nauczyć model” — trzeba umieścić te materiały w kontekście, jedynym wejściu, którym możesz sterować.

Użycie:

„Czy możemy sprawić, żeby znał nasze wewnętrzne API?”

„Nie przez trenowanie — to wielomiesięczny proces prowadzony przez dostawcę modelu. Zamiast tego załaduj dokumentację API do kontekstu; to dźwignia, którą faktycznie masz.”

Uruchamianie wytrenowanego modelu w celu wygenerowania odpowiedzi — odbywa się przy każdym żądaniu do dostawcy modelu. Parametry pozostają stałe; model wykonuje jedynie przewidywanie następnego tokenu na podstawie otrzymanego kontekstu. To tanie w porównaniu z treningiem, ale koszt nalicza się za każdy token; w korzystaniu z modelu to właśnie wnioskowanie stanowi główny wydatek.

Życie modelu dzieli się na dwie fazy:

Nic, co robisz podczas wnioskowania, nie zapisuje zmian w parametrach — dlatego poprawka przekazana dzisiaj nie zostaje zapamiętana na jutro. Model, który po twoim dokładnym wyjaśnieniu ponownie popełnia ten sam błąd w następnej sesji, nie ignoruje cię; nie potrafi uczyć się z tej wymiany. Model jest bezstanowy, więc ciągłość musi pochodzić spoza niego — z okna kontekstu albo systemu pamięci.

Ten mechanizm wyjaśnia też sposób naliczania opłat. Każde żądanie uruchamia model na pełnym kontekście, więc koszt rośnie wraz z liczbą tokenów wejściowych i wyjściowych. Agent wykonujący dziesiątki wywołań narzędzi płaci za wnioskowanie przy każdej rundzie. Dlatego rozmiar kontekstu wpływa zarówno na koszt, jak i na jakość.

Użycie:

"Dlaczego rachunek rośnie wraz z użyciem, zamiast być stałą opłatą licencyjną?"

"Płacisz za wnioskowanie — każde żądanie do dostawcy modelu uruchamia model na sprzęcie dostawcy. Trening już się odbył, ale koszt wnioskowania nalicza się za każde żądanie, a pojedyncza tura może rozwinąć się w wiele żądań, gdy wywoływane są narzędzia."

Poziom wysiłku to pokrętło określające, ile rozumowania model wykonuje przed odpowiedzią. Ustawiany dla każdego żądania do dostawcy modelu, określa długość namysłu, przez który model przechodzi, zanim zacznie pisać widoczną dla ciebie odpowiedź. Ten namysł powstaje podczas wnioskowania, tak jak pozostały wynik; harness często go ukrywa, ale model naprawdę wykonuje tę pracę.

Większy wysiłek kosztuje więcej i trwa dłużej. Rozumowanie jest emitowane jako tokeny, rozliczane jako tokeny wyjściowe, nawet jeśli ich nie widzisz, i powstaje token po tokenie — zwiększenie wysiłku wydłuża więc oczekiwanie na odpowiedź i podnosi rachunek. To kompromis między głębszym namysłem a szybkością i kosztem.

Większość harnessów udostępnia kilka poziomów wysiłku:

Skutki złego wyboru są odczuwalne w obie strony. Ustaw wysiłek zbyt nisko przy trudnym problemie, a otrzymasz pewną siebie, powierzchowną odpowiedź, która pominęła potrzebne rozumowanie — brzmi dobrze, ale później kosztuje. Ustaw maksymalny poziom przy zmianie nazwy w jednym wierszu, a będziesz czekać na długie rozważania, które nie wniosą niczego ponad to, co dałby najniższy poziom.

Dobieraj wysiłek do zadania, a nie do sesji. Zwiększ go tam, gdzie rozumowanie jest rzeczywiście trudne, a przy rutynowej pracy obniż.

Użycie:

"Wciąż psuje tę poprawkę współbieżności — wyjaśniałem ją już trzy razy."

"Zwiększ poziom wysiłku. Ten błąd wymaga intensywnego rozumowania, a przy domyślnym ustawieniu model nie zastanawia się wystarczająco długo, zanim wybierze podejście."

Atomowa jednostka odczytywana i zapisywana przez model. Ma mniej więcej rozmiar słowa, choć nie zawsze — częste słowa zajmują jeden token, a rzadkie lub długie rozbijają się na kilka. Rozmiar okna kontekstu, koszt i opóźnienie mierzy się w tokenach.

Tekst zamienia się w tokeny za pomocą tokenizera: ustalonego słownika zawierającego dziesiątki tysięcy fragmentów, nauczonego przed treningiem, który dzieli dowolne wejście na sekwencję elementów słownika. Model nigdy nie widzi znaków ani słów — każdy tekst jest zamieniany na tokeny przy wejściu, a przewidywanie następnego tokenu tworzy wynik token po tokenie.

Orientacyjnie jeden token to około trzy czwarte angielskiego słowa, więc tysiąc tokenów odpowiada mniej więcej 750 słowom. Kod jest mniej przewidywalny: częste słowa kluczowe i idiomy są tokenizowane zwięźle, natomiast generowane identyfikatory, hashe, ciągi base64 i zminimalizowany wynik rozpadają się na wiele tokenów na „słowo”. Zasada jest taka: tekst często występujący w materiałach źródłowych tokenizera otrzymuje krótkie, wydajne kodowanie; rzadki tekst dzieli się na wiele małych fragmentów. Hash taki jak `a3f9c2e1` nigdy nigdzie się nie pojawił, więc rozpada się na wiele tokenów, podczas gdy `function` jest jednym. Dlatego plik, który wygląda na mały, ale zawiera dużo nietypowych ciągów, może zająć zaskakująco dużą część okna kontekstu.

Wszystko inne mierzy się w tokenach. Koszt naliczany jest za token — dostawcy rozliczają osobno tokeny wejściowe i tokeny wyjściowe. Szybkość mierzy się w tokenach na sekundę, bo wynik powstaje token po tokenie. Okno kontekstu ma ustalony limit tokenów, więc ich liczba w twoich plikach decyduje o tym, ile się w nim zmieści.

Unikaj: słowa „wyraz” — granice tokenów nie pokrywają się z granicami słów, a rzeczywistymi jednostkami są tokeny na sekundę i tokeny na dolara.

Użycie:

"Jak duży będzie ten prompt?"

"Przepuść go przez tokenizer — schemat jest zwięzły, ale klucze JSON są nietypowe, więc zostaną podzielone na więcej tokenów, niż sądzisz."

To, co faktycznie robi model. Otrzymuje kontekst, losuje następny token, dopisuje go i powtarza. Każdy wynik — zdanie, wywołanie narzędzia, plik liczący tysiąc wierszy — powstaje po jednym tokenie. Model nie działa w żaden inny sposób.

Każdy krok wygląda tak samo: tokeny z okna kontekstu są przetwarzane przez parametry, które przypisują prawdopodobieństwo każdemu tokenowi ze słownika — ten jest bardzo prawdopodobny jako następny, tamten mniej. Jeden token jest losowany z tych prawdopodobieństw, dopisywany, a pętla rusza ponownie z nieco dłuższym kontekstem. To losowanie sprawia, że ten sam prompt daje różne wyniki przy kolejnych uruchomieniach: niedeterminizm wynika z samego mechanizmu, nie jest dodatkowym błędem.

Zrozumienie tego mechanizmu wyjaśnia zachowania, które inaczej wyglądają dziwnie. Model nie sprawdza, czy token jest prawdziwy, zanim go wygeneruje — sprawdza tylko, czy jest prawdopodobny — co leży u podstaw halucynacji. Zobowiązuje się do kolejnych tokenów w trakcie generowania, więc pewnie brzmiące pierwsze zdanie może skierować resztę odpowiedzi na złą drogę. A ponieważ tokeny wyjściowe powstają ściśle po jednym, szybkość generowania wyznacza minimalny czas pracy każdego agenta.

Użycie:

„Jak agent «decyduje», że ma wywołać narzędzie?”

„Nie decyduje — na samym dole zawsze jest przewidywanie następnego tokenu. Wywołanie narzędzia to po prostu ustrukturyzowany ciąg znaków, który środowisko odczytuje ze strumienia wyjściowego.”

To samo wejście może dać różne wyniki. Uruchom model dwa razy z identycznym kontekstem, a możesz otrzymać dwie różne odpowiedzi — czasem zmieni się jedno słowo, czasem całe podejście. W kodzie nie musi zajść żadna zmiana, by tak się stało.

To właściwość sposobu, w jaki modele generują tekst, oraz tego, jak dostawcy modeli obsługują żądania. Podczas wnioskowania model tworzy rozkład prawdopodobieństwa możliwych następnych tokenów, po czym jeden z nich jest losowany — zwykle celowo z pewną dozą losowości, ponieważ ciągłe wybieranie najbardziej prawdopodobnego tokenu daje powtarzalny tekst gorszej jakości. Jeden token wylosowany inaczej na początku odpowiedzi zmienia wszystkie następne tokeny; tak pojedyncze inne słowo prowadzi do zupełnie odmiennego podejścia. Obsługa po stronie dostawcy wprowadza kolejne różnice: żądania są łączone w partie na współdzielonym sprzęcie, a niewielkie różnice zmiennoprzecinkowe między partiami mogą przechylić decyzję między dwoma tokenami o zbliżonym prawdopodobieństwie. Nie ma ustawienia, które można przełączyć, by całkowicie temu zapobiec.

Spodziewaj się zróżnicowanych wyników pracy agenta nad tym samym zadaniem. Większość odpowiedzi mieści się w rozsądnej krzywej jakości — dlatego niedeterminizm jest w ogóle tolerowany — ale skrajne przypadki rzeczywiście się zdarzają: jednego dnia model wydaje się bystry, a innego jakby stracił wątek. To samo zadanie, inny rzut kośćmi. Wynikają z tego dwa praktyczne wnioski. Ponowienie jest uzasadnioną strategią: nieudana próba to jeden los z rozkładu, a kolejna próba tego samego zadania może po prostu wypaść lepiej. Weryfikacja ma też większe znaczenie niż przy narzędziach deterministycznych — nie możesz raz przetestować zachowania agenta i zakładać, że będzie je powtarzał, dlatego automatyczne kontrole muszą wychwytywać nieudane losowania.

Uważaj, by nie dopisywać temu nadmiernej narracji. Ludzie są maszynami do rozpoznawania wzorców, więc seria nieudanych przebiegów może sprawiać wrażenie dowodu, że „model pogorszył się w tym tygodniu”. Zwykle to po prostu rozkład wyników.

Użycie:

"Claude dziś fatalnie działa. Czy wypuścili gorszą wersję?"

"Raczej nie — wyniki modelu są niedeterministyczne. Przy tym samym zadaniu zdarzają się dobre i złe dni. Spróbuj jutro, zanim zaczniesz szukać przyczyny."

Wszystko, co udostępnia modelowi możliwość wnioskowania. Zwykle jest to zdalna usługa (Anthropic, OpenAI, Google), ale może być też lokalna — Ollama, LM Studio lub llama.cpp działające na Twoim komputerze. Środowisko nie uruchamia modelu samodzielnie; wysyła żądanie do dostawcy.

Dostawca jest właścicielem infrastruktury: parametry znajdują się na jego sprzęcie, a każde żądanie do dostawcy modelu to wysłanie przez środowisko tokenów przez sieć i odebranie prognoz. Dlatego źródłem całej grupy problemów, które błędnie przypisuje się modelowi lub środowisku, jest dostawca — limity częstotliwości, spadek dostępnej mocy i awarie występują właśnie tutaj. Gdy agent zatrzymuje się w środku sesji lub popełnia błąd w każdej turze, najpierw warto sprawdzić stronę statusu dostawcy.

Dostawca określa też warunki handlowe: cenę za tokeny wejściowe i wyjściowe, zniżki pamięci podręcznej prefiksu i listę dostępnych modeli. Dostawca i twórca modelu mogą być różnymi firmami — Bedrock, Vertex i OpenRouter udostępniają modele innych podmiotów.

Lokalni dostawcy zamieniają możliwości na kontrolę: modele mieszczące się na Twoim sprzęcie są znacznie mniejsze niż modele frontier, ale nic nie opuszcza komputera i nie płacisz za każdy token.

Użycie:

„Czy możemy uruchamiać to offline u klienta odizolowanego od sieci?”

„Zmień dostawcę modelu na lokalnego — Ollama albo llama.cpp na jego komputerze. Środowisko tego nie zauważy, po prostu odwoła się do innego punktu końcowego.”

Wszystko, co otacza model i zmienia go w agenta: narzędzia, prompt systemowy, zarządzanie oknem kontekstu, uprawnienia, hooki. Claude.ai i Claude Code działają na tym samym modelu, ale zachowują się inaczej, ponieważ różnią się ich harnessy.

Sam model robi tylko jedną rzecz: przyjmuje tekst i zwraca tekst. Nie potrafi odczytać pliku, uruchomić polecenia ani pamiętać poprzedniej tury. To wszystko zapewnia harness. Przygotowuje kontekst dla każdego żądania do dostawcy modelu, wykonuje wywołania narzędzi, o które prosi model, przekazuje z powrotem wyniki narzędzi, przechowuje historię sesji, pyta o zgodę przed ryzykownymi działaniami i decyduje, kiedy skompaktować kontekst. Pętla agenta — model proponuje, harness wykonuje, i tak dalej — jest obsługiwana przez harness.

To ważne przy diagnozowaniu problemów. Gdy zachowanie różni się między dwoma produktami albo między wczoraj a dziś, przyczyną często nie jest model, lecz harness. Inny prompt systemowy, zestaw narzędzi, domyślne ustawienie uprawnień czy nowa strategia zarządzania kontekstem zmieniają zachowanie bez zmiany modelu. Oznacza to też, że większość konfiguracji znajduje się w harnessie: pliki AGENTS.md, ustawienia uprawnień i hooki są instrukcjami dla harnessu, a nie dla modelu.

Przykłady: Claude Code, Cursor, Codex CLI oraz Claude.ai, który jest harnesssem konwersacyjnym, a nie programistycznym.

Użycie:

"Ten sam model — dlaczego Claude Code edytuje pliki, a Claude.ai tylko odpowiada na pytania?"

"Różne harnessy — Claude Code ma narzędzia systemu plików, inny prompt systemowy i warstwę uprawnień. To nie model jest tu zmienną."

Jedna wymiana między harnessem a dostawcą modelu. Harness wysyła bieżący kontekst, a dostawca zwraca jedną odpowiedź (wywołanie narzędzia albo odpowiedź końcową). Jedna wiadomość użytkownika może uruchomić wiele żądań do dostawcy modelu, jeśli agent wywołuje narzędzia — po każdym wyniku narzędzia następuje kolejne żądanie.

Każde żądanie zawiera wszystko: prompt systemowy, całą dotychczasową rozmowę i wszystkie wyniki narzędzi. Model jest bezstanowy, więc dostawca nie zachowuje niczego między żądaniami — żądanie czterdzieste ponownie wysyła to, co wysłało trzydzieste dziewiąte, wraz z jednym dodatkowym wynikiem narzędzia. Pamięć podręczna prefiksów sprawia, że takie powtórzenia są tańsze.

Żądanie jest też jednostką rozliczeniową. Tokeny wejściowe, tokeny wyjściowe i zniżki za pamięć podręczną nalicza się dla każdego żądania. Dlatego niewinnie wyglądające pytanie może kosztować zaskakująco dużo: koszt zależy nie od długości twojej wiadomości, lecz od liczby żądań pomnożonej przez rozmiar kontekstu wysyłanego w każdym z nich.

Warto odróżniać żądanie od tury. Tura to jedna wymiana z tobą, ale pojedyncza tura — „napraw nieudany test” — może składać się z całego łańcucha żądań:

Sześć żądań w jednej turze — każde ponownie wysyła cały kontekst. Gdy zastanawiasz się, gdzie podziały się tokeny, policz żądania, a nie tury.

Użycie:

"Jedno pytanie zużyło czterdzieści tysięcy tokenów?"

"Sprawdź wywołania narzędzi — dwanaście wyszukiwań grep, osiem odczytów, cztery edycje. Każdy wynik narzędzia wywołuje kolejne żądanie do dostawcy modelu, a prefiks całej sesji jest wysyłany ponownie za każdym razem."

Tokeny, które środowisko wysyła w każdym żądaniu do dostawcy modelu — prompt systemowy, historię rozmowy, wyniki narzędzi i wszystko, co model odczytuje przed wygenerowaniem odpowiedzi. Są rozliczane według niższej stawki niż tokeny wyjściowe, ponieważ ich przetwarzanie jest tańsze.

Podczas programowania z AI większość rachunku stanowią tokeny wejściowe. Model jest bezstanowy, więc każda tura ponownie wysyła całą sesję jako dane wejściowe: pierwszą wiadomość, każdą odpowiedź i wszystkie dotychczasowe wyniki narzędzi. Wejście dla pięćdziesiątej tury zawiera poprzednie czterdzieści dziewięć tur. Pojedyncze żądanie do dostawcy modelu może wygenerować kilkaset tokenów wyjściowych, a jednocześnie ponownie wysłać sto tysięcy tokenów wejściowych z nagromadzonej historii.

Pamięć podręczna prefiksu obniża ten koszt: historia, która dokładnie odpowiada poprzedniemu żądaniu, jest rozliczana jako tanie tokeny z pamięci podręcznej, a nie pełnopłatne tokeny wejściowe. Gdy koszt wejścia nadal jest wysoki, rozwiązaniem jest ograniczenie danych wysyłanych ponownie — wyczyszczenie lub skompaktowanie kontekstu między zadaniami.

Użycie:

„Rachunek jest wysoki, ale agent prawie niczego nie pisze”.

„Chodzi o tokeny wejściowe — każda tura ponownie wysyła całą sesję. Bez pamięci podręcznej prefiksu płacisz za historię przy każdym żądaniu.”

Tokeny generowane przez model. Są rozliczane według wyższej stawki niż tokeny wejściowe — zwykle około pięć razy wyższej — ponieważ ich wygenerowanie wymaga większej mocy obliczeniowej.

Liczy się wszystko, co model zapisuje: czytana proza, wygenerowany kod, wywołania narzędzi oraz dłuższe rozumowanie przed odpowiedzią. To ostatnie zaskakuje wiele osób — tokeny rozumowania są rozliczane jako wyjściowe, nawet jeśli środowisko często ich nie pokazuje; zwiększenie wysiłku oznacza zużycie większej ich liczby.

Tokeny wyjściowe wyznaczają też tempo sesji. Model szybko czyta dane wejściowe, ale generuje odpowiedź token po tokenie, więc gdy tura wydaje się powolna, niemal zawsze chodzi o zapisywanie odpowiedzi, a nie odczytywanie wejścia. Długie oczekiwanie zwykle oznacza, że powstaje długa odpowiedź.

Użycie:

„Sesja refaktoryzacji zużywa środki, chociaż dane wejściowe są niewielkie”.

„Agent przepisuje całe pliki zamiast nakładać poprawki. Tokeny wyjściowe kosztują mniej więcej pięć razy więcej niż wejściowe — każ mu generować zmiany, a rachunek spadnie.”

Magazyn po stronie dostawcy, który pozwala kolejnym żądaniom do dostawcy modelu pominąć ponowne przetwarzanie wspólnego prefiksu. Gdy początek żądania jest zgodny z początkiem niedawnego żądania — ten sam prompt systemowy, ta sama historia do pewnego miejsca — dostawca wykorzystuje wcześniejszą pracę i rozlicza te tokeny po znacznie niższej stawce jako tokeny z pamięci podręcznej.

Pamięć podręczna się opłaca, ponieważ sesje rosną przez dopisywanie. Każde żądanie ponownie wysyła całą historię jako tokeny wejściowe (w odpowiednim haśle wyjaśniono dlaczego), a podczas zwykłej sesji historia zmienia się tylko na końcu — każde żądanie to poprzednie żądanie oraz kilka nowych wiadomości. Dostawca raz przetwarza długi, wspólny początek, zapisuje wynik i kontynuuje od miejsca, w którym kończy się prefiks. Bez pamięci podręcznej sesja obejmująca 50 tur wymagałaby ponownego przetworzenia pierwszej tury pięćdziesiąt razy.

Pamięć podręczna także wygasa. Czas przechowywania aktywnego wpisu zależy od dostawcy modelu — zwykle są to minuty, a nie godziny. Jeśli sesja pozostanie bezczynna dłużej niż to okno, następne żądanie raz odbuduje prefiks po pełnej cenie, zanim ponownie zacznie korzystać z pamięci podręcznej. To głównie sprawa twórców środowisk; użytkownik widzi, że żądania po dłuższej przerwie kosztują więcej niż wcześniejsze.

Użycie:

„Dlaczego rachunek wzrósł w połowie sesji?”

„Środowisko zaczęło dodawać aktualny czas do promptu systemowego przy każdej turze. Pamięć prefiksu przestaje działać przy pierwszym zmienionym tokenie, więc każde kolejne żądanie rozliczono po pełnej stawce.”

Tokeny wejściowe zachowane przez dostawcę w pamięci podręcznej z poprzedniego żądania do dostawcy modelu, aby nie musiał przetwarzać ich ponownie. Jeśli kolejne żądania mają wspólny prefiks, dostawca ponownie wykorzystuje wykonaną pracę za pomocą pamięci podręcznej prefiksów i nalicza za buforowaną część dużo niższą stawkę. To czynnik, który sprawia, że długie sesje są przystępne cenowo — bez niego każda tura ponownie kosztowałaby pełną historię.

To ważne ze względu na sposób rozliczania sesji. Model jest bezstanowy, więc każde żądanie ponownie wysyła całą rozmowę — prompt systemowy, każdą wiadomość, każdy wynik narzędzia — jako tokeny wejściowe. Przy pięćdziesiątej turze każde żądanie zawiera historię pięćdziesięciu tur i za każdym razem płacisz pełną stawkę za całość. Pamięć podręczna zmienia rachunek: tokeny, które dostawca już przetworzył w identycznym prefiksie, są rozliczane jako tokeny z pamięci podręcznej, często za jedną dziesiątą stawki wejściowej lub mniej. Podczas długiej sesji większość wysyłanych danych stanowią tokeny z pamięci podręcznej, dzięki czemu rachunek pozostaje rozsądny.

Przykład pokazuje, kiedy tokeny trafiają do pamięci podręcznej, a kiedy nie. Każda litera oznacza blok treści rozmowy; każde żądanie wysyła dotychczasową rozmowę:

Pamięć podręczna jest podatna na zmiany w konkretny sposób: dopasowuje dokładne prefiksy. Jeśli cokolwiek zmieni się wcześniej w rozmowie — harness zmieni kolejność treści, zaktualizuje się znacznik czasu, zmieni się zapis pliku — pamięć podręczna przestaje trafiać od tego miejsca, a wszystko po nim jest rozliczane według pełnej stawki za tokeny wejściowe. Pamięć podręczna wygasa też po kilku minutach bezczynności, więc wznowienie sesji po dłuższej przerwie oznacza jednorazową ponowną opłatę za historię. Gdy koszt sesji niespodziewanie rośnie, w raporcie zużycia porównaj tokeny z pamięci podręcznej z tokenami wejściowymi — awaria pamięci podręcznej najpierw ujawni się właśnie tam.

Użycie:

"Długie sesje są potwornie drogie — refaktoryzacja kosztowała osiem dolarów."

"Sprawdź tokeny z pamięci podręcznej. Jeśli harness zmienia kolejność promptu systemowego albo plików między turami, prefiks przestaje pasować i przy każdym żądaniu ponownie płacisz pełną stawkę wejściową."

Nic nie przenosi się dalej. Model jest bezstanowy między żądaniami do dostawcy modelu — każde żądanie ponownie wysyła całe okno kontekstu, bo model nie ma dostępu do niczego innego. Domyślnie agent jest bezstanowy między sesjami: nowa sesja zaczyna się od pustego stanu, bez śladu poprzednich. Przeciwieństwo stanowości.

Sam model jest trwale bezstanowy: jego parametry zostają zamrożone po treningu, a nic, co robisz podczas wnioskowania, ich nie zmienia. Model nie uczy się na twoich poprawkach, nie pamięta, że wczoraj powiedziano mu to samo, i nie poznaje cię — choć rozmowa może sprawiać takie wrażenie. Poczucie ciągłości w ramach sesji wytwarza harness, który zachowuje transkrypt i wysyła go ponownie przy każdym żądaniu. Model nie pamięta rozmowy; czyta ją na nowo.

Praktyczny skutek: jeśli coś ma być pamiętane między sesjami, trzeba to zapisać w miejscu, z którego agent ponownie to odczyta. Do tego służą pliki AGENTS.md, systemy pamięci i artefakty przekazania — pliki ładowane do kontekstu przyszłych sesji, zastępujące pamięć, której model nie ma. Gdy agent ponownie popełnia błąd, który już wcześniej poprawiono, pytanie nie brzmi, dlaczego się nie nauczył — nie potrafi — lecz gdzie zapisać tę poprawkę, aby odczytała ją każda kolejna sesja.

Użycie:

"Dlaczego za każdym razem zapomina tę konwencję, gdy czyszczę sesję?"

"Model jest bezstanowy — nowa sesja zaczyna się od pustego stanu. Jeśli chcesz zachować tę informację, zapisz ją w AGENTS.md albo w pliku pamięci ładowanym przez harness na początku sesji."

Informacje istotne dla zadania, do których agent ma dostęp w danej chwili. To pojęcie abstrakcyjne — nie surowe dane wejściowe widziane przez model (to okno kontekstu), nie bieżąca historia (to sesja), ale to, co agent wie i co ma znaczenie dla zadania. „Załadować coś do kontekstu” oznacza włączyć to do tego zbioru; „inżynieria kontekstu” to dziedzina zajmująca się jego selekcją.

Trzy terminy różnią się jasno:

To rozróżnienie ma znaczenie, ponieważ kontekst jest miarą jakości, a nie ilości. Okno kontekstu może być niemal pełne, a kontekst nadal kiepski — tysiące tokenów nieaktualnych wyników narzędzi, z których żaden nie dotyczy bieżącego zadania. Może też być prawie puste, ale znakomite: wystarczy jedna definicja typu, od której zależy zadanie.

Większość codziennych błędów wynika z kontekstu. Gdy agent wymyśla API, przeczy decyzji albo zgaduje schemat, najpierw sprawdź, co było w kontekście, gdy to robił — zwykle istotny fakt nie został załadowany albo został pogrzebany przez degradację uwagi. Rozwiązaniem jest selekcja: załaduj to, czego wymaga zadanie, a resztę pomiń.

Użycie:

„Ciągle wymyśla pola, których nie ma w typie”.

„Plik z typem nie jest w kontekście — czyta miejsca wywołań i zgaduje. Najpierw wczytaj definicję.”

Wszystko, co model widzi przy każdym żądaniu do dostawcy modelu. Jest ograniczone, zależne od modelu i stanowi jedyną powierzchnię, przez którą model cokolwiek postrzega.

To jedna sekwencja tokenów: prompt systemowy, dotychczasowa rozmowa i każdy wynik narzędzia, który środowisko przekazało modelowi. Jeśli coś znajduje się w tej sekwencji, model może z tego skorzystać; jeśli nie, model nie wie o jego istnieniu — ani o Twojej bazie kodu, ani o wczoraj edytowanym pliku, ani o instrukcji przekazanej trzy sesje temu. Wszystko spoza okna trzeba wprowadzić, zwykle przez wywołanie narzędzia, zanim będzie mogło na cokolwiek wpłynąć.

Okno jest ograniczone, więc może się zapełnić. Każda tura dopisuje kolejne elementy — Twoje wiadomości, odpowiedzi modelu, wyniki narzędzi — a długa sesja w końcu dobije do limitu, wymuszając kompaktowanie lub wyczyszczenie. Ograniczenie oznacza też konkurencję: każdy załadowany token zmniejsza przestrzeń dostępną dla pozostałych, a niepotrzebne treści nadal zajmują uwagę modelu. W praktyce traktuj okno jak budżet — załaduj to, czego wymaga zadanie, a resztę pozostaw poza nim.

Unikaj: „pamięć” — okno kontekstu jest stanem roboczym i nie zachowuje się między sesjami. Pamięć to osobna warstwa.

Użycie:

„Czy mogę po prostu wkleić całe monorepo do promptu?”

„Okno kontekstu ma 200 tys. tokenów — to może jedna piąta repozytorium. Wybierz pliki, których dotyczy zadanie, a resztę pozostaw za wywołaniem narzędzia.”

Przenosi informacje w przyszłość. Sesja jest stanowa między turami — w jej trakcie gromadzi się kontekst, dlatego długie sesje osuwają się w strefę otępienia. Agenta można uczynić stanowym między sesjami, dodając system pamięci, który zapisuje informacje w środowisku i ponownie ładuje je na początku kolejnych sesji. Model nigdy nie jest stanowy; pozorną ciągłość zapewnia harness, ponownie przekazując kontekst. Przeciwieństwem jest bezstanowość.

Gdzie stan znajduje się na poszczególnych poziomach:

Stan na każdym poziomie powstaje przez ponowne odczytanie czegoś zapisanego poziom niżej: sesja wydaje się ciągła, bo harness ponownie wysyła historię wiadomości do bezstanowego modelu, a agent pamięta między sesjami, bo harness ponownie ładuje pliki ze środowiska. Sam model nigdy nie przechowuje żadnego stanu.

Stan nie zawsze jest pożądany. Wszystko, co się przenosi, wpływa na dalszy przebieg, więc przenosi się również błędne założenie przyjęte na początku sesji. Czyszczenie to celowe odrzucenie stanu sesji i rozpoczęcie od informacji, które zapisano.

Użycie:

"Pamiętał moje wczorajsze preferencje — czy to znaczy, że model się ich nauczył?"

"Nie, agent jest stanowy, bo harness zapisał je w pliku pamięci i załadował ponownie na początku sesji. Sam model nie widział niczego z wczoraj."

Model wyposażony w środowisko, narzędzia, prompt systemowy i okno kontekstu, który prowadzi z użytkownikiem tury. Claude Code jest agentem. Cursor jest agentem. Claude.ai jest agentem. Agent jest tym, z kim faktycznie rozmawiasz — modelem w działaniu, skonfigurowanym do konkretnego celu.

W przeciwieństwie do większości terminów w tym słowniku „agent” nie nazywa mechanicznej części. Model to plik parametrów; środowisko to oprogramowanie, które można wskazać. Agent nie jest żadnym z nich — to jednostka, do której mówisz. Ludzie stale antropomorfizują AI, a agent jest właśnie taką antropomorfizowaną jednostką: tym, komu delegujesz zadanie, kto czyta wiadomość i odpowiada, tym „ono” w zdaniu „znowu zepsuło kompilację”. Mówiąc, że agent coś zrobił, masz na myśli model wraz ze środowiskiem, ale zwracasz się do tej kombinacji jak do jednego podmiotu.

Ta koncepcja jest starsza niż obecna fala AI. Agenty programowe — programy, którym delegujesz cel i które działają w Twoim imieniu — istnieją jako idea od tak dawna, jak samo AI.

Unikaj: „AI”, „bot” (to zbyt ogólne określenia — nie wiadomo, czy chodzi o parametry, czy o model wyposażony w środowisko).

Użycie:

„Z jakiego agenta korzystasz przy migracji?”

„Lokalnie Claude Code, a do pracy nad interfejsem Cursor — pod spodem ten sam model, ale inne środowiska.”

Instrukcje, które środowisko dodaje na początku każdego żądania do dostawcy modelu — stała instrukcja dla agenta: kim jest, jak ma się zachowywać, których narzędzi może używać i jakich konwencji przestrzegać. Zwykle nie zmieniają się przez całą sesję.

Prompt systemowy pisze dostawca środowiska, a nie użytkownik; w środowiskach programistycznych jest duży — często obejmuje dziesiątki tysięcy tokenów reguł zachowania, opisów narzędzi i obsługi przypadków brzegowych, rozliczanych jako tokeny wejściowe w każdej turze. Dołączane są do niego Twoje własne stałe instrukcje: pliki takie jak AGENTS.md są ładowane obok promptu systemowego na początku sesji, więc model czyta wspólnie instrukcje dostawcy i Twoje, zanim zobaczy Twoją wiadomość.

Ponieważ prompt systemowy jest identyczny w każdym żądaniu, tworzy początek pamięci podręcznej prefiksu — między innymi dlatego środowiska utrzymują go bez zmian przez całą sesję, zamiast modyfikować w trakcie pracy.

Modele są trenowane tak, by przedkładać prompt systemowy nad wiadomości użytkownika. Gdy agent upiera się przy konwencji, o którą nie prosiłeś, albo formatuje wynik w sposób, którego nie możesz zmienić, zwykle wykonuje polecenia z promptu systemowego — a Twoja wiadomość przegrywa. Niektóre środowiska można dostosować: dają pełny dostęp do promptu systemowego, dzięki czemu można przeczytać, co agentowi faktycznie powiedziano, i zmienić te instrukcje.

Użycie:

„Dwa środowiska, ten sam model, zupełnie inne zachowanie dla tego samego promptu”.

„Różne prompty systemowe. Jedno jest dostrojone do zwięzłych zmian w kodzie, drugie do wyjaśnień — różnica powstaje, zanim dotrze Twoja wiadomość.”

Jedna ograniczona seria interakcji z agentem. Zaczyna się pusta, gromadzi wiadomości, wyniki narzędzi i przeczytane pliki, a kończy po wyczyszczeniu, zamknięciu lub skompaktowaniu do nowej sesji. To sesja wypełnia okno kontekstu: jeśli okno kontekstu jest pudełkiem, sesja jest zawartością, która stopniowo je zapełnia. Pracę większą niż jedno okno kontekstu trzeba podzielić na kilka sesji.

Historia wiadomości w sesji jest pamięcią roboczą agenta. Model jest bezstanowy, więc wszystko, co zdaje się pamiętać — Twoje zlecenie, wyniki testów, jego decyzję sprzed trzech tur — znajduje się w historii wiadomości, ponownie wysyłanej przy każdym żądaniu do dostawcy modelu. To, czego nie ma w sesji, nie istnieje dla agenta.

Ta pamięć kończy się wraz z sesją. Nowa sesja zaczyna od zera: agent, który pod koniec wczorajszej sesji dobrze znał Twoją bazę kodu, dziś rano nic o niej nie wie. Przetrwa tylko system plików — pliki zapisane podczas jednej sesji można odczytać w następnej i na tym opierają się przekazania, systemy pamięci oraz AGENTS.md.

Decydujesz, gdzie kończy się sesja. Wszystko w sesji wpływa na każdą późniejszą turę, więc niezwiązane zadania wykonane w jednej sesji zostawiają ślad, który zabarwia następną odpowiedź. Jedno zadanie na sesję utrzymuje kontekst w temacie; ukończenie zadania jest naturalnym momentem na wyczyszczenie sesji.

Użycie:

„Jak długo może działać jedna sesja, zanim się rozpadnie?”

„To zależy od pracy — skupiony refaktoring zachowa precyzję dłużej niż otwarte badanie. Gdy sesja nabrzmieje, przekaż pracę dalej lub skompaktuj kontekst; nie brnij dalej.”

Jedna wiadomość użytkownika oraz wszystko, co agent zrobi w odpowiedzi, aż do chwili przekazania kontroli użytkownikowi. Zawiera jedno lub więcej żądań do dostawcy modelu — wiele, jeśli agent wywołuje narzędzia. Pytanie doprecyzowujące zamyka turę; Twoja odpowiedź rozpoczyna następną. Hierarchia wygląda tak: sesja > Tura > Żądanie do dostawcy modelu.

Warto nazywać turę, bo jej długość ustala agent, a nie użytkownik. Przekazujesz jedną wiadomość; agent decyduje, ile wywołań narzędzi wykona przed oddaniem kontroli. Tura może być odpowiedzią w jednym zdaniu albo dwudziestoma minutami czytania, edycji i uruchamiania testów. To dwie strony tej samej cechy: długie tury umożliwiają pracę AFK, ale bez nadzoru właśnie wtedy najczęściej coś idzie źle — gdy agent oddaje kontrolę, mógł już znacznie odejść od tego, co miałeś na myśli.

Tura jest też naturalną jednostką kierowania pracą. Wszystko w jej trakcie dzieje się bez Ciebie; między turami możesz przekierować agenta. Większość środowisk to łagodzi: możesz przerwać turę w połowie i zmienić kierunek albo wpisać wiadomość podczas pracy, która zostanie odczytana po zakończeniu tury. Jeśli regularnie nie podoba Ci się, gdzie kończą się tury, rozwiązaniem jest zwykle prosić o krótsze — najpierw plan, potem jeden krok naraz — wymieniając większą autonomię na częstsze chwile, w których możesz pokierować pracą.

Użycie:

„Jedna tura trwała dwie minuty?”

„Wykonał w niej czternaście wywołań narzędzi — każde z nich to osobne żądanie do dostawcy modelu. Opóźnienie się kumuluje, zanim agent w końcu odda Ci kontrolę.”

Świat, na który działa agent — wszystko poza harnessem, co agent postrzega przez wyniki narzędzi i zmienia za pomocą wywołań narzędzi. Harness uruchamia agenta; środowisko jest miejscem, w którym agent pracuje. Plik taki jak `AGENTS.md` znajduje się w środowisku; harness ładuje go do okna kontekstu. Najczęstszym środowiskiem jest system plików, ale nie jedynym — środowiskiem może być też baza danych, zdalne API czy sesja przeglądarki.

Agent widzi środowisko tylko wtedy, gdy je sprawdza. Wszystko, co o nim wie, pochodzi z wyników narzędzi, więc jego obraz składa się z migawek, z których każda jest aktualna w chwili wykonania. Jeśli plik zmieni się po odczytaniu przez agenta — na przykład ręcznie go edytujesz albo ponownie generuje go etap budowania — agent nadal rozumuje na podstawie nieaktualnej kopii, dopóki coś nie skłoni go do ponownego odczytu. Gdy agent z przekonaniem opisuje plik, który już tak nie wygląda, zwykle właśnie to się stało: środowisko się zmieniło, a migawka nie.

Środowisko jest też warstwą trwałą — jedyną, która zawsze jest stanowa. Kontekst sesji znika po jej zakończeniu, ale pliki zapisane w środowisku pozostają do odczytu dla następnej sesji. Na tym polegają systemy pamięci, artefakty przekazania i pliki `AGENTS.md`. Wszystko, co agent powinien pamiętać jutro, musi znaleźć się w środowisku.

To ty określasz rozmiar środowiska. Piaskownica je ogranicza, zawężając zasoby dostępne agentowi; dodanie narzędzia je rozszerza, udostępniając bazę danych lub API. To, co znajduje się wewnątrz granicy, agent może postrzegać i zmieniać; wszystko poza nią dla agenta nie istnieje. To, jak dobrze środowisko wspiera pracę agenta, określa AX bazy kodu.

Unikaj: używania słowa „środowisko” na określenie środowiska uruchomieniowego albo samego harnessu — harness jest opakowaniem, a środowisko przestrzenią roboczą.

Użycie:

"Agent nie widzi schematu bazy stagingowej."

"Podłącz ją do środowiska — udostępnij mu narzędzie `psql` ograniczone do odczytu w stagingu. Harness działa poprawnie, po prostu nie ma na czym pracować."

Drzewo plików i katalogów, z którego agent czyta, do którego zapisuje i w którym wykonuje polecenia — domyślny rodzaj środowiska dla agenta programistycznego. AGENTS.md, umiejętności, kod źródłowy, skrypty kompilacji i konfiguracje narzędzi znajdują się w systemie plików. Gdy środowisko „uruchamia się w Twoim projekcie”, wskazuje agentowi właśnie system plików.

Agent korzysta z niego wyłącznie przez wywołania narzędzi — odczyt pliku, zapis pliku czy uruchomienie polecenia powłoki. Nic na dysku nie trafia do okna kontekstu, dopóki wywołanie narzędzia tego nie załaduje. Dzięki temu agent może pracować w repozytorium znacznie większym niż okno: system plików przechowuje wszystko, a kontekst tylko to, co zostało odczytane dla bieżącego zadania. Niektóre środowiska domyślnie ładują do okna kontekstu nazwy plików z bieżącego katalogu — bez ich zawartości, tylko drzewo — co działa jak wskaźniki kontekstu: agent widzi, co istnieje, i odczytuje potrzebne pliki.

System jest współdzielony z Tobą. Pliki edytowane przez agenta to te same pliki, które otwierasz w edytorze i porównujesz w git — system plików jest wspólnym obszarem roboczym, w którym możesz sprawdzić pracę agenta.

Użycie:

„Dlaczego nie ładuje mojego AGENTS.md?”

„Działa na innym systemie plików — piaskownica zamontowała katalog nadrzędny, a nie katalog główny projektu. Zmień katalog roboczy środowiska.”

Funkcja udostępniana przez harness, którą może wywołać agent — na przykład Read, Write, Bash, Search. Narzędzia pozwalają agentowi postrzegać i zmieniać środowisko: widzi je wyłącznie przez wyniki narzędzi, a zmienia tylko przez wywołania narzędzi. Każde wywołanie narzędzia wymaga dodatkowego żądania do dostawcy modelu, ponieważ wynik musi wrócić do modelu, zanim zdecyduje, co zrobić dalej.

Narzędzia dołączane do większości agentów programistycznych:

Definicję narzędzia tworzą trzy elementy: nazwa, opis działania oraz schemat parametrów. Przy każdym żądaniu harness przesyła te definicje do modelu, a model wybiera narzędzie tak samo, jak tworzy pozostałe treści — zapisując tokeny, w tym przypadku uporządkowane wywołanie z argumentami. Model sam niczego nie wykonuje; harness odczytuje wywołanie, uruchamia funkcję i odsyła wynik.

Lista narzędzi określa, co agent może robić. Model o dużych możliwościach z wąskim zestawem narzędzi staje się wąskim agentem: wszystko próbuje wykonać tym, co ma, dlatego agenci tak często polegają na Bash — powłoka to jedno narzędzie dające dostęp do większości systemu. Aby przyznać agentowi konkretną możliwość, dodaj do niego narzędzie; MCP jest standardem podłączania narzędzi spoza harnessu.

Definicje narzędzi zajmują miejsce w kontekście przy każdym żądaniu, więc duży zestaw narzędzi generuje stały koszt, zanim którekolwiek zostanie wywołane. Wiele podobnie opisanych narzędzi dodatkowo utrudnia modelowi wybór właściwego.

Użycie:

"Czy agent może bezpośrednio odpytwać środowisko stagingowe?"

"Dodaj harnessowi narzędzie `psql`, ograniczone do odczytu w stagingu. Bez narzędzia agent nie widzi niczego poza systemem plików."

Tekst wyjściowy model, który wskazuje narzędzie i jego argumenty — po prostu uporządkowany tekst. Samo niczego nie robi; harness musi je odczytać i wykonać. Model tworzy je w ramach jednego żądania do dostawcy modelu.

Cykl życia wywołania narzędzia:

Jedna tura pracy agenta zwykle obejmuje wiele takich połączonych wymian.

Ponieważ wywołanie powstaje przez przewidywanie następnego tokenu, tak jak pozostałe odpowiedzi, może być błędne: ścieżka może nie istnieć, polecenie może nie obsługiwać danej flagi, a argumenty mogą tylko wyglądać wiarygodnie. Harness wykonuje to, co zapisano, a nie to, co zamierzano — literówka w ścieżce nie kończy się łagodnym błędem, tylko edycją niewłaściwego pliku.

Użycie:

"Twierdził, że uruchomił testy, ale znaczniki czasu plików się nie zmieniły."

"Sprawdź transkrypt — czy rzeczywiście wysłał wywołanie narzędzia, czy tylko opisał uruchamianie testów? Model tworzy wywołanie, ale jeśli harness go nie wykonał, nic się nie stało."

To, co harness odsyła po wykonaniu wywołania narzędzia — zawartość pliku, wynik polecenia, błąd. To jedyny widok agenta na środowisko. Wynik wraca do modelu w następnym żądaniu do dostawcy modelu, a model decyduje, co z nim zrobić. Wywołanie narzędzia i jego wynik są dwoma końcami tej samej wymiany, zachodzącej w obrębie jednej tury.

Cykl życia wyniku narzędzia:

Wynik pozostaje w kontekście przez resztę sesji. Wyniki narzędzi zwykle zajmują większość kontekstu sesji programistycznej: w całości trafia do niego każdy odczyt pliku, uruchomienie testów i wyszukiwanie, które zużywają tokeny długo po tym, jak przestają być przydatne. Kilka obszernych wyników — rozwlekły log testów, odczyt całego wygenerowanego pliku — może zapełnić okno kontekstu szybciej niż sama rozmowa.

Ponieważ model widzi tylko wynik, nie ma sposobu, by sprawdzić ukryte za nim środowisko. Jeśli wynik został ucięty, polecenie po cichu się nie powiodło albo harness zwrócił błąd zamiast zawartości, model rozumuje na podstawie tego, co otrzymał. Gdy obraz systemu przedstawiany przez agenta wydaje się błędny, sprawdź wyniki narzędzi: gdzieś w transkrypcie znajduje się wynik sprzeczny z tym, co wiesz.

Użycie:

"Rozumuje o tym pliku tak, jakby był pusty."

"Wynik narzędzia zawierał odmowę dostępu, a nie treść. Model widział tylko komunikat błędu — nie ma innego sposobu, by zobaczyć plik."

Model Context Protocol. Protokół łączenia zewnętrznych serwerów narzędzi z harnessem — dzięki niemu agent otrzymuje narzędzia, których harness nie udostępnia wbudowanych. Agent nigdy nie „wywołuje MCP”; wywołuje narzędzie, które harness akurat pobrał z serwera MCP. Protokół udostępnia też zasoby (dane tylko do odczytu) i prompty (wielokrotnego użytku szablony), ale jego głównym zastosowaniem jest dostarczanie narzędzi.

Protokół rozwiązuje problem integracji. Bez wspólnego standardu każdy harness musiałby mieć własną integrację z Linear, własną integrację ze Slackiem i własną integrację z bazą danych — każdą napisaną i utrzymywaną osobno. Dzięki MCP integrację pisze się raz, jako serwer, a każdy zgodny z MCP harness może z niej korzystać. Harness łączy się z serwerem, serwer ogłasza dostępne narzędzia, a one stają się dla agenta dostępne obok narzędzi wbudowanych.

Koszt ponosi kontekst. Każde narzędzie ogłaszane przez serwer pojawia się jako definicja — nazwa, opis, schemat parametrów — a model może wywoływać tylko te narzędzia, o których wie. Naiwne podejście ładuje od razu wszystkie definicje do okna kontekstu: zainstaluj kilka rozbudowanych serwerów, a sesja rozpocznie się od tysięcy tokenów schematów narzędzi, zanim cokolwiek wpiszesz, zużywając budżet uwagi na narzędzia, których zadanie nigdy nie użyje.

Wiele harnessów ogranicza dziś ten koszt przez wyszukiwanie narzędzi: zamiast pełnych definicji kontekst zawiera wskaźnik kontekstu do dostępnych narzędzi — agent wyszukuje narzędzie po nazwie lub przeznaczeniu i ładuje jego definicję dopiero wtedy, gdy jej potrzebuje. Jeśli twój harness tego nie robi, koszt początkowy nadal obowiązuje, dlatego warto włączać tylko serwery potrzebne danemu projektowi.

Użycie:

"Agent musi odczytywać zgłoszenia z Linear."

"Skonfiguruj harness, aby używał serwera MCP Linear — udostępnia on agentowi API Linear w postaci wywoływanych narzędzi. Dzięki temu nie musisz pisać własnych nakładek na narzędzia."

To, co harness pokazuje użytkownikowi przed wykonaniem niezatwierdzonego wywołania narzędzia. Model tworzy wywołanie narzędzia, ale harness zamiast od razu je uruchomić, zatrzymuje pracę i pyta o zgodę. Po zatwierdzeniu wykonuje wywołanie; po odmowie przekazuje informację o odmowie modelowi jako wynik narzędzia. To mechanizm, który włącza człowieka do pętli przy działaniach ryzykownych lub wrażliwych.

Cykl życia prośby o zgodę:

Odmowa kieruje dalszą pracą agenta. Model odczytuje ją jak każdy inny wynik narzędzia i reaguje — próbuje innego podejścia albo pyta, co wolisz. Większość harnessów pozwala dołączyć wiadomość do odmowy, dzięki czemu prośba staje się punktem, w którym można pokierować pracą: „nie w ten sposób, użyj zamiast tego skryptu migracyjnego” trafia do modelu dokładnie wtedy, gdy decyduje, co zrobić dalej.

Kosztem jest to, że każda prośba wymaga synchronicznego oczekiwania na ciebie. Agent czeka bezczynnie na odpowiedź; to nie problem, gdy obserwujesz pracę, ale przeszkoda, gdy cię nie ma — agenta stale wywołującego prośby nie można zostawić do pracy AFK. Pokrętłem jest tryb uprawnień: które wywołania przechodzą automatycznie, a które wymagają zgody. Dobrze też użyć piaskownicy, aby bezpieczniej poszerzyć zbiór działań dozwolonych bez pytania.

Użycie:

"Od dziesięciu minut czeka na moją zgodę — byłem na spotkaniu."

"Taki jest koszt udziału człowieka w pętli. Zatwierdź wcześniej bezpieczne narzędzia, żeby pytało tylko przy rzeczywiście ryzykownych wywołaniach."

Część trybu agenta, która kontroluje uprawnienia — które wywołania narzędzi wymagają prośby o zgodę, a które są wykonywane automatycznie. To pierwotny cel systemów trybów, zanim harnessy zaczęły dokładać do nich instrukcje dotyczące zachowania.

Harnessy udostępniają zestaw takich trybów:

Wybór poziomu to kompromis między bezpieczeństwem a przerwami; odczuwa się skutki obu skrajności. Zbyt restrykcyjnie — i stajesz się wąskim gardłem: agent zatrzymuje się co kilka sekund, by zapytać o nieszkodliwy odczyt, klikasz zgodę automatycznie, a zatwierdzenia przestają cokolwiek znaczyć. Bezrefleksyjne zatwierdzanie to najgorszy wariant obu światów: wszystkie przerwy, żadnej ochrony. Zbyt luźno — i agent edytuje pliki oraz uruchamia polecenia, które wolałbyś wcześniej zobaczyć.

Najłatwiej uzasadnić luźniejsze ustawienia wewnątrz piaskownicy, gdzie zasięg szkód po złym wywołaniu narzędzia jest ograniczony. Poza nią większość osób wybiera automatyczne zatwierdzanie odczytów i pozostawia człowieka w pętli przy działaniach nieodwracalnych.

Użycie:

"Zatrzymywał się przy każdym grep — całkowicie zniweczyło to przebieg AFK."

"Poluzuj tryb uprawnień dla narzędzi tylko do odczytu, a przy zapisie i powłoce nadal pytaj. Większość próśb o zgodę podczas sesji badawczej to szum."

Ustawienie wstępne określające sposób działania agenta w czasie wykonywania — łączy tryb uprawnień z instrukcjami dotyczącymi zachowania, wstrzykiwanymi do promptu systemowego. Przykłady: ustawienie domyślne, które pyta przed ryzykownymi wywołaniami; tryb planowania, który blokuje edycje i kieruje agenta ku badaniu; tryb akceptowania edycji, który automatycznie zatwierdza zmiany; tryb omijania uprawnień (potocznie tryb YOLO), który zatwierdza wszystko. Można go zmienić w trakcie sesji.

Połączenie tych elementów odróżnia tryb od samego ustawienia uprawnień. Tryb uprawnień to tylko bramka: decyduje, które wywołania narzędzi są przepuszczane. Sama bramka tworzy agenta, który chce edytować, ale nie może — proponuje zapis, zostaje zablokowany i próbuje inaczej. Wstrzyknięte instrukcje usuwają samo pragnienie edycji: tryb planowania nie tylko blokuje zmiany, lecz także informuje agenta, że jest w fazie planowania, więc agent czyta, pyta i proponuje zamiast walczyć z bramką. Bramka i wskazówki prowadzą w tym samym kierunku.

W praktyce zmieniasz tryb wraz ze zmianą zaufania w trakcie zadania. To samo zadanie może przechodzić przez kilka trybów: planowanie, gdy kształtuje się podejście; tryb domyślny z pytaniami, gdy wprowadzane są pierwsze delikatne zmiany; akceptowanie edycji, gdy agent pokaże, że rozumie zakres; omijanie uprawnień podczas przebiegu AFK w piaskownicy. Zmiana trybu nic cię nie kosztuje: rozmowa toczy się dalej dokładnie w tym samym miejscu, za to z nowymi uprawnieniami i instrukcjami. Jeśli zatwierdzasz każde pytanie, nawet go nie czytając, tryb jest bardziej restrykcyjny niż twoje faktyczne zaufanie; jeśli ciągle odrzucasz edycje — jest zbyt liberalny.

Terminy dostawców: Claude Code nazywa je „trybami uprawnień”, a Codex — „trybami zatwierdzania”; oba określenia pochodzą sprzed połączenia ustawień z instrukcjami zachowania.

Użycie:

"Ciągle edytuje pliki, a ja chcę tylko plan."

"Przełącz na tryb planowania — zablokuje zapisy i pozostanie w fazie badania."

"A co z późniejszym przebiegiem AFK?"

"Tryb omijania uprawnień, ale tylko w piaskownicy."

Odizolowane środowisko, w którym działa agent — kontener, maszyna wirtualna, tymczasowy system plików albo powłoka z ograniczonymi uprawnieniami. Ogranicza zasięg działań agenta: nawet jeśli uruchomi destrukcyjne polecenie lub pobierze coś złośliwego, szkody pozostają w obrębie izolacji. To warstwa bezpieczeństwa, dzięki której praca AFK staje się praktyczna.

Piaskownica i tryb uprawnień rozwiązują ten sam problem z przeciwnych stron. Uprawnienia wymagają zgody przed wykonaniem działania; piaskownica ogranicza zasoby, do których działanie może dotrzeć, jeśli zostanie uruchomione. Uprawnienia wymagają twojej obecności w pętli — każde pytanie przerywa pracę — a sesja, która bez przerwy o coś pyta, jest ledwie autonomiczna. Piaskownica zużywa zasoby infrastruktury zamiast twojej uwagi: im silniejsza izolacja, tym mniej trzeba pytać.

Izolacja ma różne poziomy:

Żadna piaskownica nie obejmuje działań, które legalnie ją opuszczają. Agent mający twoje poświadczenia Git może wypchnąć zmiany; agent z dostępem do sieci może wywoływać produkcyjne API. Zanim zdecydujesz, jak szczelna ma być izolacja, ustal, co może przekraczać jej granicę.

Użycie:

"Chcę pozwolić mu pracować przez noc z ominięciem uprawnień, ale nie jestem jeszcze na to gotowy."

"Umieść go w piaskownicy — świeży kontener, bez zamontowanych poświadczeń i bez dostępu do sieci. W najgorszym razie skasuje własny system plików, a ty wyrzucisz kontener."

Pewnie brzmiąca, zgodna z rozmówcą odpowiedź modelu. Wynika z trenowania: model został ukształtowany tak, by preferować odpowiedzi lubiane przez ludzi, a ludzie częściej lubią zgodę niż informację, że się mylą. Model nauczył się więc, że zgoda jest nagradzana — nawet gdy jest błędna.

Ujawnia się jako:

• Uleganie naciskom — zmiana poprawnej odpowiedzi po pytaniu „na pewno?”.
• Pochwała złych danych wejściowych — uznanie wadliwego planu za genialny, zanim zostanie przeanalizowany.
• Stronnicze przedstawianie — przegląd jest pozytywny, gdy zaznaczysz, że napisałeś kod, a negatywny, gdy wskażesz kogoś innego. Ten sam artefakt, inny werdykt.
• Naśladowanie — powtarzanie Twoich błędów w formie potwierdzenia.

Test diagnostyczny: czy model powiedziałby to samo bez Twojej sugestii? Jeśli zmienił się tylko ton lub sposób przedstawienia, to schlebianie, a nie rzeczywista zmiana analizy.

Rozwiązanie: ukryj swoje preferencje. Formułuj prompty neutralnie — „przejrzyj ten kod”, a nie „czy ten kod jest dobry?”.

Unikaj: używania słowa „schlebianie” wobec każdej błędnej odpowiedzi, która akurat Ci się podoba. Bez testu diagnostycznego termin nie znaczy więcej niż „błędna odpowiedź”.

Użycie:

„Powiedział, że mój plan refaktoryzacji wygląda świetnie, a potem zapytałem «na pewno?» i całkowicie się wycofał”.

„Typowe schlebianie — najpierw się zgodził, bo brzmiałeś pewnie, potem ustąpił, bo zabrzmiałeś niepewnie. Jakość planu się nie zmieniła — zmienił się Twój ton. Wyczyść kontekst i zapytaj ponownie, nie sygnalizując stanowiska.”

Pewne siebie, lecz błędne wyjście modelu. Dwa rodzaje błędu, z różnymi przyczynami i sposobami naprawy:

Przewidywanie następnego tokenu tworzy płynną wypowiedź niezależnie od tego, czy stojący za nią fakt jest prawdziwy — model nie ma wewnętrznego sygnału, że czegoś nie wie, więc zmyślona metoda pojawia się równie pewnym tonem co poprawna. Zmyślony kod jest z założenia wiarygodny: wygląda tak, jak wyglądałoby API, gdyby istniało. Dlatego łatwo prześlizguje się przez pobieżny przegląd, a zawodzi dopiero po uruchomieniu.

Trzeba rozpoznać, z którym rodzajem błędu mamy do czynienia, bo naprawa jednego pogarsza drugi. Błąd prawdziwości oznacza brak wiedzy; trzeba dodać kontekst — dokumentację, definicje typów, plik. Błąd wierności oznacza, że wiedza jest obecna, ale przegrywa walkę o uwagę; należy usunąć część kontekstu. Jeśli błędnie rozpoznasz problem wierności jako brak wiedzy, dokleisz więcej dokumentacji, zwiększysz kontekst i pogłębisz odchylenie. Gdy agent się myli, przed wyborem rozwiązania sprawdź, czy poprawna informacja była już w kontekście.

Unikaj: używania słowa „halucynacja” jako ogólnego synonimu „błędu” — bez wskazania rodzaju problemu termin nie pomaga go diagnozować.

Użycie:

"Zmyślił metodę `parseAsync` w schemacie."

"Błąd prawdziwości czy wierności?"

"Metoda była w dokumentacji, którą wkleiłem — po prostu przestał ją czytać po czterdziestej turze."

"Czyli problem z wiernością. Skompaktuj kontekst i załaduj go ponownie; nie doklejaj kolejnych dokumentów."

To, co model „wie” z treningu, jest zapisane w jego parametrach. Parametry zostają zamrożone w chwili treningu — model nie może ich zobaczyć ani zaktualizować. Szczegóły giną w kompresji: miliardy faktów upychane są w skończonej liczbie parametrów, a te rzadkie zacierają się. Stąd płynność wypowiedzi na częste tematy i zmyślanie na rzadkie. Przeciwieństwem jest wiedza kontekstowa.

Wiedza parametryczna nie jest przechowywana w postaci faktów. Podczas treningu model nie dostaje bazy danych do przeszukiwania; parametry są dostrajane tak, by model dobrze przewidywał tekst, a model, który dobrze przewiduje tekst o danym temacie, zachowuje się tak, jakby go znał. Wiarygodność tej wiedzy zależy od tego, jak często temat pojawiał się w danych treningowych: temat poparty milionami przykładów jest odtwarzany trafnie, a przy zaledwie kilku model zgaduje na podstawie podobnych tematów. Dla modelu odtwarzanie i zgadywanie to ten sam proces, więc nie potrafi rozpoznać, który właśnie zachodzi. Zmyślona odpowiedź brzmi równie płynnie jak poprawna. Halucynacja to błędne zgadywanie modelu.

Wiedza parametryczna z czasem się starzeje. Parametry przestają się zmieniać po dacie odcięcia wiedzy, więc biblioteka wydana lub przemianowana później nie jest w nich uwzględniona, a zmienione API zostaje zapamiętane w dawnej postaci.

W obu przypadkach — gdy wiedza jest zbyt rzadka albo zbyt nowa — rozwiązanie jest takie samo: nie można dodać jej do parametrów, trzeba więc dostarczyć ją jako wiedzę kontekstową.

Użycie:

"Pisze bezbłędny kod w React, ale wymyśla metody naszego wewnętrznego SDK."

"Wiedza parametryczna o React jest gęsta — miliony przykładów treningowych. O twoim SDK model ich nie ma, więc uzupełnia luki wiarygodnie wyglądającymi konstrukcjami. Załaduj dokumentację SDK do kontekstu."

Data, po której model nie ma już wiedzy parametrycznej. Biblioteki, API i wydarzenia późniejsze niż ta data stają się pułapkami prowadzącymi do zmyśleń, chyba że ich dokumentacja zostanie załadowana jako wiedza kontekstowa. Każde wydanie modelu ma własną datę graniczną.

Granica wynika ze sposobu tworzenia modeli: trenowanie zapisuje migawkę tekstu w parametrach modelu, które później zostają zamrożone. Model nie wie, że jego wiedza ma krawędź — zapytany o coś późniejszego niż data graniczna nie odmawia, tylko ekstrapoluje na podstawie najbliższych znanych mu informacji. Na tym polega podstępność tej pułapki: kod napisany dla starej wersji biblioteki wygląda wiarygodnie, często się kompiluje, a zawodzi w miejscach, które uległy zmianie.

Rozwiązanie jest zawsze takie samo: wprowadź aktualne informacje do kontekstu. Załaduj changelog, wskaż definicje typów z zainstalowanej wersji albo poproś agenta o odczytanie dokumentacji z sieci. Wszystko, co jest w kontekście, ma pierwszeństwo przed tym, czego nie ma w parametrach.

Użycie:

„Wciąż pisze składnię SDK v3, a my korzystamy z v5”.

„Wersja v5 ukazała się po dacie granicznej wiedzy. Załaduj jej changelog jako wiedzę kontekstową, inaczej nadal będzie zmyślał na podstawie starszej wersji parametrycznej.”

Fakty, które agent może teraz bezpośrednio odczytać z kontekstu — zadanie użytkownika, wczytane przez agenta pliki, wyniki narzędzi, treść AGENTS.md załadowana na początku sesji. Przeciwieństwo wiedzy parametrycznej: wiedza parametryczna jest przywoływana z parametrów, a kontekstowa — odczytywana z okna. Halucynacje są znacznie rzadsze, gdy agent korzysta z wiedzy kontekstowej — odpowiedź ma przed sobą, zamiast wydobywać ją z niewyraźnego wspomnienia.

Spośród tych dwóch rodzajów wiedzy tylko wiedza kontekstowa podlega twojej kontroli. Parametry są zamrożone, więc jedyny sposób, by przekazać modelowi brakującą wiedzę — o wewnętrznym SDK, bibliotece wydanej po dacie odcięcia wiedzy, wczorajszej decyzji — to umieszczenie jej w kontekście. Duża część praktycznej pracy programistycznej z AI sprowadza się do tego, by w odpowiednim momencie podsunąć modelowi właściwe fakty.

Gdy wiedza kontekstowa i parametryczna są sprzeczne, zwykle wygrywa kontekstowa. Wklej aktualną dokumentację API, a model zastosuje ją zamiast nieaktualnej wiedzy o dawnym API — choć stare informacje mogą nadal się przebijać, zwłaszcza w długiej sesji. Jeśli agent mimo załadowanej dokumentacji ciągle wraca do przestarzałego wzorca, oznacza to, że wiedza parametryczna przedostaje się przez kontekst; ponowne sformułowanie poprawki albo przesunięcie jej bliżej bieżącej pracy może pomóc.

W przeciwieństwie do wiedzy parametrycznej korzystanie z wiedzy kontekstowej ma swoją cenę. Wszystko, co załadowano do okna, zużywa tokeny i konkuruje o budżet uwagi modelu, więc więcej nie zawsze znaczy lepiej — celem są odpowiednie fakty w oknie, a nie wszystkie fakty.

Używaj tego terminu tylko przy porównaniu z wiedzą parametryczną; w pozostałych przypadkach wystarczy powiedzieć kontekst.

Unikaj: określenia „pamięć robocza” — wiedza kontekstowa to informacje znajdujące się w oknie teraz; system pamięci przenosi do niego dane między sesjami. To różne skale, których nie należy mylić.

Użycie:

"Dlaczego trafnie korzysta z API, gdy wklejam dokumentację, a zmyśla, gdy tego nie robię?"

"Z dokumentacją ma wiedzę kontekstową — odczytuje ją z tekstu. Bez niej korzysta z wiedzy parametrycznej, w której rzadkie punkty końcowe się zacierają."

Przewidując każdy token, model uwzględnia wszystkie pozostałe tokeny w kontekście — jedne bardzo mocno, inne ledwie zauważalnie. Powiązanie między dwoma tokenami nazywa się relacją uwagi; znaczące pary („ona” i „Sarah” albo wywołanie `getUser()` i definicja `function getUser`) silniej na siebie wpływają niż pary niezwiązane. Dla kontekstu zawierającego N tokenów istnieje rząd wielkości N² takich relacji.

To właśnie w tych powiązaniach mieści się pozorne rozumienie modelu. Gdy rozwiązuje zaimek, dzieje się tak dlatego, że relacja uwagi między „nią” a „Sarah” jest silna. Gdy wywołuje funkcję z właściwymi argumentami, działa relacja między miejscem wywołania a wcześniej odczytaną definicją. Niczego tu się nie wyszukuje — dla każdej pary obliczenie jest wykonywane od nowa przy każdym żądaniu do dostawcy modelu.

Warto się zastanowić nad wartością N², bo rośnie szybciej, niż podpowiada intuicja:

Każdą parę oblicza się więcej niż raz. Modele mają wiele głowic uwagi — dokładne liczby dla modeli najnowszej generacji nie są publikowane, ale rozsądnym szacunkiem jest od 50 do 100 — a każda głowica oblicza własną wersję każdej relacji. Oznacza to, że każda para w tabeli powyżej jest powielana dla każdej głowicy. Tych par jest naprawdę dużo.

W konkretnym zadaniu istotna jest tylko niewielka część tych relacji. Powiązanie między twoją instrukcją a kodem, którego dotyczy, jest jedną z nielicznych ważnych par; niemal wszystkie pozostałe to szum. Obie liczby rosną w innym tempie: liczba ważnych relacji pozostaje mniej więcej stała, podczas gdy cała pula rośnie kwadratowo wraz z rozmiarem kontekstu. Przy 1 000 tokenów ważna dla ciebie para stanowi jedną na milion; przy 100 000 tokenów — jedną na dziesięć miliardów. To matematyczna podstawa budżetu uwagi, a degradacja uwagi opisuje odczucie, gdy istotne relacje stanowią zbyt małą część puli.

Użycie:

"Ciągle myli dwa symbole `user` w diffie — chyba jesteśmy w strefie otępienia."

"Tak, relacja uwagi między każdym miejscem wywołania a jego deklaracją konkuruje z drugą — taki sam kształt tokenu, inne powiązanie. Zmień jedną nazwę, a pary staną się wyraźniejsze."

Każdy token ma ograniczoną ilość wpływu do rozdzielenia na resztę kontekstu. Silny wpływ na jedną zależność zostawia mniej dla pozostałych. Budżet dotyczy każdego tokenu osobno i nie rośnie wraz z kontekstem, dlatego długie sesje rozmywają jego uwagę.

Pomyśl o tym jak o sygnale i szumie. Twoja instrukcja jest sygnałem o stałej głośności; każdy inny token w oknie kontekstu to konkurujący dźwięk. Instrukcja sama nie cichnie — nadal jest tam znak po znaku — ale gdy kontekst rośnie, wokół niej robi się głośniej i spada stosunek sygnału do szumu. Instrukcja, która przy 10 tysiącach tokenów kontekstu była najgłośniejsza, przy 150 tysiącach staje się tłem. To mechanizm degradacji uwagi: model nie zapomina; sygnał ginie w szumie.

Objaw wygląda jak nieposłuszeństwo — agent wcześniej zgodził się na ograniczenie, potem się od niego oddala, a ponowne wklejenie pomaga tylko na chwilę. Przyczyną nie jest instrukcja, lecz cała reszta okna konkurująca z nią o uwagę.

Masz kontrolę nad tym, co trafia do kontekstu. Treść, która nie służy zadaniu, nie jest obojętna — stanowi szum zagłuszający wszystko, co jest przydatne. Utrzymuj okno małe, czyść je, gdy nagromadzony kontekst przestaje być użyteczny, i ponownie podawaj ważne ograniczenia zamiast zakładać, że ich wczesna wzmianka wystarczy.

Użycie:

„Dlaczego ciągle ignoruje schemat, który wkleiłem na początku?”

„Jesteśmy głęboko w strefie słabego myślenia — budżet uwagi każdego tokenu jest stały, ale kontekst wciąż rósł. Sygnał dotyczący schematu konkuruje teraz z tysiącami nowszych tokenów.”

W miarę jak rośnie sesja, budżet uwagi każdego tokena rozdziela się między coraz większą liczbę konkurujących elementów. Sygnał dotyczący konkretnej znaczącej zależności słabnie, a napływający nieistotny kontekst zagłusza go. Ten sam model, te same parametry — tylko więcej osób przy tym samym stole. To przyczyna efektu strefy jasnego i słabego myślenia.

Objawia się to pogorszeniem modelu w trakcie sesji: ograniczenia przestrzegane przez godzinę zaczynają być pomijane, model ponownie pyta o rzeczy, które już mu przekazano, albo pisze kod ignorujący wcześniej przeczytany plik. Model się nie zmienił — jedyną zmienną jest ilość kontekstu, na który musi teraz zwracać uwagę.

Pogorszenie jest stopniowe, dlatego trudno je zauważyć w trakcie sesji. Nie ma błędu ani konkretnego progu; każda tura jest tylko nieznacznie gorsza od poprzedniej, a gdy potknięcia stają się oczywiste, od pewnego czasu przebywasz już w strefie słabego myślenia.

Odzyskujesz sprawność, usuwając kontekst, a nie dodając go więcej. Ponowne wklejenie zignorowanej instrukcji dodaje kolejnego konkurenta do tego samego zatłoczonego okna i pomaga tylko przez chwilę. Skuteczne działania to wyczyszczenie kontekstu i ponowne załadowanie tylko tego, czego wymaga zadanie, skompaktowanie go albo przekazanie pracy do nowej sesji. Spadek przestrzegania instrukcji traktuj jako sygnał dotyczący długości kontekstu, a nie modelu.

Użycie:

„Jest głęboko w strefie słabego myślenia — wymyśla typy generyczne, których nie ma w pliku typów”.

„Degradacja uwagi. Definicje typów nadal są w kontekście, ale zagłuszyło je wszystko, co dodaliśmy od tamtej pory. Wyczyść i załaduj ponownie.”

Na początku sesji agent znajduje się w „strefie skupienia” — jest bystry, skoncentrowany i dobrze sobie przypomina. Wraz z wydłużaniem sesji osuwa się w „strefę otępienia”: robi się mniej staranny, zapomina więcej i popełnia więcej błędów — również halucynacji wynikających z utraty wierności (halucynacje). Ten sam model, ten sam harness — tylko więcej kontekstu. Tak odczuwa się degradację uwagi. W przypadku modeli najnowszej generacji strefa otępienia często zaczyna się przy około 125–150 tys. tokenów, choć jest to przedmiotem dyskusji. Gdy sesja puchnie, wyczyść kontekst albo go skompaktuj; nie próbuj za wszelką cenę kontynuować.

Pogorszenie następuje stopniowo, dlatego łatwo je przeoczyć. Nie pojawia się komunikat o błędzie ani wyraźna granica; agent po prostu najpierw działa nieco gorzej, a potem wyraźnie gorzej. Częste oznaki: zapomina instrukcję podaną dwadzieścia tur temu, powtarza błąd, który już poprawił, albo z przekonaniem twierdzi coś sprzecznego z kontekstem. Ponieważ pogorszenie jest płynne, typową reakcją jest kontynuowanie pracy i ponowne wyjaśnienie problemu — co dodaje kontekst i pogarsza sytuację.

Strefy nie zależą od limitu okna kontekstu. Sesja może być głęboko w strefie otępienia, gdy większość okna pozostaje wolna: limit wyznacza moment, w którym harness odmawia dalszej pracy, ale jakość spada dużo wcześniej. Planuj z myślą o strefie skupienia, nie o rozmiarze okna — praktyczny budżet zadania to liczba tokenów, przy której agent działa dobrze, a nie liczba, którą technicznie jest w stanie pomieścić.

Strefa skupienia to budżet, który zużywają niezwiązane zadania. Każde zadanie wykonane w sesji zajmuje tokeny, więc rozpoczęcie drugiego w tej samej sesji oznacza wejście bliżej strefy otępienia. Jedno zadanie na sesję pozwala każdemu skorzystać z jej najostrzejszej fazy. Jeśli jedno zadanie jest większe niż strefa skupienia, podziel je: przekaż pracę albo skompaktuj kontekst w naturalnym miejscu i pozwól nowej sesji wykonać następną część.

Użycie:

"Świetnie poradził sobie z pierwszymi trzema komponentami, a czwarty kompletnie zepsuł."

"Wyszedłeś ze strefy skupienia — ten sam model, ale już głęboko w strefie otępienia. Skompaktuj kontekst i ponownie załaduj plan; następny komponent powinien wyjść dobrze."

Zakończenie bieżącej sesji i rozpoczęcie nowej. Następna wiadomość trafia do pustej sesji z pustym oknem kontekstu. Zwykle decyduje o tym użytkownik.

Lekarstwem na zanieczyszczony kontekst jest jego wyczyszczenie. Sesja gromadzi wszystko: nieudane próby, błędne kierunki, nieaktualne wyniki narzędzi, porzucone plany. Model odczytuje całość ponownie w każdej turze, a zła historia obciąża nową pracę. W głębokiej fazie długiej sesji agent staje się mniej precyzyjny i mniej posłuszny — wyraźnie przekazane instrukcje są ignorowane, jakość spada, a ponaglanie go nic nie daje, bo nadal brodzi w szumie kontekstu. Wyczyszczenie usuwa ten szum.

Wyczyszczenie nie kasuje rozmowy. Większość środowisk przechowuje historię sesji na komputerze, więc transkrypt nadal można przeczytać lub wznowić. Usunięty zostaje stan roboczy agenta: model jest bezstanowy, dlatego nowa sesja niczego nie wie o tym, co wiedziała poprzednia. Jeśli sesja zawiera decyzje lub postępy potrzebne w następnej, poproś agenta, by najpierw utworzył artefakt przekazania, a nową sesję rozpocznij od wskazania go.

Porównaj z kompaktowaniem, które podsumowuje sesję w nowym kontekście zamiast zaczynać od zera. Wyczyszczenie jest bardziej radykalnym narzędziem: nic się nie przenosi, łącznie ze śmieciami.

Użycie:

„Utknął w pętli wokół nieudanego testu”.

„Po prostu wyczyść kontekst — rozpocznij nową sesję z dokumentem planu i plikiem testu. Nie ma sensu walczyć z obecnym kontekstem.”

Przeniesienie kontekstu agenta z jednej sesji do drugiej. Sposób przekazania zależy od sytuacji — może to być zapisany artefakt przekazania, podsumowanie w pamięci (kompaktowanie) lub inna metoda. To coś innego niż czyszczenie, przy którym nic się nie przenosi. Powody są różne: zmiana roli (planista → wykonawca), rozpoczęcie przebiegu AFK, rozdzielenie pracy na równoległe sesje albo zwolnienie miejsca w oknie kontekstu.

Sesja odbierająca zaczyna z pustym kontekstem — model jest bezstanowy, więc nowa sesja nie widzi niczego ze starej. Wszystko, czego będzie potrzebować, trzeba jawnie przenieść; cała reszta przepada. Ograniczeniem kształtującym przekazywane informacje jest „brak drogi powrotnej”: nowa sesja nie może zapytać poprzedniej, co miała na myśli, więc przekazany materiał musi być zrozumiały sam w sobie.

Widocznym skutkiem złego przekazania jest ponowne roztrząsanie decyzji: nowa sesja otwiera sprawy, które poprzednia już rozstrzygnęła, bo przekazano jej same decyzje, bez uzasadnienia. Oceń przekazanie po tym, co potrafiłaby zrobić sesja zaczynająca od zera.

Użycie:

"Sesja planowania robi się ciężka — mam po prostu kontynuować?"

"Przekaż pracę. Zapisz decyzje w dokumencie, wyczyść sesję i rozpocznij implementację w nowej sesji, która go odczyta."

Źródło prawdy w swojej pierwotnej postaci — kod, transkrypt rozmowy, surowy dziennik, rzeczywista odpowiedź API. Nie relacja o czymś, lecz sama rzecz. Przeciwieństwo źródła wtórnego.

Jeśli chcesz wiedzieć, co robi Twoja baza kodu, źródłem pierwotnym jest kod. Dokumentacja, diagram architektury i README są jego opisami — dokładnymi w chwili napisania, a odtąd aktualizowanymi we własnym rytmie. Gdy agent z przekonaniem podaje nieprawdę o Twoim projekcie, zapytaj, z jakiego źródła korzystał: agent, który przeczytał dokument, przejmuje jego nieaktualność; agent, który przeczytał kod, odczytuje bieżącą prawdę.

Koszt sprawia, że źródła pierwotne nie są wybierane domyślnie. Załadowanie źródła do okna kontekstu jest kosztowne — cały plik, cały transkrypt, każdy token rozliczany jako wejściowy i konkurujący o budżet uwagi. W zamian otrzymujesz kompletność: nikt nie odfiltrował wcześniej informacji według własnej oceny tego, co istotne. Podsumowanie napisane w zeszłym miesiącu nie może zawierać szczegółu, który dopiero dziś okazał się ważny; źródło pierwotne wciąż go zawiera.

Sięgaj po źródło pierwotne, gdy liczy się precyzja — dokładny podpis, rzeczywisty błąd, wiersz, w którym następuje wyjątek. Znaczna część zarządzania kontekstem polega na ustaleniu, kiedy warto zapłacić za źródło pierwotne, a kiedy wystarczy źródło wtórne.

Użycie:

„Agent twierdzi, że logika ponawiania prób stosuje wykładnicze opóźnienie, ale widzę, że nieustannie uderza w punkt końcowy”.

„Wywnioskował to z dokumentu projektowego. Wskaż mu rzeczywisty moduł ponawiania prób — gdy liczy się zachowanie, pracuj na podstawie źródła pierwotnego.”

Opis źródła pierwotnego, oddalony od niego o jeden krok — dokumentacja opisująca kod, podsumowanie opisujące transkrypt, raport opisujący wyniki wyszukiwania. Taki opis taniej załadować do okna kontekstu niż źródło, którego dotyczy, a z definicji gubi on część informacji: jego autor zdecydował, co jest ważne, a czytelnik korzystający wyłącznie z podsumowania nie widzi tego, co pominięto.

Duża część inżynierii kontekstu polega na tworzeniu źródeł wtórnych. Kompaktowanie zamienia historię sesji w podsumowanie, od którego zaczyna się kolejna sesja. Podagent poświęca własny kontekst na chaotyczne wyszukiwanie, po czym zwraca krótki raport. Artefakt przekazania kondensuje decyzje z sesji w dokumencie, który czyta następna sesja. Systemy pamięci destylują wiedzę zdobytą podczas sesji do notatek. Każda z tych metod wymienia wierność na dodatkowe miejsce.

Źródła wtórne zawodzą na dwa sposoby. Gubią informacje — podsumowanie po kompaktowaniu pomija decyzję o schemacie, raport nie wspomina o przypadku brzegowym. Mogą też się zdezaktualizować — źródło pierwotne się zmienia, a opis nie nadąża, więc dokumentacja przedstawia architekturę z zeszłego kwartału z pewnością właściwą dla bieżącego. Gdy agent działa na podstawie źródła wtórnego, które zawodzi w którykolwiek z tych sposobów, z przekonaniem opiera się na błędnych informacjach; rozwiązaniem jest odesłanie go do źródła pierwotnego.

Żaden z tych problemów nie oznacza, że źródła wtórne są błędem. Okno kontekstu ma ograniczoną pojemność, a źródła pierwotne są kosztowne; bez podsumowań, raportów i dokumentów przekazania nic dużego się w nim nie zmieści. Sztuka polega na tym, by wiedzieć, które szczegóły mogą przetrwać skrócenie — i weryfikować informacje w źródle pierwotnym, gdy nie mogą. Dobrze przygotowane źródło wtórne zawiera wskaźnik kontekstu prowadzący z powrotem do oryginału — podsumowanie wskazujące transkrypt, z którego powstało, albo dokument podający opisywany plik — tak aby czytelnik mógł podążyć za nim, zamiast polegać na niepełnym opisie.

Użycie:

"Dokument przekazania mówi, że autoryzacja jest gotowa, ale nowa sesja ciągle znajduje błędy w odświeżaniu tokenu."

"Ten dokument jest źródłem wtórnym — poprzednia sesja zapisała to, w co wierzyła, a nie to, co jest prawdą. Poproś nową sesję o uruchomienie testów autoryzacji i zaufaj źródłu pierwotnemu."

Dokument służący do przeniesienia informacji podczas przekazania — jedna sesja zapisuje go w środowisku, a inna go odczytuje. Specyfikacje, zgłoszenia i dokumenty planu to przykłady artefaktów przekazania.

Po co go tworzyć: model jest bezstanowy, więc po wyczyszczeniu sesji nic z niej nie zostaje. Decyzje, ograniczenia, niedokończone plany — wszystko znika wraz z kontekstem, który je zawierał. Środowisko pozostaje. Zapisanie ważnych informacji w pliku przenosi je w miejsce, z którego następna sesja może je odczytać.

Artefakt jest źródłem wtórnym — opisem pracy wykonanej podczas sesji, a nie samą pracą. Dzięki temu można zwięźle wprowadzić nową sesję, ale też łatwo ją wprowadzić w błąd: dokument zapisuje to, w co wierzyła sesja tworząca, a wszystko, co pominęła lub opisała błędnie, pozostaje niewidoczne dla czytelnika. Jeśli jakieś twierdzenie ma znaczenie, następna sesja powinna zweryfikować je w źródle pierwotnym — w kodzie czy testach — zamiast bezkrytycznie je przejąć.

Dobry artefakt przygotowuje się z myślą o sesji zaczynającej od zera. Należy podać konkretne ścieżki plików zamiast pisać „plik, o którym rozmawialiśmy”; wyjaśnić, co postanowiono i dlaczego, żeby następna sesja nie roztrząsała decyzji od nowa; opisać, co już zrobiono i co pozostało. Warto powiedzieć sesji tworzącej, dokąd trafi dokument: „napisz dokument przekazania dla nowej sesji, która nic nie wie o tej pracy”.

Alternatywnym sposobem przenoszenia informacji jest kompaktowanie, które tworzy podsumowanie w pamięci. Artefakt ma dwie zalety: jest zapisany na dysku, więc można go przeczytać i poprawić, zanim cokolwiek od niego zależy, a także można go używać wielokrotnie — ta sama specyfikacja może wprowadzić pięć równoległych sesji.

Użycie:

"Jak podzielić tę pracę między agenta planującego a tego, który ją wdraża?"

"Poproś planistę o utworzenie artefaktu przekazania — ścieżki plików, decyzje, ograniczenia. Sesja wykonawcy rozpocznie się od wskazania tego dokumentu i będzie pracować na jego podstawie."

Artefakt przekazania opisujący pracę obejmującą wiele sesji — co jest tworzone, a nie jak każda sesja ma wykonać swoją część. Zmienia się w miarę postępu pracy. Składa się ze zgłoszeń.

Specyfikacja istnieje, ponieważ sesje są tymczasowe, a duże zadania nie. Każda praca wymagająca więcej niż jednego okna kontekstu potrzebuje miejsca poza kontekstem — w środowisku agenta, które przetrwa wyczyszczenie: może to być plik w repozytorium, zgłoszenie GitHub albo dostępny dla agenta system do obsługi zgłoszeń. Specyfikacja jest takim miejscem: zawiera cel, ograniczenia, dotychczasowe decyzje oraz listę zgłoszeń wraz z ich stanami. Każda nowa sesja może ją przeczytać i zrozumieć stan pracy bez przejmowania nagromadzonego szumu z poprzedniej sesji.

Specyfikacje mają rozpoznawalne style, w większości odziedziczone z tego, jak zespoły już zapisują ustalenia. Dokument wymagań produktu (PRD) skupia się na tym, co i dlaczego widzi użytkownik — funkcjach, zachowaniu, kryteriach akceptacji. Dokument projektowy lub RFC ma charakter techniczny — opisuje wybrane podejście, odrzucone alternatywy i kompromisy. Na najmniejszą skalę tę samą rolę w funkcji rozwijanej przez wiele sesji pełni zwykły plik `plan.md` z listą kontrolną zgłoszeń. Forma ma mniejsze znaczenie niż rola: dla agenta każdy z tych dokumentów jest trwałym zapisem zamiaru, który czyta na początku każdej sesji.

Użycie:

„Czy to wszystko powinno być jedną sesją?”

„Nie, opisz to w specyfikacji — podziel na zgłoszenia i każde realizuj w osobnej sesji. Próba zrobienia wszystkiego w jednym kontekście doprowadzi do strefy słabego myślenia, zanim dojdziesz do połowy.”

Artefakt przekazania wyznaczający zakres pracy jednej sesji. Może istnieć samodzielnie albo być częścią specyfikacji. Zgłoszenia mogą blokować inne zgłoszenia w tym samym zestawie lub same być przez nie blokowane, więc kolejność pracy wynika z grafu zależności, a nie z liniowego planu.

Kluczowym ograniczeniem jest rozmiar: jedna sesja. Zgłoszenie powinno dać się ukończyć, zanim sesja opuści strefę jasnego myślenia — można to sprawdzić. Jeśli sesje dotyczące zgłoszeń regularnie ulegają pogorszeniu, zanim praca zostanie ukończona, zgłoszenia są za duże; podziel je. Jeśli każda sesja zużywa większość kontekstu na przygotowania, zanim wykona pięć minut pracy, zgłoszenia są za małe; połącz je.

Dobre zgłoszenie jest napisane dla czytelnika, który nie ma żadnego innego kontekstu. Zawiera cel, kryteria akceptacji i wskaźniki kontekstu prowadzące do odpowiednich plików i wcześniejszych decyzji — tyle, by sesja mogła rozpocząć pracę bez odtwarzania tego, co wiedziała poprzednia.

Graf zależności pozwala też uruchomić pracę równolegle. Niezależne zgłoszenia — liście grafu — mogą być realizowane w osobnych sesjach w tym samym czasie. To skuteczny sposób równoczesnego uruchamiania wielu agentów. W fabryce oprogramowania oznaczenie zgłoszenia jako gotowego samo uruchamia jego sesję.

Użycie:

„Od czego zacząć w specyfikacji migracji?”

„Sprawdź graf zgłoszeń — zmiana schematu blokuje migrację danych, a migracja blokuje przełączenie API. Wybierz liść i uruchom dla niego sesję.”

Przekazanie wykonywane w pamięci: historia poprzedniej sesji zostaje podsumowana, a podsumowanie zasila nową sesję. Z założenia powoduje utratę informacji: transkrypt jest źródłem pierwotnym, a podsumowanie wtórnym — szczegóły wymienia się na wolne miejsce. Uruchamiane ręcznie przez użytkownika albo automatycznie przez automatyczne kompaktowanie.

Mechanizm jest prosty: okno kontekstu ma ograniczoną pojemność i zapełnia się podczas długiej sesji — w historii zostaje każdy wynik narzędzia, przeczytany plik i błędny kierunek. Gdy zrobi się ciasno, środowisko prosi model o podsumowanie sesji, odrzuca pierwotną historię i rozpoczyna nową sesję z podsumowaniem. Wszystko, czego podsumowanie nie zachowało, znika z kontekstu. Niektóre środowiska łagodzą ten skutek, zachowując stary transkrypt na dysku i dodając do podsumowania wskaźnik kontekstu — źródło wtórne prowadzi wtedy z powrotem do pierwotnego, więc szczegół utracony w podsumowaniu można odzyskać przez ponowne przeczytanie oryginału.

Podsumowanie pisze model, więc można mu podać instrukcje. „Zachowaj decyzje dotyczące schematu” sprawia, że wygenerowany artefakt jest bardziej świadomy. Ważny jest też moment: kompaktuj na granicy fazy, po ustaleniu planu, a nie w środku zadania.

Dla porównania wyczyszczenie odrzuca wszystko i zaczyna od zera: kompaktowanie stara się przenieść najważniejsze informacje, a wyczyszczenie zakłada, że są już zapisane gdzieś lepiej.

Użycie:

„Kontekst robi się ciężki, a mam jeszcze do przejścia test”.

„Skompaktuj go przed rozpoczęciem — wpisz do promptu podsumowania, co musi przetrwać, aby nowa sesja zachowała decyzje o schemacie i odrzuciła eksplorację.”

Kompaktowanie uruchamiane automatycznie przez środowisko, gdy okno kontekstu zbliża się do zapełnienia.

Środowisko obserwuje stopień zapełnienia okna kontekstu. Po przekroczeniu progu — często około 80% — zatrzymuje pracę, prosi model o podsumowanie dotychczasowej sesji i zasiewa nową sesję tym podsumowaniem. Praca jest kontynuowana tak, jakby nic się nie wydarzyło.

A jednak coś się wydarzyło. Kompaktowanie powoduje utratę informacji, a automatyczne kompaktowanie dzieje się w chwili, której nie wybrałeś. Ręczne kompaktowanie wykonuje się na granicy fazy, gdy możesz wskazać modelowi, co ma zachować. Automatyczne uruchamia się w środku zadania po osiągnięciu progu — być może w połowie refaktoryzacji, a podsumowanie samo decyduje, które z Twoich decyzji warto zachować. Typowy objaw: agent działa dalej z pewnością siebie, ale po cichu zapomniał ograniczenie ustalone godzinę temu; zauważasz to dopiero, gdy praca zaczyna mu przeczyć.

Najlepszą ochroną jest niedopuszczenie do automatycznego uruchomienia. Obserwuj wskaźnik kontekstu i wykonuj kompaktowanie ręcznie w naturalnym miejscu granicznym albo zapisuj decyzje w dokumencie planu lub artefakcie przekazania na dysku, gdzie żadne podsumowanie ich nie utraci. Większość środowisk pozwala też dostosować bufor — przesunąć próg wcześniej lub później albo całkowicie wyłączyć automatyczne kompaktowanie — by ustawić zapas, jaki ma pozostać przed uruchomieniem.

Użycie:

„Nie wygląda na to, żeby pamiętał, co wcześniej ustaliliśmy w sprawie schematu”.

„Automatyczne kompaktowanie uruchomiło się między turami — wcześniejsze decyzje podsumowano i coś musiało zniknąć. Załaduj ponownie dokument planu albo następnym razem skompaktuj kontekst ręcznie, by zdecydować, co zachować.”

System, który próbuje zachować stanowość agenta między sesjami. Zapisuje informacje w środowisku podczas sesji i ponownie ładuje je do okna kontekstu na początku kolejnych, aby agent zachował ciągłość nawet po tym, jak użytkownik wyczyści sesję.

System pamięci ma dwie części. Ścieżka zapisu: podczas sesji agent zapisuje poznane informacje — podaną przez Ciebie preferencję albo fakt dotyczący projektu — jako pliki w środowisku. Ścieżka odczytu: na początku sesji środowisko ładuje te pliki lub ich indeks z powrotem do okna kontekstu. Wiele środowisk oferuje własny system pamięci — jednym z nich jest `/memory` w Claude Code — ale możesz też zbudować własny: katalog z notatkami i instrukcję w AGENTS.md, by z niego korzystać.

Obowiązują te same kompromisy, co w przypadku każdej treści ładowanej stale. Pamięć narasta, więc większość systemów ładuje jednowierszowy indeks, a treści pozostawia za wskaźnikami kontekstu, zamiast umieszczać wszystko w kontekście. Pamięci są też źródłami wtórnymi, więc się dezaktualizują: fakt zapisany w marcu zostaje wczytany z takim samym przekonaniem w czerwcu, choć projekt zdążył się zmienić. System pamięci wymaga przycinania, tak samo jak AGENTS.md.

Użycie:

„Ciągle muszę przypominać mu, że używam Postgresa, a nie MySQL”.

„Skonfiguruj system pamięci — niech zapisuje to, czego się nauczy, w systemie plików podczas pierwszej tury, a potem ładuje to przy rozpoczęciu sesji. Sam model jest bezstanowy; warstwa pamięci udaje ciągłość.”

Plik w środowisku, który harness ładuje do okna kontekstu na początku sesji — stała instrukcja projektu dla agenta. To konwencja wspólna dla różnych harnessów; niektóre mają też własny odpowiednik (w Claude Code jest to CLAUDE.md).

Ponieważ plik ładuje się automatycznie, pomaga uniknąć powtarzania tych samych informacji w kolejnych sesjach. Model jest bezstanowy — poprawka podana w jednej sesji znika w następnej, więc każdej nowej sesji trzeba od początku przypominać, że projekt używa pnpm, testy uruchamia się z określoną flagą, a dany katalog jest generowany i nie należy go dotykać. Jeśli dwa razy poprawiono agenta w tej samej sprawie, tę poprawkę warto dopisać do AGENTS.md.

Warto umieszczać tam wszystko, czego agent nie może wywnioskować z kodu: polecenia budowania i testowania, konwencje, które nie są oczywiste w repozytorium, oraz twarde ograniczenia („nigdy nie edytuj wygenerowanego klienta”). Treść powinna być krótka i rzeczowa — to instrukcja, nie dokumentacja.

Kosztem jest to, że cały plik ładuje się za każdym razem. Instrukcje się kumulują, a większość z nich nie ma związku z konkretnym zadaniem. Długi AGENTS.md zużywa tokeny i osłabia sam siebie — im więcej instrukcji znajduje się w kontekście, tym mniej niezawodnie agent stosuje każdą z nich.

Unikaj: umieszczania w AGENTS.md treści, która powinna być ujawniana stopniowo — każda taka treść kosztuje tokeny w każdej turze i każdej sesji, nawet jeśli nie jest potrzebna. Przewodnik stylu można umieścić w umiejętności albo wskaźniku kontekstu; w AGENTS.md zostaw tylko instrukcje obowiązujące zawsze.

Użycie:

"Dlaczego każda sesja zaczyna się od zużycia 4 tys. tokenów?"

"Sprawdź AGENTS.md — ktoś wkleił tam cały przewodnik stylu, zamiast umieścić go za umiejętnością."

Załadowanie tylko tego kontekstu, którego agent potrzebuje teraz, wraz ze wskaźnikami kontekstu prowadzącymi do pozostałych informacji. Pojęcie zapożyczone z projektowania interfejsów użytkownika, gdzie oznacza pokazywanie tylko kontrolek potrzebnych do bieżącego zadania i ukrywanie reszty za kliknięciem.

Ta technika jest potrzebna, bo kontekst kosztuje podwójnie. Każdy załadowany z góry token jest rozliczany jako token wejściowy w każdej turze, a każdy token zużywa budżet uwagi, niezależnie od tego, czy agent go potrzebuje. AGENTS.md wypełniony całym przewodnikiem stylu, procedurą wdrażania i konwencjami bazy danych pogarsza działanie agenta we wszystkich tych obszarach — ważne w danym zadaniu instrukcje rozmywają się wśród nieistotnych. Widać to po agencie, który ignoruje zasady, o których wiesz, że są w jego kontekście: są tam, ale zostały pogrzebane.

Stopniowe ujawnianie odwraca tę sytuację. Warstwę zawsze ładowaną utrzymuj niewielką — po jednym zdaniu na temat i wskaźniku do miejsca, gdzie znajdują się szczegóły. Agent czyta przewodnik stylu podczas pisania komponentu, procedurę wdrażania podczas wdrożenia, a żadnego z nich, gdy naprawia test. Umiejętności to wzorzec wbudowany w środowisko: krótki opis ładowany w każdej sesji, a pełne instrukcje dopiero po spełnieniu warunku.

Użycie:

„Czy powinienem wkleić cały przewodnik stylu do AGENTS.md?”

„Nie — zastosuj stopniowe ujawnianie. Wskaż przewodnik jako umiejętność ładowaną przez agenta dopiero wtedy, gdy naprawdę musi napisać komponent. AGENTS.md kosztuje tokeny w każdej turze.”

Wzmianka w jednym dokumencie odsyłająca do innego, dzięki czemu agent może włączyć jego treść do okna kontekstu dopiero wtedy, gdy wymaga tego zadanie. To podstawowa jednostka, z której buduje się stopniowe ujawnianie.

Powodem używania wskaźnika zamiast wklejania treści jest koszt. Wskaźnik zajmuje jedną linię w oknie kontekstu. Powiązany dokument może zawierać tysiące tokenów, ale nie kosztują one nic, dopóki agent nie skorzysta ze wskaźnika. Wklej obszerną instrukcję wdrożenia o długości 2000 tokenów do AGENTS.md, a zapłaci za nią każda sesja; zastąp ją tekstem „proces wdrażania: zobacz `internal/deploy.md`”, a dokument załadują tylko sesje zajmujące się wdrożeniem. Gdy zadanie pasuje do opisu, agent korzysta ze wskaźnika przez wywołanie narzędzia.

Aby wskaźnik działał, potrzebuje dwóch elementów: stabilnej ścieżki oraz opisu wystarczającego, by agent wiedział, kiedy warto za nim podążyć. Sama ścieżka nie daje agentowi powodu, by ją otworzyć; wzmianka „zobacz `internal/deploy.md`” bez wskazówki, co zawiera, zostanie pominięta przez sesję, której jest potrzebna. Sformułuj ją tak, by pasowała do zadań: „wydanie, wdrożenie lub wycofanie zmian — najpierw przeczytaj `internal/deploy.md`”.

Wskaźniki są wszędzie, gdy zaczniesz ich szukać: wiersze w AGENTS.md, opisy umiejętności (harness ładuje opis, a treść umiejętności pozostaje za nim), nazwy plików w wykazie katalogu, odnośniki między dokumentami.

Wskaźnik może też łączyć źródło wtórne z źródłem pierwotnym, na którym je oparto — podsumowanie po kompaktowaniu może wskazywać oryginalny transkrypt, a dokument może podawać plik źródłowy, który opisuje. Dzięki temu można odzyskać informacje utracone w źródle wtórnym: gdy okazuje się, że podsumowanie nie wystarcza, agent podąża za wskaźnikiem i czyta oryginał, zamiast ograniczać się do treści zachowanej w skrócie.

Unikaj: słowa „odnośnik” — jest zbyt suche i nie sugeruje, że przejście za nim dodaje kontekst. „Portal” jest z kolei zbyt kwiecisty.

Użycie:

"AGENTS.md zrobił się ogromny."

"Większość treści powinna być wskaźnikami kontekstu, a nie samą treścią. Zostaw w pliku zasady obowiązujące zawsze, a instrukcję wdrażania i przewodnik stylu zamień na umiejętności, pozostawiając wskaźnik kontekstu."

Umiejętność, którą można przekazać, zapakowana jako jedna całość — instrukcje i zasoby do dobrego wykonania konkretnego zadania. Pozostaje w środowisku, dopóki wskaźnik kontekstu nie wczyta jej do okna kontekstu na potrzeby bieżącego zadania. To jednostka stopniowego ujawniania w środowisku.

Umiejętności są otwartym standardem opisanym na agentskills.io — pierwotnie opracowanym przez Anthropic, a następnie przyjętym przez większość głównych środowisk, więc umiejętność napisana raz działa w wielu z nich. Format to folder zawierający:

• Plik `SKILL.md` — metadane (co najmniej nazwa i opis) oraz same instrukcje
• Opcjonalne skrypty, które może uruchamiać agent
• Opcjonalne szablony i materiały referencyjne wskazane w instrukcjach

Domyślnie w kontekście znajdują się tylko nazwa i opis. Gdy zadanie agenta pasuje do umiejętności, wczytuje resztę. Wcześniej umiejętność zajmuje prawie zero miejsca — zdanie lub dwa tokenów, niezależnie od długości pełnych instrukcji.

To odróżnia umiejętności od AGENTS.md, które jest ładowane do każdej sesji, niezależnie od zadania. Umiejętność jest czytana, gdy pojawia się konkretny rodzaj pracy — wydanie, utworzenie szkieletu usługi, napisanie migracji — a przez resztę czasu pozostaje pominięta.

Unikaj: „narzędzie” — narzędzie to coś, co agent wywołuje; umiejętność to instrukcje, które czyta.

Użycie:

„Gdzie umieścić procedurę wdrażania?”

„Jako umiejętność — agent wczyta ją tylko wtedy, gdy zadanie będzie dotyczyć wdrożenia. W AGENTS.md zużywałaby tokeny w każdej turze, chociaż używamy jej raz w tygodniu.”

Agent uruchomiony przez innego agenta za pomocą wywołania narzędzia. Działa we własnej sesji i własnym oknie kontekstu, po czym zwraca jeden wynik narzędzia. Różni się od przekazania — agent nadrzędny wyraźnie oczekuje odpowiedzi; przekazanie nie ma ścieżki powrotnej. Nie może uruchamiać kolejnych podagentów — drzewo ma tylko jeden poziom. Podagenci służą izolowaniu kontekstu, a nie budowaniu hierarchii.

Chodzi o to, by głośna praca nie zaśmiecała kontekstu agenta nadrzędnego. Szerokie wyszukiwanie lub długie wyprawy po plikach generują strony wyników narzędzi, z których większość jest przydatna tylko do znalezienia odpowiedzi. Gdy praca odbywa się w agencie nadrzędnym, wszystkie te wyniki pozostają w jego kontekście przez resztę sesji. Uruchomienie jej w podagencie umieszcza szum w osobnym, przeznaczonym do porzucenia oknie — do kontekstu nadrzędnego trafia tylko raport końcowy. Raport jest źródłem wtórnym: agent nadrzędny otrzymuje relację podagenta, a nie surowe wyniki, więc wszystko, co pominie raport, pozostaje niewidoczne.

Podagenci działają też współbieżnie — agent nadrzędny może równolegle uruchomić kilku do niezależnych zadań.

Użycie:

„Wyniki grep zaśmiecają mi kontekst”.

„Uruchom podagenta do wyszukiwania — zużyje własne okno kontekstu na szum i zwróci dwie ścieżki plików, których naprawdę potrzebujesz.”

Model pracy, w którym jedna lub więcej osób współpracuje z agentem podczas sesji — na bieżąco przegląda jego pracę, koryguje kierunek lub wspólnie działa. Człowiek jest obecny i zaangażowany, a nie tylko zatwierdza pojedyncze działania.

Przeciwieństwem jest praca AFK, podczas której agent działa bez nadzoru, a rezultat ocenia się później. Praca z człowiekiem w pętli polega na wychwytywaniu problemów, póki ich naprawa jest tania: widzisz, że agent sięga po niewłaściwy plik, błędnie odczytuje wymaganie albo zmierza w ślepą uliczkę, i jednym zdaniem go korygujesz — zamiast po dwudziestu minutach odkrywać pewnie wykonaną pracę opartą na błędnym założeniu. Agenci nie potrafią niezawodnie rozpoznać, że zeszli z kursu; pozostawieni sami sobie, zwykle idą dalej, zamiast się zatrzymać i zapytać.

To, który model pracy pasuje, zależy od zadania. Zadania dobrze opisane, mało ryzykowne i łatwe do zweryfikowania nadają się do pracy AFK. Przy zadaniach niejednoznacznych, nieodwracalnych albo takich, których końcowy rezultat trudno byłoby ci ocenić — migracji schematu, trudnej decyzji projektowej, wszystkim, co dotyka produkcji — lepiej pozostać w pętli. W gruncie rzeczy trzeba ocenić: ile kosztowałby błędny skręt i jak późno byś go zauważył?

Niektóre zadania z natury wymagają obecności człowieka, bo jego reakcje są częścią danych wejściowych. Grilling działa tylko wtedy, gdy jesteś na miejscu, by odpowiadać na pytania; prototypowanie wymaga twojej obecności, żebyś mógł reagować na artefakt.

Pozostawanie w pętli zużywa twoją uwagę, a to ograniczony zasób. Jednym ze sposobów lepszej pracy z agentami jest bezpieczne przenoszenie kolejnych zadań poza pętlę — dzięki planom, automatycznym kontrolom i ludzkiemu przeglądowi na końcu, zamiast nadzoru przez cały czas. Fabryka oprogramowania idzie krok dalej i rozpoczyna sesje na podstawie wyzwalaczy, dzięki czemu nawet uruchomienie pracy nie wymaga twojego udziału.

Użycie:

"Uruchomić to na noc w trybie AFK?"

"Nie, to migracja schematu — zostaw człowieka w pętli. Chcę widzieć każdy krok i pokierować pracą, jeśli wybierze niewłaściwą kolumnę do uzupełnienia."

Poza klawiaturą. Model pracy, w którym użytkownik uruchamia sesję i pozostawia agenta bez nadzoru. To mnożnik przepustowości przy programowaniu z AI — wiele sesji AFK może działać równolegle, gdy śpisz, jesz albo zajmujesz się czymś innym. Dla bezpieczeństwa zwykle wymaga liberalnego trybu uprawnień oraz izolacji w piaskownicy.

Pod nieobecność użytkownika agent inaczej radzi sobie z niejednoznacznością. Gdy obserwujesz pracę, niejasna decyzja staje się pytaniem, na które odpowiadasz; po twoim odejściu agent wybiera domyślną opcję i kontynuuje, a każda następna decyzja opiera się na tym domyśle. Typowa porażka polega na tym, że wracasz po kilku godzinach ukończonej, pewnie wykonanej pracy zbudowanej na złej decyzji podjętej w pierwszych dziesięciu minutach. Praca nie jest niedbała — jest spójna, tylko dotyczy niewłaściwej rzeczy.

Skoro nie możesz przekazywać wskazówek w trakcie przebiegu, przekaż je przed nim i po nim. Przed: rozstrzygnij niejednoznaczności z góry — w sesji grillowania, pisemnej specyfikacji — aby agent miał mniej luk do samodzielnego wypełniania. W trakcie: automatyczne kontrole i automatyczny przegląd zastępują twoją uwagę, szybko wykrywając to, co da się sprawdzić mechanicznie. Po: przebieg powinien zakończyć się czymś, co można przejrzeć — PR-em, a nie zmianami już scalonymi. AFK nie usuwa ludzkiego przeglądu; odkłada go w całości na koniec, dlatego rezultat musi być wart przejrzenia. Właśnie dlatego AX jest najważniejsze w przebiegach AFK — bez obserwującego człowieka środowisko jest jedynym wsparciem agenta.

Unikaj: określenia „agent w tle” — skupia uwagę na maszynie („działa w tle”), a nie na ludzkim wzorcu („użytkownik odszedł”). AFK nazywa istotny fakt: użytkownik nie obserwuje pracy.

Użycie:

"Uruchamiam to w trybie AFK — trzy odizolowane agenty pracują nad refaktoryzacją, rano przejrzę ich PR-y."

"Ominąć uprawnienia?"

"Tak, tylko do odczytu system plików, bez sieci."

Deterministyczna weryfikacja uruchamiana w środowisku — testy, sprawdzanie typów, lintery, budowanie, hooki pre-commit. Wynik to zaliczenie albo błąd, bez uznaniowości. Sygnał, na podstawie którego agent może sam poprawić problem, bez udziału innych osób. Niestabilny test to zepsuta kontrola, a nie brak kontroli; automatyczne kontrole są deterministyczne z założenia.

Samokorekta działa jak pętla. Agent wprowadza zmianę, uruchamia kontrolę jako wywołanie narzędzia, a komunikat o błędzie trafia do jego okna kontekstu — na przykład błąd typów ze wskazaniem pliku i wiersza albo nieudana asercja z oczekiwaną i rzeczywistą wartością. To wystarczy, by agent poprawił problem i ponownie uruchomił kontrolę, raz za razem, aż przejdzie, bez udziału człowieka. Determinizm sprawia, że pętla jest wiarygodna: ten sam kod zawsze daje ten sam werdykt, więc zaliczenie coś znaczy. Niestabilna kontrola ją zatruwa — agent „naprawia” kod, który był dobry, albo ponawia próbę mimo rzeczywistego błędu.

Dlatego dobre kontrole stanowią istotną część AX bazy kodu. Agent w repozytorium ze ścisłymi typami, szybkim zestawem testów i linterem wykrywa większość własnych błędów, zanim je zobaczysz; agent w repozytorium bez takich zabezpieczeń wysyła wszystko, co wytworzy. Różnica jest najważniejsza podczas przebiegów AFK, kiedy kontrole są jedyną weryfikacją odbywającą się w trakcie pracy. Kontrola wykrywa jednak tylko to, co sprawdza — zielony wynik oznacza, że zadeklarowane właściwości są spełnione, a nie że kod jest poprawny. Luki wymagające osądu są powodem, dla którego istnieją automatyczny przegląd i ludzki przegląd.

Unikaj: określeń „pętla informacji zwrotnej” i „backpressure” — oba zrównują kontrole z przeglądem. Unikaj: „test” — testy są automatycznymi kontrolami, ale nie każda automatyczna kontrola jest testem.

Użycie:

"Agent ciągle wypuszcza zepsuty kod w przebiegach AFK."

"Jakie automatyczne kontrole skonfigurowano w piaskownicy?"

"Tylko testy jednostkowe."

"Dodaj sprawdzanie typów i lint — agent sam poprawi błędy na ich podstawie, zanim PR w ogóle trafi do przeglądu."

Agent przeglądający pracę innego agenta, często używający innego modelu albo promptu systemowego. To proces niedeterministyczny: wymaga osądu. Może działać na dowolnym etapie — przed scaleniem PR-a, po fakcie na historii commitów albo w trakcie sesji jako podagent. LLM oceniający zmiany w CI to automatyczny przegląd, a nie automatyczna kontrola; o kategorii decyduje to, co sprawdza asercja, a nie miejsce jej uruchomienia.

Działa dzięki oddzieleniu od agenta wykonującego pracę. Proszenie agenta, który napisał kod, by sam go przejrzał, daje niewiele — sesja, w której powstał błąd, zawiera też rozumowanie, które do niego doprowadziło, a agent odczytuje własne wnioski jako potwierdzenie. Recenzent z nowym oknem kontekstu nie jest do nich przywiązany: widzi diff jak obca osoba, a na tym polega przegląd. Inny model lub prompt systemowy przygotowany specjalnie do przeglądu dodatkowo to wzmacnia — zapewnia inne martwe pola i prompt skupiony na tym, na czym naprawdę ci zależy (bezpieczeństwie, kontraktach API, wydajności), zamiast ogólnego „poszukaj problemów”.

Ta metoda znajduje się między pozostałymi warstwami przeglądu. Automatyczne kontrole są deterministyczne i wykrywają to, co można sprawdzić mechanicznie; ludzki przegląd jest kosztowny i najtrudniej go skalować. Automatyczny przegląd zajmuje środek: niewielkim kosztem wykrywa problemy wymagające osądu — mylącą nazwę funkcji czy pominięty przypadek brzegowy. Ponieważ jest niedeterministyczny, może coś przeoczyć albo zgłosić nieistotny problem; traktuj go jak filtr podnoszący minimalny poziom jakości przed ludzkim przeglądem, a nie bramkę, która go zastępuje.

Unikaj: określeń „przegląd AI” lub „przegląd agenta” — są zbyt nieprecyzyjne, by odróżnić ten proces od samego agenta wykonującego pracę.

Użycie:

"Z przebiegów AFK trafia do nas za dużo kiepskich PR-ów."

"Dodaj automatyczny przegląd przed scaleniem — inny model, osobny prompt systemowy, zakres ograniczony do bezpieczeństwa i zmian kontraktów."

Użytkownik czyta kod utworzony przez agenta i ocenia go. Liczy się lektura różnicy lub zmienionych plików; samo przeczytanie opisu pracy agenta się nie liczy — narracja nie jest artefaktem. Opis jest źródłem wtórnym, napisanym przez stronę podlegającą ocenie; różnica jest źródłem pierwotnym, a przegląd polega na jej przeczytaniu.

Agenci zwiększają ilość tworzonego kodu, więc przegląd staje się wąskim gardłem. Przydatnym rozwiązaniem jest warstwowanie różnych strategii kontroli. Testy automatyczne wykrywają błędy mechaniczne, automatyczny przegląd wychwytuje te, które można opisać, a przegląd człowieka pozostaje dla rzeczy, które tylko człowiek może ocenić — czy zmiana jest właściwa, czy podejście pasuje do bazy kodu i czy ta funkcja w ogóle powinna istnieć.

Wcześniejszy przegląd jest też tańszy. Przeczytanie planu przed rozpoczęciem pracy albo małej różnicy w jej trakcie zajmuje minuty; analizowanie gotowej gałęzi po przebiegu AFK trwa dłużej. Wybór momentu kontroli to decyzja o udziale człowieka w pętli, a nie kwestia na później.

Unikaj: samego określenia „przegląd kodu” — może oznaczać przegląd człowieka lub automatyczny.

Użycie:

„Przejrzałem wynik AFK jako człowiek”.

„Czytałeś różnicę, czy tylko podsumowanie?”

„Różnicę. Podsumowanie twierdziło, że usunięto martwy kod — okazało się, że funkcja jest wywoływana z wygenerowanego pliku.”

Wzorzec pracy, w którym użytkownik przyjmuje kod agenta bez ludzkiego przeglądu. Diff traktuje się jak czarną skrzynkę — liczy się to, czy program działa, a nie to, co zawiera. Nadal mogą działać automatyczny przegląd i automatyczne kontrole; vibe coding nie przesądza o żadnym z nich.

Termin pochodzi od Andreja Karpathy’ego, który ukłuł go na początku 2025 roku: „w pełni poddajesz się nastrojowi” i „zapominasz, że kod w ogóle istnieje” — opisujesz, czego chcesz, przyjmujesz rezultat i oceniasz go, uruchamiając program.

Vibe coding zamienia inspekcję na szybkość. Czytanie diffów jest zwykle najwolniejszym etapem pracy z agentem, więc pominięcie go usuwa główne wąskie gardło. W przypadku kodu, którego błędy niewiele kosztują — prototypów, jednorazowych skryptów, narzędzi wewnętrznych — to rozsądny kompromis. Ryzyko rośnie wraz z czasem życia kodu i stawką.

Koszt pojawia się później. Zmiany tworzone metodą vibe codingu kumulują się w bazie kodu, której nikt nie czytał, a sprawdzano wyłącznie działanie programu — dlatego wszystko, czego działanie nie ujawnia, może trafić do produkcji niezauważone: sekret zapisany w logach, brakujący przypadek brzegowy czy błędne, lecz ciche przetwarzanie danych. Pierwszy raz, gdy ktoś diagnozuje system, jest zarazem pierwszym razem, gdy ktoś czyta jego kod. Po usunięciu ludzkiego przeglądu jedyną bramką pozostaje ta automatyczna weryfikacja, która jeszcze działa — testy, typy, automatyczny przegląd. Tę samą postawę zastosowaną do całej bazy kodu lub jej części, gdy zmiany pochodzą z fabryki oprogramowania, nazywa się ciemną fabryką.

Unikaj: używania „vibe coding” jako synonimu „niskiej jakości kodowania z AI” — termin opisuje podejście do przeglądu, a nie jakość powstałego kodu.

Użycie:

"Czy przeczytałeś zmiany w przepływie autoryzacji?"

"Zrobiłem vibe coding — logowanie nadal działa, tylko to sprawdziłem."

"Przeczytaj diff, zanim wypchniesz zmiany; vibe coding przy autoryzacji to sposób, w jaki sekrety trafiają do logów."

Wspólne zrozumienie tego, co jest tworzone, podzielane przez użytkownika i agenta, ale odrębne od każdego artefaktu. Pojęcie Brooksa (The Design of Design): rozmowa, artefakty przekazania i kod próbują uchwycić lub wyrazić koncepcję projektu, ale żaden z nich nią nie jest. Jakość koncepcji projektu odczuwa się poprzez jakość rozmowy, w której ją wypracowano.

Termin nazywa lukę stojącą za znaną frustracją: agent pisze dokładnie to, o co prosisz, a wynik nadal jest błędny. Zwykle dlatego, że sam nie w pełni ustaliłeś, czego chcesz. Koncepcja projektu nie była ukończona w Twojej głowie — prompt obejmował wypracowane kwestie, a milczał o tych, których jeszcze nie rozstrzygnąłeś. Agent wypełnił te luki własnymi założeniami, bo nie było do czego dopasować wyniku. Nic się nie zepsuło. Nie istniała wspólna koncepcja projektu, ponieważ nie była jeszcze kompletna.

Możesz rozpoznać wspólną koncepcję projektu tak jak w rozmowie ze współpracownikiem: druga strona zaczyna odpowiadać na niezadane jeszcze pytania tak, jak zrobiłbyś to Ty. Do tego czasu praca polega na rozmowie — przepytywanie jest jej celową odmianą — a zbyt wczesne pisanie specyfikacji jedynie utrwala niedopasowanie w trwalszym artefakcie. Koncepcja projektu zmienia się wraz z wiedzą; artefakty pozostają w tyle, dlatego specyfikacja wiernie oddająca zeszłotygodniowe rozumienie może nadal wprowadzać w błąd podczas tej sesji.

Użycie:

„Pisze dokładnie to, o co proszę, a mimo to wynik jest błędny”.

„Nie macie jeszcze wspólnej koncepcji projektu — agent wypełnia luki założeniami. Rozmawiajcie dalej, aż uzgodnicie anulowanie, zwroty i częściowe realizacje, zanim pozwolisz mu napisać specyfikację.”

Technika rozwijania koncepcji projektu z agentem: agent prowadzi z użytkownikiem rozmowę sokratejską, zadając po jednym pytaniu i proponując zalecaną odpowiedź. Spowalnia pośpiech do gotowego planu — artefakt przekazania nie powstaje, dopóki koncepcja się nie ustabilizuje.

Ta technika jest potrzebna, bo agenci po cichu uzupełniają luki. Poproszony o napisanie specyfikacji na podstawie dwuwierszowego promptu agent nie zatrzymuje się przy niepodjętych przez Ciebie decyzjach — wybiera domyślne rozwiązania i wpisuje je do dokumentu. Wynik wygląda na kompletny, a domysły nie różnią się od podjętych decyzji, więc odkrywasz je późno: podczas przeglądu albo gdy zbudowana funkcja obsługuje przypadek brzegowy w sposób, którego nigdy nie wybrałeś. Ta technika odwraca sytuację: zamiast zgadywać, agent musi pytać.

To technika człowieka w pętli: odpowiedzi użytkownika są danymi wejściowymi. Gdy na pytanie nie da się odpowiedzieć w rozmowie — trzeba zobaczyć rozwiązanie — przejdź do prototypowania.

Użycie:

„Od razu zaczął pisać specyfikację i źle obsłużył anulowanie”.

„Najpierw go przepytaj — niech zapyta o częściowe anulowanie, zwroty i terminy, zanim cokolwiek zapisze w dokumencie. Łatwiej i taniej rozwiązać to w rozmowie niż w kodzie.”

Poproszenie agenta, by szybko zbudował zgrubną wersję rozwiązania, gdy rozmowa ma zbyt niską wierność i potrzebujesz rzeczywistego artefaktu, o którym można rozmawiać.

Przepytywanie pomaga rozstrzygać decyzje projektowe w rozmowie. Rozmowa jest tania, lecz ma niską wierność: na niektóre pytania nie da się odpowiedzieć słowami — jak odczuwa się interakcję, czy kształt API jest wygodny w rzeczywistym kodzie korzystającym z niego, czy układ sprawdza się przy prawdziwej ilości danych. Wywiad dochodzi do pytania, na które szczera odpowiedź brzmi: „Nie wiem, musiałbym to zobaczyć”. Od tego momentu dyskusja kręci się w kółko. Zamiast tego poproś agenta, by zbudował rozwiązanie, obejrzyj je i wróć do rozmowy z odpowiedzią.

Agenci obniżają koszt tworzenia, co czyni to podejście praktycznym. Zgrubna wersja, której przygotowanie makiety zajmowało kiedyś dzień, teraz powstaje w kilka minut, więc warto regularnie tak pracować. To technika człowieka w pętli: prototyp powstaje po to, byś mógł zareagować.

Zwykle nie kończy się na jednym obejrzeniu. Pracuj iteracyjnie z prototypem — reaguj, proś o zmianę, reaguj ponownie — aby każda runda rozstrzygała kolejną decyzję na podstawie prawdziwego artefaktu, z większą wiernością niż umożliwia rozmowa.

Prototyp nie musi być całkowicie prowizoryczny. Możesz zbudować oceniane elementy z jakością produkcyjną, by po podjęciu decyzji komponent lub API, na które zareagowałeś, można było przenieść do właściwej bazy kodu. Dlatego prototypowanie dostarcza materiału, do którego powinna odwoływać się specyfikacja.

Użycie:

„Od pół godziny spieramy się, czy kreator powinien mieć jedną stronę, czy trzy kroki”.

„Nie rozstrzygniemy tego słowami — poproś agenta o prototyp obu wariantów. Przeklikamy je i będziemy wiedzieć za pięć minut.”

Doświadczenie programisty — to, jak łatwo kod i jego narzędzia pozwalają ludziom dobrze pracować. Dobre DX oznacza szybki feedback, czytelne komunikaty o błędach, dokumentację odpowiadającą na rzeczywiste pytania oraz konfigurację, która działa za pierwszym razem. Termin ten powstał na długo przed kodowaniem z AI; w tym słowniku pojawia się głównie jako przeciwieństwo AX.

DX opisuje interakcję człowieka z bazą kodu — i nic ponadto. Główna różnica między tymi odbiorcami polega na tym, że ludzie są stanowi, a agenci bezstanowi. Człowiek raz poznaje bazę kodu i zachowuje tę wiedzę na każdy kolejny dzień, dlatego da się żyć ze słabym DX: omija wolne CI, łącząc zmiany przed ich wysłaniem, braki w dokumentacji nadrabia, raz pytając na Slacku, a mylącą strukturę obchodzi, pamiętając, gdzie co się znajduje. Obejścia się kumulują i zespół staje się produktywny w bazie kodu, która mu przeszkadza.

Agenci trafiają na tę samą bazę kodu, ale nie mogą skorzystać z tak zgromadzonej wiedzy. Ponieważ są bezstanowi między sesjami, za każdym razem poznają kod od początku. Korzystają z szybkiego zestawu testów i czytelnych komunikatów o błędach, ale wszystko, co ustalili wczoraj, przepada, chyba że zapisano to w środowisku, które agent poznaje wyłącznie przez wyniki narzędzi. Tę różnicę opisuje AX: obejmuje te elementy DX, które pomagają, gdy programistą jest agent, oraz potrzeby, których ludzie nie mają, na przykład zachowanie wolnego miejsca w oknie kontekstu.

Obszary wspólne sprawiają, że inwestycje w DX często poprawiają AX bez dodatkowego wysiłku — ścisłe typy, szybkie testy i przewidywalna struktura pomagają obu grupom. Różnice oznaczają, że nie zawsze tak jest: świetny dokument wdrożeniowy pomaga człowiekowi przez tydzień, a agentowi wcale, jeśli nie prowadzi do niego AGENTS.md.

Użycie:

"Nasze DX jest w porządku — nowi pracownicy osiągają produktywność w tydzień."

"Są produktywni, bo ktoś przez ten tydzień pracuje razem z nimi. Agent nie dostaje tego tygodnia; osobno sprawdź AX."

Doświadczenie agenta — to, na ile środowisko przygotowano tak, by agent mógł dobrze pracować w bazie kodu. Odpowiednik DX z perspektywy agenta. Jeśli ten sam agent dobrze radzi sobie w jednym repozytorium, a źle w innym — przy tym samym modelu i harnessie — różnica zwykle wynika z AX. Odruchowo obwinia się model albo przepisuje prompt, ale rozwiązanie częściej leży w samym repozytorium.

Dobre AX ma trzy główne wymiary:

AX i DX mają wspólne obszary — dobre kontrole i przejrzysta architektura pomagają obu grupom — ale też się różnią. Ludzie radzą sobie z wiedzą plemienną, wolnym CI i tekstem „zapytaj Sarę o moduł rozliczeń”; agenci nie. Agentom nie pomagają podpowiedzi IDE ani ładne pulpity; potrzebują komunikatów o błędach w postaci tekstu w wyniku narzędzia. Baza kodu może zapewniać dobre DX i słabe AX.

Unikaj: traktowania AX jako synonimu DX — tym grupom potrzebne są różne inwestycje.

Użycie:

"Agent pisze świetny kod w repozytorium API, a fatalny we frontendowym."

"Repozytorium API ma ścisłe typy i szybki zestaw testów; frontend nie ma ani jednego, ani drugiego, za to zawsze ładuje czterdzieści umiejętności. To luka w AX, a nie problem z modelem."

System pracy, w którym sesje agentów uruchamiają wyzwalacze — utworzenie zgłoszenia, harmonogram, błąd CI, zakończenie innej sesji — a nie człowiek. Dzięki temu więcej zadań odbywa się w trybie AFK, a uwaga ludzi skupia się na decyzjach, które nadal wymagają człowieka w pętli.

Bez fabryki każda sesja zaczyna się, bo ktoś ją uruchomił. Nawet w pełni automatyczna praca AFK czeka, aż ktoś otworzy sesję, wskaże jej zgłoszenie i ją rozpocznie. Zespoły chcą dostarczać więcej, niż pozwala na to taki model. Fabryka usuwa udział człowieka przy uruchamianiu sesji, ale niekoniecznie w pozostałych etapach.

Typowe wyzwalacze i uruchamiane przez nie sesje:

Fabryka nie musi obejmować całego procesu tworzenia oprogramowania. Jedno zadanie cron, które uruchamia jeden rodzaj sesji i otwiera jeden PR nadający się do przeglądu, już jest fabryką. Warto zacząć od takiego zakresu: wąska pętla tworzy małe, podobne PR-y, a ich przegląd pokazuje, na ile można zaufać automatyzacji, zanim zostanie rozszerzona.

Ludzie mogą uczestniczyć w dowolnym miejscu fabryki — pisać i oznaczać zgłoszenia uruchamiające sesje, zatwierdzać plan przed rozpoczęciem implementacji albo przeprowadzać ludzki przegląd przed scaleniem. Najważniejszą decyzją projektową jest ustalenie, które z tych decyzji pozostają po stronie człowieka. Baza kodu lub jej część, której wyników fabryki nie przegląda żaden człowiek, to ciemna fabryka.

Użycie:

"Kto naprawił wszystkie naruszenia `no-floating-promises`?"

"Fabryka. Zadanie cron każdej nocy wybiera jedną regułę lintowania i otwiera PR. Rano tylko go przeglądam."

Baza kodu lub jej część, w której fabryka oprogramowania pisze kod, a żaden człowiek go nie czyta. Nie ma tu przeglądu człowieka. Ludzie nadal mogą tworzyć zgłoszenia rozpoczynające pracę. Nikt jednak nie czyta powstającego kodu. Nazwa pochodzi od fabryk „lights-out”, które wytwarzają produkty bez ludzi na hali.

Ciemna fabryka to programowanie intuicyjne stosowane do obszaru kodu, a nie pojedynczej zmiany. Gdy programujesz intuicyjnie, wybierasz nieczytanie zamówionej przez siebie zmiany. Wiesz jednak, że ona istnieje. W ciemnej fabryce zespół podejmuje tę decyzję raz dla całego obszaru. Potem nikt nie zleca ani nie ogląda każdej zmiany. Zmiany napływają w tempie, w jakim wyzwalacze rozpoczynają nową pracę.

Problem wychodzi na jaw, gdy coś się psuje. Nie wiesz, co się zmieniło, bo nikt nie czytał zmian. Musisz debugować kod, którego nikt w zespole nie przeczytał. Przyczyna może tkwić w dowolnej z wielu zmian, a każda przeszła kontrole.

Jedynymi bramkami są testy automatyczne i automatyczny przegląd. Jeśli nie wykryją problemu, problem trafia do kodu.

Unikaj: nazywania bazy kodu „ciemną” tylko dlatego, że fabryka działa bez nadzoru. Jeśli sesje agentów działają AFK, a człowiek przegląda ich pull requesty, to jest fabryka oprogramowania, nie ciemna fabryka.

Użycie:

„Kto zmienił logikę ponawiania prób w usłudze rozliczeń? Nikt w zespole tego nie pamięta”.

„Usługa rozliczeń to ciemna fabryka. Agenci scalają wszystkie zmiany przechodzące CI. Nikt tej zmiany nie przeczytał.”