Twój agent pisze szybciej, niż Pan/Pani zdąży przeczytać

W zeszły wtorek mój autonomiczny agent kodujący ukończył refaktoryzację 47 plików w 9 minut. Testy przeszły. Linting przeszedł. Bramki jakości nie wykryły żadnych naruszeń. Scaliłem PR, wdrożyłem i poszedłem dalej. Trzy dni później członek zespołu zapytał, dlaczego logika ponawiania prób w usłudze płatności zmieniła się z wykładniczego wycofywania na odpytywanie w stałych odstępach. Nie wiedziałem, że się zmieniła. Komunikat commitu od agenta brzmiał „refactor: standardize retry patterns across services”. Zmiana była technicznie poprawna. Nigdy nie przeczytałem linii 847 pliku 31.

Dług poznawczy to przepaść między kodem, który agent AI wysyła, a tym, co programista faktycznie rozumie z tego kodu. W przeciwieństwie do długu technicznego, który żyje w bazie kodu, dług poznawczy żyje w głowie programisty. Kumuluje się wraz z prędkością agenta — agenty produkujące 140-200 linii na minutę generują dług szybciej, niż programiści są w stanie go spłacić poprzez przeglądy. Pięć niezależnych zespołów badawczych opublikowało prace na ten problem w ciągu jednego tygodnia, potwierdzając, że jest to centralne wąskie gardło w programowaniu wspomaganym przez agenty.

Ta przepaść między tym, co zostało wysłane, a tym, co zrozumiałem, to właśnie dług poznawczy.

TL;DR

Pięć niezależnych zespołów badawczych opublikowało w jednym tygodniu prace na ten sam strukturalny problem: agenty kodujące produkują wyniki szybciej, niż programiści mogą je zweryfikować, zrozumieć i utrzymywać. Margaret-Anne Storey nazwała ten wzorzec „długiem poznawczym”. Badacze z Microsoft, ETH Zurich i wielu uniwersytetów budują systemy do wykrywania nieprawidłowych zachowań agentów, uczynienia wywołań narzędzi transakcyjnymi oraz testowania, jak agenty uczą się poprzez interakcję. Ta zbieżność ma znaczenie, ponieważ sygnalizuje, że społeczność badawcza dogania problem, który praktycy rozwiązywali doraźnymi bramkami jakości. Problem niezawodności agentów ma teraz nazwę, taksonomię i pięć konkurencyjnych podejść. Poniżej: badania, sposób wykrywania długu poznawczego we własnym przepływie pracy oraz minimalna realna interwencja, którą można wdrożyć już dziś.

Pięć prac, jeden tydzień, jeden problem

Między 15 a 21 lutego 2026 roku pięć niezależnych grup opublikowało prace dotyczące tej samej strukturalnej wady agentów kodujących AI. Żadna z nich nie cytowała pozostałych. Każda podchodziła do problemu z innej strony. Wszystkie doszły do tego samego wniosku: wąskim gardłem w programowaniu wspomaganym przez agenty nie jest już jakość kodu. Wąskim gardłem jest ludzkie zrozumienie.

Margaret-Anne Storey sformułowała koncepcję „długu poznawczego”, aby opisać to, co kumuluje się, gdy agenty produkują kod, który może być czysty, przetestowany i dobrze skonstruowany, podczas gdy programiści tracą orientację co do tego, co kod faktycznie robi.¹ Dług techniczny żyje w bazie kodu. Dług poznawczy żyje w głowie programisty. Ujęcie Storey przesuwa pytanie o niezawodność agentów z „czy kod działa?” na „czy programista rozumie kod?”.

Nanda i in. z Microsoft opublikowali Wink, system do automatycznego wykrywania i odzyskiwania po nieprawidłowych zachowaniach agentów kodujących.² Ich taksonomia identyfikuje trzy tryby awarii: odchylenie od instrukcji (agent robi coś innego niż to, o co się prosiło), powtarzalne pętle (agent wielokrotnie próbuje tego samego nieudanego podejścia) oraz nadużywanie narzędzi (agent wywołuje niewłaściwe narzędzie lub przekazuje błędne argumenty). Wink monitoruje zachowanie agenta w czasie rzeczywistym i interweniuje, zanim nieprawidłowe zachowanie się spotęguje.

Mohammadi i in. z ETH Zurich przedstawili Atomix, środowisko uruchomieniowe, które opakowuje wywołania narzędzi agentów w transakcje.³ Gdy wieloetapowy plan agenta kończy się niepowodzeniem w trakcie, Atomix wycofuje skutki uboczne. Kluczowy wniosek: agenty działają na systemach zewnętrznych (bazy danych, API-y, systemy plików), a te działania mają konsekwencje, których agent nie może cofnąć bez jawnej infrastruktury wycofywania.

Hallinan i in. stworzyli OpaqueToolsBench, benchmark mierzący, jak agenty uczą się zachowania narzędzi poprzez interakcję, a nie dokumentację.⁴ Narzędzia w świecie rzeczywistym są słabo udokumentowane. Benchmark sprawdza, czy agenty potrafią odkrywać tryby awarii, najlepsze praktyki i przypadki brzegowe metodą prób i błędów. Wynik: agenty, które samodzielnie eksplorują zachowanie narzędzi, dają lepsze rezultaty niż agenty otrzymujące idealną dokumentację, której nigdy nie weryfikują.

Deng i in. ocenili 28 systemów testów penetracyjnych opartych na LLM i zidentyfikowali dwie odrębne kategorie awarii.⁵ Awarie typu A wynikają z brakujących możliwości (niewłaściwe narzędzia, złe prompty), które inżynieria łatwo naprawia. Awarie typu B utrzymują się niezależnie od oprzyrządowania, ponieważ agent nie ma osądu niezbędnego do oceny własnych wyników. Typ B to problem długu poznawczego wyrażony jako ryzyko bezpieczeństwa: agent znajduje sześć z siedmiu luk, ale pewnie raportuje, że system jest bezpieczny.

Zbieżność ma większe znaczenie niż pojedyncza praca

Jedna praca o niezawodności agentów jest interesująca. Pięć prac w jednym tygodniu od niezwiązanych zespołów to sygnał. Społeczność badawcza niezależnie dochodzi do tego samego wniosku, który praktycy odkrywali poprzez awarie produkcyjne.

Budowałem system jakości Jiro począwszy od maja 2025. System wymusza 7-etapową pętlę jakości, bramkę dowodową złożoną z 6 kryteriów oraz 7 nazwanych trybów awarii, które bezpośrednio odwzorowują się na wzorce opisane w tych pracach:

Oś czasu ma znaczenie. Dziewięć miesięcy debugowania metodą prób i błędów w środowisku produkcyjnym, budowania bramek jakości jedna po drugiej przy każdej awarii, zaowocowało architekturą, którą pięć prac badawczych obecnie niezależnie formalizuje. Problemy strukturalne są realne. Rozwiązania doraźne działają. Badania doganiają praktykę z ramami, taksonomiami i benchmarkami, które czynią rozwiązania odtwarzalnymi.

Trzy prawa długu poznawczego

Ujęcie Storey krystalizuje to, co zaobserwowałem w ciągu 11 miesięcy autonomicznego rozwoju agentów. Trzy wzorce utrzymują się niezależnie od modelu, oprzyrządowania czy dziedziny:

1. Dług poznawczy kumuluje się wraz z prędkością. Mój agent średnio wprowadza 140-200 linii znaczących zmian w kodzie na minutę podczas sesji refaktoryzacji (mierzone z git diffów, z wyłączeniem białych znaków). Skupiony programista-człowiek produkuje mniej więcej 20-40 linii na minutę podczas aktywnego kodowania.⁸ Pętla Ralph, która uruchamia Claude za 10 USD/godzinę, nie produkuje 5-krotności długu poznawczego programisty. Produkuje znacznie więcej, ponieważ prędkość pisania programisty jest sprzężona z prędkością jego myślenia. Prędkość wyjścia agenta nie ma sprzężenia z prędkością Państwa zrozumienia. Wyjście się podwaja; zrozumienie pozostaje stałe; dług się kumuluje.

2. Przechodzące testy nie spłacają długu poznawczego. Każda praca z tego tygodniowego klastra traktuje przejście testów jako konieczny, ale niewystarczający sygnał. Awarie typu B z pracy Denga i in. przechodzą wszystkie zautomatyzowane kontrole. Taksonomia nieprawidłowych zachowań Wink obejmuje agenty, które produkują działający kod niezgodny z intencją. Moja bramka dowodowa wymaga sześciu kryteriów poza „testy przechodzą”, a najtrudniejszym kryterium do zweryfikowania wciąż pozostaje „czy programista rozumie, co się zmieniło?”.⁶

Oto konkretny przykład. Mój agent zrefaktoryzował zapytanie do bazy danych, aby używało CTE (Common Table Expression) zamiast podzapytania. Oba podejścia zwracały identyczne wyniki. Testy przeszły. Wersja z CTE działała 3-krotnie wolniej na naszym zbiorze danych, ponieważ planista zapytań nie mógł wepchnąć predykatów do CTE. Wykryłem to podczas rutynowego sprawdzenia EXPLAIN ANALYZE dwa tygodnie później. Testy agenta weryfikowały poprawność. Nic w zestawie testów nie weryfikowało charakterystyki wydajnościowej. Dług poznawczy nie polegał na „złym kodzie”. Dług poznawczy polegał na tym, że „nie wiedziałem, iż plan wykonania się zmienił”.

3. Dług poznawczy jest niewidoczny, dopóki nie jest. Dług techniczny obwieszcza się poprzez wolne budowy, niestabilne testy i konflikty scalania. Dług poznawczy jest cichy, dopóki ktoś nie zapyta „dlaczego usługa płatności używa odpytywania w stałych odstępach?” i nikt nie wie. Wkład Storey polega na nadaniu nazwy niewidocznemu problemowi.

Pięć znaków ostrzegawczych, że kumuluje się dług poznawczy

Zanim będzie można naprawić problem, trzeba go zauważyć. Te pięć sygnałów pojawia się, zanim dojdzie do incydentów produkcyjnych:

1. Nie potrafi Pan/Pani wyjaśnić ostatniego PR-a agenta bez ponownego przeczytania. Proszę otworzyć najnowszy PR utworzony przez agenta. Bez zaglądania do diffa, proszę opisać, co się zmieniło i dlaczego. Jeśli to niemożliwe, scalono kod, którego się nie rozumie. Śledzę to, dodając jednolinijkową „kontrolę streszczenia” do mojego procesu przeglądu: przed zatwierdzeniem piszę jednozdaniowe wyjaśnienie w komentarzu PR. Jeśli nie potrafię napisać tego zdania, nie przejrzałem wystarczająco.

2. Państwa git log --stat pokazuje sesje z 20+ modyfikowanymi plikami. Proszę uruchomić to teraz:

git log --stat --since="1 week ago" --author="$(git config user.name)" | \
  awk '/files? changed/ {files+=$1} END {print files, "files changed this week"}'

Proszę porównać tę liczbę z tym, ile z tych plików można opisać z pamięci. Różnica to zaległości długu poznawczego.

3. Przegląda Pan/Pani diffy poprzez przewijanie, nie czytanie. Przewijanie to dopasowywanie wzorców: „to wygląda dobrze”. Czytanie to rozumienie: „to zmienia interwał ponawiania z wykładniczego na stały, co oznacza, że usługa po stronie konsumenta zobaczy inny wzorzec ruchu”. Jeśli Państwa przegląd zajmuje mniej niż jedną minutę na 100 linii diffa, przewijacie Państwo, a nie czytacie.

4. Komunikaty Państwa commitów opisują CO, a nie DLACZEGO. „Refactor: standardize retry patterns” opisuje, co zrobił agent. „Fix: exponential backoff caused thundering herd after service restart” opisuje dlaczego. Jeśli komunikaty commitów agenta czytają się jak pierwszy przykład i ich Pan/Pani nie przepisuje, nikt (łącznie z Panem/Panią w przyszłości) nie będzie znał uzasadnienia zmiany.

5. Czuje się Pan/Pani produktywnie, ale nie potrafi wymienić, co się zmieniło. Pod koniec dnia pracy z agentem proszę spisać z pamięci trzy najbardziej znaczące zmiany w kodzie. Jeśli sprawia to trudność, agent był produktywny. Pan/Pani nie. Dług kumulował się, podczas gdy czuliście się Państwo efektywni.

Proszę zacząć tutaj: protokół trzech plików

Nie trzeba 95 hooków, 7 nazwanych trybów awarii ani systemu deliberacji wieloagentowej, aby zacząć zarządzać długiem poznawczym. Proszę zacząć od jednej reguły i budować dalej.

Reguła: Po każdej sesji agenta należy w pełni przeczytać trzy pliki. Nie przeglądać pobieżnie. Nie przewijać. Przeczytać każdą linię trzech plików z największymi diffami.

Dlaczego trzy? Bo trzy pliki są osiągalne (faktycznie się to zrobi) i diagnostyczne (odkryje się, czy zmiany agenta pasują do Państwa modelu mentalnego). Jeśli pasują, dług jest możliwy do opanowania. Jeśli nie, ma Pan/Pani wskaźnik wyprzedzający, że pozostałe zmiany z sesji również odbiegają od Państwa zrozumienia.

Wdrożenie

Po zakończeniu pracy agenta należy uruchomić:

# Show the 3 files with the largest diffs from the last commit
git diff HEAD~1 --stat | sort -t'|' -k2 -rn | head -3

Następnie proszę przeczytać te trzy pliki. Nie diff. Cały plik. Kontekst ma znaczenie: diff pokazuje, co się zmieniło, ale plik pokazuje, co ta zmiana oznacza w kontekście.

Ścieżka rozbudowy

Gdy protokół trzech plików stanie się nawykiem (mniej więcej tydzień), proszę dodawać po jednej warstwie naraz:

Każda warstwa spłaca określoną kategorię długu poznawczego. Czytanie trzech plików wychwytuje luki w zrozumieniu. Streszczenie PR wychwytuje rozbieżność intencji. Sprawdzanie zapytań wychwytuje incydent z CTE, który opisałem powyżej. Przepisanie commitu zachowuje uzasadnienie, które inaczej by się ulotniło. Nazwane tryby awarii zapobiegają powtarzającym się błędom.

Co proponują badania (a co faktycznie działa)

Pięć prac wskazuje cztery strukturalne interwencje. Wszystkie cztery istnieją w jakiejś formie w moim łańcuchu narzędzi Claude Code, zbudowanym przed publikacją tych prac, zwalidowanym przez te same wzorce, które opisują prace.

Niezależna weryfikacja. Wink monitoruje zachowanie agenta w zestawieniu z deklarowaną intencją. Moja pętla jakości wymaga ponownego przeczytania każdej napisanej linii, wyraźnie zabraniając trybu awarii Fantomowa Weryfikacja (twierdzenie, że testy przechodzą, bez ich uruchomienia w bieżącej sesji).⁷ Rozwiązanie jest strukturalne: weryfikacja musi być wykonywana przez inny proces niż ten, który wyprodukował wynik.

W praktyce wymuszam to za pomocą hooka po sesji, który uruchamia zestaw testów niezależnie, zamiast ufać raportowi agenta:

# Post-session verification hook (simplified)
# Agent says "tests pass" — verify independently
cd "$PROJECT_DIR"
test_output=$(python -m pytest --tb=short -q 2>&1)
exit_code=$?

if [ $exit_code -ne 0 ]; then
  echo "AGENT CLAIMED TESTS PASS. INDEPENDENT RUN FAILED:"
  echo "$test_output"
  exit 1
fi

Agent zaraportował „wszystkie testy przechodzą” i tak myślał. Niezależne uruchomienie wychwytuje różnice środowiskowe, brakujące fikstury oraz testy, które przechodzą przez skutki uboczne, a nie poprawność. W ciągu 11 miesięcy działania tego hooka wychwycił on 23 fałszywe pozytywy z samoraportów agenta.⁹

Granice transakcyjne. Atomix opakowuje wywołania narzędzi w transakcje z możliwością wycofania. Mój system deliberacji bramkuje nieodwracalne działania poprzez konsensus wielu niezależnych agentów. Oba podejścia dodają tarcie do wykonania agenta w punktach, gdzie błędy są najbardziej kosztowne. Praktyczna wersja dla większości zespołów: wymagać ręcznego kroku zatwierdzenia przed jakąkolwiek inicjowaną przez agenta migracją bazy danych, wdrożeniem lub zewnętrznym wywołaniem API.

Taksonomie behawioralne. Trzy tryby awarii Wink (odchylenie, pętle, nadużywanie narzędzi) oraz moje siedem nazwanych trybów awarii (Spirala Skrótów, Miraż Pewności, Plateau Wystarczająco Dobre, Widzenie Tunelowe, Fantomowa Weryfikacja, Odroczony Dług, Pusty Raport) służą temu samemu celowi: czynią niewidoczne awarie widocznymi, nadając im nazwy.⁷ Programista, który potrafi powiedzieć „agent przejawia Widzenie Tunelowe”, może interweniować, zanim dług się spotęguje. Warto zacząć od trzech nazw dla trzech najczęstszych błędów agenta w Państwa zespole. Nazwy mają większe znaczenie niż sama taksonomia.

Selektywne zaangażowanie. Rozróżnienie typu A/typu B Denga i in. oraz moduł pewności w moim systemie deliberacji kodują ten sam wniosek: nie każdy wynik agenta zasługuje na ten sam poziom analizy. Użyteczna heurystyka:

Pytanie, na które nikt jeszcze nie odpowiedział

Wszystkie pięć prac opisuje problem. Wink, Atomix i OpaqueToolsBench proponują częściowe rozwiązania. Żadna z nich nie odpowiada na pytanie, które ma największe znaczenie: jak mierzyć dług poznawczy?

Dług techniczny ma swoje wskaźniki zastępcze: złożoność cyklomatyczną, pokrycie testami, wiek zależności. Dług poznawczy nie ma równoważnej metryki. Moja bramka dowodowa pyta „czy programista rozumie, co się zmieniło?”, ale wymusza odpowiedź poprzez samoocenę, co jest dokładnie tą metodą weryfikacji, którą eksploatuje tryb awarii Miraż Pewności.

Użyteczna metryka śledziłaby różnicę między tym, co agent zmienił, a tym, co programista potrafi wyjaśnić. Liczba plików to prymitywny wskaźnik zastępczy. Złożoność diffu (nie liczba linii, lecz semantyczna gęstość zmian) jest lepsza. Idealna metryka korelowałaby z prawdopodobieństwem incydentu produkcyjnego spowodowanego niezrozumieniem kodu wygenerowanego przez agenta. Nikt jeszcze nie zbudował takiej metryki. Interaktywny kalkulator powyżej przybliża ten stosunek, ale stosunek to nie próg. Nie wiemy jeszcze, gdzie leży granica między „możliwym do opanowania długiem” a „incydentem czekającym na wystąpienie”.

Dopóki ktoś nie zbuduje tej metryki, praktyczną odpowiedzią jest ta sama, która poprzedza agenty AI: czytać kod. Prędkość agenta czyni czytanie każdej linii niepraktycznym. Protokół trzech plików, taksonomie behawioralne i granice transakcyjne redukują objętość kodu wymagającą ludzkiej uwagi. Dług poznawczy, który pozostaje po tych filtrach, to dług, który ma znaczenie.

Kluczowe wnioski

• Pięć niezależnych zespołów badawczych zbiegło się przy tym samym problemie w jednym tygodniu. Gdy niezwiązane zespoły dochodzą jednocześnie do tego samego wniosku, problem leżący u podstaw jest strukturalny, a nie teoretyczny.
• Wąskim gardłem jest dług poznawczy, a nie jakość kodu. Agenty produkują poprawny kod szybciej, niż programiści są w stanie go zrozumieć. Testy, lintery i bramki jakości redukują problem, ale nie mogą go wyeliminować.
• Warto zacząć od protokołu trzech plików. Po każdej sesji agenta należy w pełni przeczytać trzy pliki z największymi diffami. Dodatkowe warstwy (streszczenia PR, sprawdzanie zapytań, przepisywanie commitów, nazwane tryby awarii) można dodawać po jednej na tydzień.
• Nazywać tryby awarii. Taksonomia Wink i nazwane tryby awarii Jiro służą temu samemu celowi: czynieniu niewidocznych problemów widocznymi. Jeśli Państwa system agentów nie ma nazw dla swoich wzorców awarii, nie można ich wykryć.
• Dodawać tarcie przy nieodwracalnych granicach. Transakcyjne wywołania narzędzi (Atomix) i konsensus wieloagentowy (deliberacja) dodają koszt w punktach, gdzie błędy są najbardziej kosztowne. Warto tego kosztu.

FAQ

Bibliografia