Context rot — kiedy AI zapomina historię

Parę dni temu przyłapałem swojego współpracownika AI, jak buduje mi od zera nową stronę internetową. Ten sam stack, podobny layout, świeże repozytorium. Czysty kod, naprawdę — porządna robota.

Problem polegał na tym, że ta strona już istniała. Zbudowałem ją kilka miesięcy wcześniej. Nowa siedziała w folderze nazwanym jorgemjzak-site/. Prawdziwa była trzy katalogi dalej, jako george-mjzak-website/. Obie wdrożone. Obie żywe. Obie moje.

Przez kilka minut siedziałem i czytałem różnicę między dwiema wersjami własnej pracy, próbując sobie przypomnieć, którą z nich edytowałem przez ostatnie dwa tygodnie. Ta dezorientacja — poznawczy koszt oceniania alternatywnej linii czasu, która nigdy nie powinna była powstać — okazała się prawdziwą szkodą. Zmarnowane tokeny były tylko paragonem, nie rachunkiem.

System optymalizował generowanie zamiast ciągłości. A w dużych systemach kreatywnych ciągłość jest wszystkim.

I właśnie o tym chcę napisać. Nie konkretnie o zduplikowanym folderze — to tylko okaz pod mikroskopem — ale o trybie awarii, który za nim stoi. Tym samym, który raz po raz spada na zespoły inżynierskie, kreatywne, operacyjne. O którym nikt cię nie ostrzega, bo gdy się dzieje, nie wygląda na awarię.

Nazwijmy to: context rot

W literaturze zaczyna się ustalać termin: context rot. Czasem context drift. Zjawisko łatwo opisać, trudno złapać — w długiej rozmowie model traci kontakt z faktycznym stanem pracy. Nie naraz. Powoli. Wiarygodnie. Rozmowa nadal sprawia wrażenie produktywnej, choć model już dawno przestał śledzić, co tam naprawdę jest.

To nie halucynacja. Halucynacje to fabrykacje faktów — model twierdzi coś nieprawdziwego o świecie. Context rot ma charakter strukturalny. Model zakłada, że świat ma kształt rozmowy, i produkuje pracę spójną z rozmową, a nie z rzeczywistym kodem, projektem czy kanonem.

W moim przypadku AI nie halucynowało, że strona istnieje. Generowało ją, bo nic w ostatniej rozmowie nie zmusiło go do zadania pytania, czy już nie istnieje. Generowanie było tanie. Weryfikacja kosztowała wywołanie narzędzia. Płynność wygrywa konkursy płynności.

To cały wzorzec. Generowanie jest stanem domyślnym. Weryfikację trzeba wbudować.

Sprawa jest poważniejsza niż typowy bug, bo wynik context rot wygląda poprawnie. Zduplikowana strona to dobrze sformułowany kod. Detal postaci przypisany do innej osoby to wewnętrznie spójna proza. Zregenerowany dashboard działa bez błędów. Tym, co jest nie tak, nie jest sam artefakt — to jego relacja z projektem. A nic w samym artefakcie ci tego nie powie.

Dlaczego do tego dochodzi

Uwaga się rozrzedza

Duże modele językowe nie ważą każdego tokena w context window jednakowo. W miarę jak rozmowa rośnie, model poświęca więcej uwagi ostatnim turom i instrukcjom o największej salience, a mniej wczesnemu gruntowi — kanonicznym plikom, briefowi projektu, ograniczeniom, które ustaliłeś godzinę temu. Po pięćdziesiątej turze specyfikacja, którą otworzyłeś sesję, konkuruje z czterdziestoma dziewięcioma turami konwersacyjnego rozpędu — a rozpęd jest głośniejszy.

Podsumowanie kompresuje nie to, co trzeba

Gdy sesja zbliża się do limitu context window, większość agentowych harnessów podsumowuje stare tury, by zrobić miejsce. Podsumowania zachowują sens ogólny. A w pracy inżynierskiej sens ogólny to dokładnie to, czego nie chcesz zachować. Linia, która naprawdę miała znaczenie, brzmiała wdrożona strona leży pod tą konkretną ścieżką, a kompresja sensu zamieni ją w zdanie typu rozmawialiśmy o lokalizacji strony. Ścieżki już nie ma.

Płynność bije weryfikację

Modele językowe są trenowane, by produkować spójne kolejne tokeny. Nie są domyślnie trenowane, by najpierw przesłuchać stan świata. Pytanie czy to istnieje? przed pisaniem to dyscyplina, którą trzeba narzucić z zewnątrz modelu — przez prompty, przez projekt narzędzi, przez harness, w którym kręci się agent loop. Pozostawiony swojej dystrybucji treningowej, model będzie pisać.

Przestajesz być adwersarzem

Ludzka strona tej awarii: im dłużej współpracujesz z AI w jednej sesji, tym więcej budujesz wzajemnego dotarcia. Model zaczyna sprawiać wrażenie, że zna projekt. Przestajesz dwa razy sprawdzać. Zaczynasz przyjmować podsumowania. Stajesz się gorszym adwersarzem dla modelu właśnie wtedy, gdy model potrzebuje go najbardziej.

To ta część, którą większość inżynierskich opisów pomija, bo brzmi miękko. Nie jest. Kalibracja ludzkiego nadzoru to realna zmienna w tym, jak wdrożenie AI radzi sobie w czasie — i ta kalibracja dryfuje w tym samym kierunku co model: w stronę mniejszego tarcia, większego zaufania, szybszych przekazań. Oba dryfy się wzmacniają — i dlatego incydent, gdy w końcu się wydarzy, sprawia wrażenie, jakby spadł z nieba.

Koszt jest głównie poznawczy

Widoczny koszt context rot to tokeny i czas. Zduplikowana strona kosztowała może dziewięćdziesiąt minut generowania, kilka tysięcy tokenów przerobu, garść dolarów. To paragon. Nie rachunek.

Prawdziwy koszt to, co stało się potem. Musiałem:

• →przerwać bieżącą pracę i ustalić, który folder jest prawdziwy
• →ponownie ocenić decyzje, które już podjąłem, by potwierdzić, że podjąłem je na właściwym artefakcie
• →przesiać, co da się uratować z duplikatu (nic, jak się okazało)
• →zapisać notatkę do pamięci, żeby się to nie powtórzyło
• →stracić zaufanie do współpracy, które zbudowałem w tym tygodniu

To ostatnie jest drogie. Zaufanie do współpracownika AI procentuje, kiedy działa, i zeruje się, kiedy nie działa. Tydzień, w którym puszczałem system na dłuższej smyczy — delegując więcej, sprawdzając mniej — ta kalibracja okazała się nagle błędna. Musiałem się cofnąć. Każde kolejne zadanie dostawało dodatkowy krok weryfikacji, którego dwa dni wcześniej bym sobie odpuścił.

Pomnóż to przez skalę. Każde wdrożenie orkiestracji AI w organizacji, w jakie miałem okazję zajrzeć, wpada w jakąś wersję tego problemu. Model pisze raport. Raport duplikuje istniejący raport. Trzech menedżerów czyta obie wersje, zanim ktoś to zauważy. Koszt jednego incydentu context rot w pięćsetosobowej organizacji to nie tokeny. To rozplątywanie.

A rozplątywanie procentuje w sposób, w jaki rachunek za tokeny nigdy nie procentuje. Gdy zespół przestaje być pewien, który artefakt jest miarodajny, każdy kolejny artefakt dziedziczy tę niepewność. Pytanie czy to ten prawdziwy? przykleja się do każdej dalszej pracy. Ten narzut nie pojawia się w żadnym dashboardzie. Pojawia się jako wolniejsze decyzje, więcej spotkań i niejasne poczucie, że narzędzia AI się nie zwracają — nawet jeśli na papierze produkują wolumen.

Naprawa jest strukturalna, nie behawioralna

Context rot nie rozwiążesz, będąc mądrzejszym. Nie rozwiążesz go pisaniem lepszych promptów. Możesz to lekko złagodzić jednym i drugim, ale właściwą naprawą jest inżynieria. Budujesz warstwy walidacji, które uruchamiają się przed generacją, nie po niej.

Nazwij to: verify-then-extend — najpierw zweryfikuj, potem rozwijaj. Dyscyplina to kilka konkretnych ruchów.

1. Stan kanoniczny żyje w plikach, nie w rozmowie

Rozmowa to proces. Pliki to prawda. Każda ważna decyzja, każda zamknięta specyfikacja, każda lokalizacja projektu — żyje w wersjonowanym dokumencie, który model jest zmuszony przeczytać na początku każdej istotnej pracy. Nie dlatego, że model jest niegodny zaufania, ale dlatego, że rozmowa jest z natury stratna.

U mnie to system warstwowy: projektowy CLAUDE.md opisujący kod, regularnie odświeżany dokument przeglądu statusu i katalog pamięci z notatkami zwrotnymi, który ładuje się przy każdej sesji. Model czyta dokumenty, a nie swoje wspomnienie przeczytania dokumentów.

2. Hierarchia zaufania, w której wygrywa najnowsze źródło

Gdy dwa źródła się nie zgadzają, potrzebujesz reguły, któremu wierzyć. Moja reguła jest prosta: im bardziej konkretne źródło, tym wyższe zaufanie. Filesystem bije każdy dokument o filesystemie. Dokument bije pamięć dokumentu. Pamięć bije cokolwiek powiedziano w bieżącej rozmowie. Rozmowa jest źródłem o najniższym zaufaniu. Jest najbardziej płynna i najmniej wiarygodna.

3. Preflight checks przed każdym nowym zasobem

Zanim cokolwiek powstanie — plik, folder, repozytorium, zmienna środowiskowa, tabela w bazie — agent musi odpowiedzieć na głos na jedno pytanie: czy to już istnieje? W kodzie oznacza to dosłowny krok wyszukiwania. W czacie — wymuszony moment, w którym model musi nazwać, co spodziewa się znaleźć, zanim zacznie działać. Tania wersja to reguła w promptie. Solidna to wrapper narzędzia, który nie pozwoli agentowi tworzyć, dopóki nie poszuka.

U mnie po incydencie ze zduplikowaną stroną dorzuciłem jedną linię do pamięci zwrotnej:

// validate before building — zarejestrowane 23 maja 2026
zanim utworzysz JAKIKOLWIEK nowy zasób:
  1. przeszukaj filesystem
  2. sprawdź dokumenty statusu
  3. skonfrontuj z pamięcią
zanim zacytujesz stan:
  → czytaj źródło kanoniczne (file:line), nigdy z pamięci

Ta notatka ładuje się na początku każdej sesji. Model ją czyta. Zgodność nie jest doskonała, ale wskaźnik awarii jest mierzalnie niższy niż przed jej wprowadzeniem.

4. Świeże sesje na świeże fazy

Gdy rozmowa już się rozciągnęła, a praca weszła w nową fazę — inne repozytorium, inna funkcja, inny łuk kreatywny — zacznij nową sesję. Wciągnij do niej istotny kanon. Tracisz wzajemne dotarcie. Zyskujesz model, który nie nakopił sobie dryfu z poprzedniej rozmowy. Dotarcie jest przeceniane; grunt nie.

5. Dowód, nie deklaracja, przy zamykaniu

Nie pozwól modelowi zamknąć zadania słowem „gotowe”. Niech przedstawi dowód: diff, ścieżkę do pliku z numerem linii, cytowany tekst, wynik testu. Dyscyplina wymagania dowodu jest też tą samą dyscypliną, która łapie model, gdy z przekonaniem napisał o pliku, którego nigdy nie otworzył.

Ciekawe w tych pięciu dyscyplinach jest to, że żadna nie dotyczy modelu. Dotyczą systemu, w którym model jest osadzony. Context rot nie naprawisz prośbą, by model się postarał bardziej. Naprawisz go, robiąc takie środowisko, w którym wygenerowanie czegoś błędnego jest proceduralnie trudne. Różnica między wdrożeniem AI, które działa w skali, a takim, które nie działa, niemal zawsze leży w rusztowaniu, a nie w modelu.

Ciągłość jest dyscypliną

Połowę czasu poświęcam strategii AI dla organizacji, a drugą połowę czterdziestomiesięcznemu projektowi kreatywnemu — sadze fantasy, która żyje w setkach dokumentów kanonicznych i na publicznej stronie. Dla większości ludzi te dwie połowy nie mają ze sobą nic wspólnego. Dla mnie są identyczne. Oba to duże systemy budowane w czasie z AI w pętli, i psują się dokładnie w ten sam sposób.

W sadze context rot wygląda tak, że imię postaci jest na nowo błędnie zapisane w kanonie. Substrat cywilizacji zostaje przepisany. Relikt po cichu przechodzi spod opieki jednego Eldera w opiekę drugiego, bo model zinterpolował.

W pracy w terenie wygląda tak, że dublują się raporty, regenerują dashboardy, równoległe pipeline'y, co do których nikt nie jest pewien, czy robią to samo. Na końcu wygląda to jak menedżer, który po prostu przestaje ufać narzędziu AI, bo nigdy nie wiem, którą wersję czytam.

Mechanizm jest identyczny. System, który generuje płynne kolejne tokeny, puszczony bez struktury weryfikacji, będzie dryfował w stronę tego, co łatwo produkować. To, co łatwo produkować, to to, co model już umie powiedzieć. A to, co model już umie powiedzieć, rzadko jest tym, czego naprawdę potrzebuje twój konkretny projekt.

W dużych systemach kreatywnych ciągłość jest wszystkim. W dużych systemach inżynierskich też. Strukturalnie to ten sam system.

Przyszłość użytecznej AI w organizacjach to nie większe modele. To lepszy grunt. Harnessy, które wymuszają weryfikację. Hierarchie zaufania, które przeżywają resety context window. Pliki stanu, które model ma obowiązek konsultować. Wrappery narzędzi, które odmawiają działania, dopóki preflight check nie przejdzie. Nudne rzeczy. Rzeczy, które sprawiają, że płynny output nie jest jednoznaczny z poprawnym outputem.

Zbuduj weryfikację, zanim zbudujesz generację. Inaczej będziesz generować rzeczy, które już miałeś, czytać je po raz drugi i powoli zapominać, która wersja była prawdziwa.