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 cytowanych dowodach obserwacje, 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ępnych jest najwięcej informacji na jego temat: dokładny nieaktualny wiersz w podręczniku procedur, dokładny parametr, który pozostawiono otwarty w briefie. Informacje te szybko tracą na aktualności. Agent normalizuje swoje własne obejście w ciągu kilku cykli, a pod koniec sesji sygnał znika, o ile nie został gdzieś zapisany; cokolwiek ustali subagent, „znika w chwili, gdy zwraca wynik” (Hindsight, maj 2026). Niniejszy rozdział dotyczy właśnie procesu zapisywania.

W jaki sposób zauważamy tarcie

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

Agent dostrzega, że ma trudności. Pętle ponownych prób, cofanie się, ponowne odczytywanie tego samego pliku lub ponowne wysyłanie zapytania do tego samego widoku analitycznego – to domysły wymuszone luką w briefie. Platformy produkcyjne zbiegały się zasadniczo w kierunku tej listy sygnałów behawioralnych (Factory Signals, styczeń 2026 r.). Najtańszy kanał, charakteryzujący się dwoma istotnymi ograniczeniami: nie dostrzega on tego, czego nie ma (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 agenckie nawet w przypadku wyselekcjonowanych śladów (~11%, TRAIL). Zatem zadaniem w trakcie sesji jest obserwacja symptomów i przytaczanie dowodów, traktując diagnozę z pewną dozą elastyczności.

Drugi pracownik weryfikuje transkrypcję. Osoba dokonująca weryfikacji z innej perspektywy dostrzega to, co pracownik odpowiedzialny za przetwarzanie uznał za prawidłowe. Jest to podejście bardziej obiektywne; wiąże się jednak z koniecznością przeprowadzenia dodatkowego przeglądu i niesie ze sobą ryzyko własnych błędów w ocenie.

Człowiek koryguje działanie agenta. Nadal dominujący czujnik: w ramach 8-tygodniowego badania produkcyjnego stwierdzono, że około 70% cichych awarii agentów zostało wykrytych po raz pierwszy 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 (słowa 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 wprowadzana przez człowieka pozwala zidentyfikować te problemy, których nie są w stanie wykryć żadne sygnały automatyczne. Niezależnie od tego, jaką kombinację zastosują Państwo, efekt powinien być zawsze ten sam: zapis danych.

Co skłania agenta do zarejestrowania tego zdarzenia?

Agent nie zarejestruje tarcia, którego nikt nie polecił mu wyszukiwać. 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 pod koniec 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. Słaby punkt: 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 czymś (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 wystąpionych trudności”. Brak infrastruktury, jednak rozwiązanie to opiera się całkowicie na tym, że model przestrzega jednej z wielu wytycznych, a jego skuteczność maleje wraz z rosnącym rozmiarem pliku; nazwanym trybem awarii jest plik pamięci, który „przestał być odczytywany” (notatka terenowa dotycząca antywzorców).
• Polecenie: polecenie wpisane przez człowieka na/retro zakończenie gałęzi funkcji lub zmiany w ramach procesu selekcji. Jest to działanie przemyślane i precyzyjnie zaplanowane czasowo; słabym ogniwem jest tu ludzka pamięć.

Składają się one z następujących elementów; proszę je ułożyć warstwowo. Wyzwalacz deterministyczny (hak lub etap procedury SOP oznaczający koniec zmiany), ładunek proceduralny (umiejętność) oraz zapis konwencyjny, który określa daną praktykę jako normę. Proszę wybrać co najmniej jeden wyzwalacz; lepiej dwa. Nawet dostawcy doszli do tego wniosku: wytyczne OpenAI dotyczące Codexu brzmią: „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 tarcie, a wszystkimi elementami znajdującymi się w dalszej części łańcucha. Jakość syntezy jest ograniczona jakością zapisu. Cztery elementy nośne:

1. Moment poparty dowodami 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. Koszt oznacza konieczność ponownego wykonania pracy, stratę czasu 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 odnotować, (est.)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 (metoda MAST osiągnęła 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 pracowano, spowalniał pracę lub powodował częste błędy: dług techniczny lub niejasna struktura kodu; zagmatwane konto, tabela, 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 zmieniły się 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 piaskownicą lub platformą

Jedna etykieta na każdy wynik zapewnia rzetelność klasyfikacji: należy wybrać opcję najlepiej pasującą, odnotować 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 racjonalnie szukać? 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 błędnych 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 biletu, 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 jest 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 (est.)symbolem, 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: rejestrowanie powinno przebiegać w trybie nieograniczonym: agent, który potrzebuje zgody na rejestrowanie, 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:

• Tajemnice, 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. Proszę opisać lukę i jej skutki: „brief pozostawił odbiorców bez odpowiedzi”, a nie „brief X”. Wpisy powinny zawierać krytykę danych wejściowych i systemów, a nie osób. Jest to ta sama zasada, na której opiera się dobra retrospektywa, i dzięki której wspólne czytanie dziennika przebiega bez obaw.

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 poddawać się takiej samej szczerej samoocenie. Jeśli nie da się opisać trudności związanych z danym zakresem bez ujawnienia poufnego kontekstu, należy zachować prywatność wpisów dotyczących tego zakresu 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 tam również powinien znajdować się dziennik problemów. Poza kodem zakresem jest konto reklamowe, skrzynka odbiorcza działu wsparcia technicznego oraz relacje z klientami; dziennik należy przechowywać w lokalizacji dokumentów danego obszaru roboczego. Zapis umieszczony poza tym zakresem to taki, 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. Kolejne rozdziały podejmują ten wątek: wybór wysokości każdego punktu orientacyjnego (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 „koła zamachowego informacji zwrotnej”: wykorzystanie wniosków w artefaktach dostarczających kontekstu (martinfowler.com). A dyscypliną wprowadzania danych jest analiza błędów, „najważniejsze działanie w ocenach” (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, jak zainstalować ją w około dziesięć minut.

Następny rozdział: Gdzie powinna zostać wprowadzona poprawka? dotyczy problemu wysokości oraz tabeli routingu.