Jak wygląda dobry wynik w zakresie tarcia

Dlaczego zapisy, a nie wspomnienia?

Tarcie występujące podczas jednej sesji to po prostu szum. To samo tarcie występujące w ciągu ośmiu sesji stanowi wzorzec, który Państwa zespół może skorygować — ale tylko wtedy, gdy te osiem sesji pozostawiło po sobie zapisy, które faktycznie można wspólnie przeanalizować: spójne (o tej samej strukturze, dzięki czemu są porównywalne) i rzetelne (oparte na obserwacjach popartych dowodami, a nie na subiektywnych odczuciach).

Żadna z tych sytuacji nie ma miejsca domyślnie. Moment, w którym pojawia się utrudnienie, jest momentem, w którym dostępna jest maksymalna ilość informacji na jego temat — dokładna nieaktualna linijka w instrukcji postępowania, dokładny parametr, który pozostawiono otwarty w wytycznych. Informacje te szybko tracą na aktualności. Agent normalizuje swoje własne obejście w ciągu kilku tur, a pod koniec sesji sygnał znika, o ile nikt go nie zapisał; cokolwiek ustali podagent, „znika w chwili, gdy zwraca wynik” (Hindsight, maj 2026). Niniejszy rozdział dotyczy właśnie tego zapisywania.

W jaki sposób zauważa się tarcie

Zanim cokolwiek zostanie zarejestrowane, musi zostać zauważone. Cztery kanały, a każdy z nich rejestruje coś innego:

Agent zauważa, że napotyka trudności. Pętle ponownych prób, cofanie się, ponowne odczytywanie tego samego pliku lub ponowne wysyłanie zapytania do tego samego widoku analitycznego, przypuszczenie wymuszone luką w briefie. Platformy produkcyjne zbieżają się zasadniczo w tej liście sygnałów behawioralnych (Factory Signals, styczeń 2026 r.). Najtańszy kanał, charakteryzujący się dwoma istotnymi ograniczeniami: nie dostrzega on rzeczy nieobecnych (pętla ponownych prób jest odczuwalna; dokument, który nigdy nie istniał, nie generuje żadnego sygnału), a samoobserwacja wyprzedza autodiagnozę — modele słabo lokalizują własne błędy agencjalne nawet w przypadku wyselekcjonowanych śladów (~11%, TRAIL). Zatem zadaniem w trakcie sesji jest obserwowanie symptomów i przytaczanie dowodów, nie przywiązując zbytniej wagi do diagnozy.

Drugi pracownik weryfikuje transkrypcję. Osoba dokonująca weryfikacji z innej perspektywy dostrzega to, co pracownik odpowiedzialny za przetwarzanie uznał za normalne. Jest to podejście bardziej obiektywne; wymaga jednak dodatkowego etapu weryfikacji i wiąże się z własnymi błędami w ocenie.

Człowiek koryguje działanie agenta. Nadal dominującym czujnikiem jest człowiek: w trwającym 8 tygodni badaniu produkcyjnym stwierdzono, że około 70% cichych awarii agentów zostało po raz pierwszy wykrytych przez osobę, która zauważyła, że coś jest nie tak — a nie przez testy jednostkowe, kontrole stanu lub audyty zgodności (arXiv 2606.14589). Każda korekta (np. uwaga recenzenta „nie, miałem na myśli…”, ponowne wyjaśnienie briefu przez interesariusza w trakcie audytu) wskazuje dokładnie, w którym miejscu kontekst odbiegał od zamierzeń, a agent może to uchwycić w danej chwili bez żadnych dodatkowych kosztów procesowych.

Telemetria. Wskaźniki błędów narzędzi, odmowy uprawnień, liczba pętli, długie czasy trwania. Automatyczna i obiektywna, ale powierzchowna: system wie że coś się wydarzyło, ale nie dlaczego.

Najskuteczniejsze konfiguracje opierają się na trójstronnej weryfikacji: dane telemetryczne wskazują, gdzie należy szukać, analiza wyników wyjaśnia dlaczego, a korekta wprowadzona przez człowieka pozwala zidentyfikować te problemy, których nie są w stanie wykryć automatyczne sygnały. Niezależnie od tego, jaką kombinację zastosują Państwo, efekt powinien być zawsze ten sam: zapis wyników.

Co skłania agenta do zarejestrowania tego zdarzenia

Agent nie zarejestruje tarcia, którego nikt mu nie polecił szukać. Większość tarcia pozostaje niezarejestrowana nie dlatego, że nie została zauważona, ale dlatego, że nic nie spowodowało jej zarejestrowania. Istnieją cztery mechanizmy, różniące się głównie tym, co gwarantuje wywołanie zdarzenia:

• Umiejętność: opatrzona numerem wersji, spisana procedura, którą agent wykonuje na zakończenie sesji. Zawiera schemat oraz zasady uczciwości, dzięki czemu jej uruchomienie jest spójne: ta sama procedura działa zarówno w przypadku refaktoryzacji, jak i przeglądu konta reklamowego. Wada: wywołanie ma charakter probabilistyczny; może się zdarzyć, że procedura nigdy nie zostanie uruchomiona bez żadnego powiadomienia.
• Hook: sam system zarządzania sesjami uruchamia lub przypomina o zdarzeniu (wstrzyknięcie na początku sesji, wyzwalacz na końcu sesji). Rozwiązanie to jest deterministyczne (jedyna opcja, która nie wymaga, by ktokolwiek cokolwiek zapamiętywał), ale mało precyzyjne (uruchamia się również w przypadku sesji trwającej dwie minuty) i uzależnione od platformy.
• Zasada postępowania: jedna stała instrukcja zawarta w pliku kontekstowym danego zakresu lub w jego odpowiedniku niebędącym kodem, a także krok w standardowej procedurze operacyjnej zespołu: „każdą istotną sesję z udziałem sztucznej inteligencji należy kończyć poprzez odnotowanie napotkanych trudności”. Nie wymaga żadnej infrastruktury, ale opiera się całkowicie na tym, że model przestrzega jednej z wielu zasad, a jej skuteczność maleje wraz z powiększaniem się pliku; wymienionym trybem awarii jest plik pamięci, który „przestał być odczytywany” (uwaga dotycząca antywzorców).
• Polecenie: polecenie wpisane przez człowieka/retrona zakończenie gałęzi funkcji lub zmiany poświęconej klasyfikacji zgłoszeń. Jest to działanie przemyślane i precyzyjnie zaplanowane czasowo; słabym ogniwem jest ludzka pamięć.

Proszę je skomponować i ułożyć warstwowo. Deterministyczny wyzwalacz (haczyk lub krok SOP oznaczający koniec zmiany), proceduralna treść (umiejętność) oraz konwencjonalna linia określająca daną praktykę jako normę — proszę wybrać co najmniej jeden wyzwalacz, a najlepiej dwa. Nawet dostawcy doszli do tego wniosku: w wytycznych OpenAI dotyczących Codexu czytamy: „gdy Codex popełni ten sam błąd dwukrotnie, należy poprosić go o retrospektywę i zaktualizować plik AGENTS.md” (najlepsze praktyki).

Cechy charakterystyczne dobrego wstępu

Zapis stanowi umowę między sesją, w której wykryto zakłócenie, a wszystkimi elementami znajdującymi się dalej w łańcuchu — jakość syntezy jest ograniczona jakością zapisu. Cztery elementy nośne:

1. Opis konkretnego zdarzenia wraz z jego kosztem. Co się wydarzyło, kiedy to miało miejsce oraz jakie były zauważalne konsekwencje – opis musi być na tyle szczegółowy, aby osoba, która nie uczestniczyła w sesji, mogła podjąć odpowiednie działania na tej podstawie. Koszt oznacza konieczność ponownego wykonania pracy, stracony czas lub błędny wynik; wpis bez podania kosztu nie może zostać później sklasyfikowany. Koszt oszacowany przez agenta ma charakter orientacyjny: należy go(est.) zaznaczyć, zamiast udawać precyzję.

2. Dokładnie jedna etykieta przyczyny źródłowej wybrana ze stałego zestawu dziesięciu etykiet. Stałe słowniki umożliwiają niezawodne przypisywanie etykiet (algorytm MAST osiągnął współczynnik κ = 0,88 dla 14 trybów awarii; patrz arXiv 2503.13657); natomiast kategorie o swobodnej formie ulegają zmianom w zależności od osoby i nie podlegają agregacji. Dziesięć:

• ambiguous-instruction: w zadaniu pominięto kluczowy parametr (odbiorcy, zakres, definicja, przedział czasowy), co zmusiło do sformułowania przypuszczenia
• missing-context: fakt, o którym zespół wie, ale którego nie ujawnił
• incorrect-context: przekazane informacje były błędne
• missing-documentation: brakuje dokumentacji, która powinna istnieć (brak pliku README, specyfikacji, instrukcji operacyjnej ani standardowej procedury operacyjnej)
• incorrect-documentation: dokument istnieje, ale jest nieaktualny lub zawiera błędy, a mimo to posłużono się nim
• work-material-friction: materiał, nad którym prowadzono prace, spowalniał proces lub zwiększał ryzyko popełnienia błędów: dług techniczny lub niejasna struktura kodu; zagmatwane konto, tablica, arkusz kalkulacyjny lub szablon poza tym środowiskiem (proszę zawsze podać konkretny materiał)
• missing-access-or-tool: brakowało niezbędnego złącza, uprawnienia lub narzędzia
• agent-error: błąd samego agenta (błędne założenie, nieaktualna wiedza, wprowadzony przez niego błąd)
• changed-requirements: w trakcie sesji zmieniono wytyczne, w związku z czym konieczne było ponowne wykonanie pracy
• environment-friction: awarie narzędzi, przekroczenia limitów czasu, problemy związane z środowiskiem testowym lub platformą

Jedna etykieta na każdy wynik zapewnia rzetelność klasyfikacji: należy wybrać opcję najlepiej pasującą, odnotować ewentualne rozbieżności w dowodach i nigdy nie wymyślać etykiety w trakcie wprowadzania danych. Trzy zasady graniczne w znacznym stopniu eliminują niejasności. Test rozpoznawalności przez podmiot: czy fakt ten można było ustalić w dowolnym miejscu, w którym podmiot mógłby go racjonalnie poszukiwać? Nie znaleziono go nigdzie, gdzie powinien się znajdować → missing-documentation; dostarczono go dopiero później przez inną osobę → missing-context. Błąd podmiotu stanowi pozostałość: należy go stosować wyłącznie wtedy, gdy dane wejściowe były adekwatne, a podmiot mimo to popełnił błąd; jeśli błąd wynika z nieprawidłowych danych wejściowych, należy oznaczyć te dane. Oraz niejednoznaczność a zmiana celu: jeśli wyjaśnienie ujawniło to, co od początku było zamierzone, to było to ambiguous-instruction; jeśli cel rzeczywiście uległ zmianie, to jest to changed-requirements.

3. Rozwiązanie o rozmiarze zgłoszenia, określające jego poziom. Poziom to obszar, którego dotyczy rozwiązanie: pamięć, umiejętności, środowisko, dokumentacja, sam materiał, proces lub etapy poprzedzające. Zgłoszenie dotyczące utrudnień bez dołączonego rozwiązania stanowi skargę.

Oto pełny wpis dotyczący sesji niezwiązanej z kodowaniem – comiesięcznego przeglądu konta reklamowego:

- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

Chwila, koszt oznaczony symbolem(est.), jedna etykieta, rozwiązanie, które ktoś mógłby wdrożyć w przyszłym tygodniu. Proszę porównać to z bezużyteczną wersją tej samej uwagi: „zlecenie było niejasne” – brak chwili, brak kosztu, brak kolejnego kroku. Niejasność sama w sobie stanowi formę niepowodzenia.

4. Prawo do milczenia. „Nic godnego uwagi” to uzasadniona i przydatna odpowiedź; dziennik wypełniony zmyślonymi ustaleniami przesłania te prawdziwe.

Jeszcze jedna kwestia projektowa: nagrywanie powinno odbywać się bez ograniczeń — agent, który potrzebuje zgody na nagrywanie, zaniża liczbę zgłoszonych problemów. Należy pozwolić mu na swobodne rejestrowanie, a informacje zwrotne od człowieka powinny służyć jako korekta po fakcie: jako dodatkowy sygnał od osoby, która również uczestniczyła w sesji, a nie jako punkt kontrolny, na który czeka pętla.

Zasady dotyczące „never-log”

Zapisy przetrwają sesje, w których powstały: są zapisywane na stałe, udostępniane i agregowane. Niektóre dane nigdy nie trafiają do systemu:

• Sekrety, dane uwierzytelniające, tokeny lub klucze API, w jakiejkolwiek formie, nawet w postaci fragmentów.
• Dane klientów lub dane osobowe.
• Niepublikowane wyniki finansowe lub dane poufne — proszę opisać skutki, a nie same dane.
• Przede wszystkim ludzie. Nigdy nie należy podawać nazwiska, stanowiska ani żadnego innego elementu pozwalającego zidentyfikować osobę odpowiedzialną za powstanie luki. Opisz lukę i jej skutki: „brief pozostawił odbiorców bez odpowiedzi”, a nie „brief X”. Wpisy zawierają krytykę danych wejściowych i systemów, a nie osób — ta sama zasada obowiązuje podczas dobrej retrospektywy i sprawia, że dziennik można bezpiecznie czytać wspólnie.

Oczekuje się, że dane wejściowe będą poddawane krytycznej ocenie: niejasne wytyczne, brak kontekstu oraz spóźnione wymagania to zazwyczaj obszary, w których znajdują się informacje pozwalające na podjęcie konkretnych działań. Agent powinien podchodzić do siebie z taką samą szczerością. Jeśli nie da się opisać trudności związanych z danym zakresem bez uwzględnienia wrażliwego kontekstu, należy zachować wpisy dotyczące tego zakresu jako prywatne i udostępniać jedynie zbiorcze podsumowanie wytycznych.

Gdzie znajduje się dziennik

Jeden wpis dziennika na każdy zakres przeglądu — granicę, w ramach której wprowadzane są poprawki. W przypadku większości prac programistycznych jest to repozytorium: jego dokumentacja, konfiguracja i konwencje znajdują się w repozytorium, więc również dziennik problemów z nim związanych powinien tam być prowadzony. Poza kodem zakresem jest konto reklamowe, skrzynka odbiorcza działu wsparcia lub relacje z klientami; dziennik należy przechowywać w lokalizacji dokumentów danego obszaru roboczego. Zapis umieszczony poza tym zakresem jest zapisem, którego ostateczny właściciel poprawki nigdy nie odnajdzie; wpis zapisany w katalogu tymczasowym znika wraz z zakończeniem sesji.

To, co musi pozostać identyczne wszędzie, to nie sposób przechowywania, lecz struktura: to właśnie schemat, a nie sposób przechowywania, umożliwia późniejsze agregowanie wpisów. Na tym właśnie polega podejście zespołowe omawiane w niniejszym rozdziale: porównywalne zapisy – niezależnie od osób, agentów, sesji i narzędzi – są tym, co w ogóle umożliwia agregację na poziomie zespołu. Sposób przechowywania można dowolnie dostosowywać; należy natomiast chronić schemat.

Co będzie dalej

Zbiór dobrych zapisów stanowi surowiec, a nie wgląd w sprawę. Kolejne rozdziały podejmują ten wątek: wybór wysokości każdego punktu nawigacyjnego (różnica między notatką z pamięci a refaktoryzacją, na którą nieustannie wskazuje „tarcie”); synteza wpisów w jednostronicowe streszczenie, które zespół może wspólnie przeczytać; oraz ceremonia, podczas której ludzie spotykają się z dziennikiem — retrospektywa, w której zapisy agenta stanowią wkład uczestników. Pętla ta stanowi jeden z przykładów mechanizmu „Feedback Flywheel”: wykorzystanie zdobytej wiedzy w artefaktach dostarczających kontekst (martinfowler.com). A podstawą tej dyscypliny jest analiza błędów, „najważniejsze działanie w ramach ocen” (Husain & Shankar, FAQ dotyczące ocen), przeniesione na najkorzystniejszy moment: gdy sesja, w której wystąpiło utrudnienie, jest nadal w toku.

Wszystkie powyższe rozwiązania działają w połączeniu z plikiem tekstowym i dowolnym agentem obsługującym tę funkcję. Jeśli nie chcą Państwo samodzielnie tworzyć szablonu, bezpłatna ai-session-retroumiejętność realizuje ten schemat wprowadzania danych od początku do końca; w artykule dotyczącym szybkiego startu opisano proces jej instalacji, który zajmuje około dziesięciu minut.

Następny rozdział: Gdzie powinna znaleźć się poprawka? — problem wysokości oraz tabela routingu.