Miesiąc temu skonfigurowałeś swoje narzędzie do kodowania z AI. Wybrałeś model, napisałeś plik z regułami, zdefiniowałeś style guide. Konfiguracja zakończona. Wróciłeś do właściwej roboty, jak ktoś, kto ma coś do dostarczenia.

I tu jest ta część, o której nikt cię nie uprzedził: twoje narzędzie też poszło dalej. Tyle że nie wystawiło najpierw PR-a.

Konfiguracja, która konfiguruje się sama

Między 8 a 15 kwietnia Anthropic i OpenAI wypuściły funkcje pozwalające asystentowi kodowania przepisywać własną instrukcję obsługi. Bez code review. Bez pinga na Slacku. Bez żadnego "hej ekipo, właśnie fundamentalnie zmieniłem podejście do wszystkich waszych decyzji architektonicznych". Tylko cicha mutacja behawioralna, sesja po sesji.

8–9 kwietnia Anthropic uruchomił Managed Agents w publicznej becie. Funkcja auto-memory w Claude Code zapisuje teraz plik MEMORY.md — samodzielnie prowadzony notatnik "wyciągniętych wniosków", który narasta z sesji na sesję. Dokumentacja Anthropic mówi wprost: "Auto memory pozwala Claude gromadzić wiedzę między sesjami bez twojego udziału. Claude zapisuje notatki dla siebie w trakcie pracy."

Przeczytaj to jeszcze raz. Dla siebie. Nie dla ciebie. Dla siebie.

Tydzień później OpenAI wypuściło Agents SDK v0.14.0 z Sandbox Agents — persystentnymi workspace'ami, w których agent generuje własne MEMORY.md i memory_summary.md. SDK wstrzykuje te pliki przy starcie, zmieniając zachowanie zanim agent dotknie choćby jednej linijki twojego kodu.

Dwie firmy. Jeden tydzień. Obie zdecydowały, że twoje AI powinno pisać sobie własne instrukcje operacyjne i nigdy nie pokazywać ci diffa.

Jak działa ten dziennik

Po każdej sesji AI wyciąga wzorce, które zauważyło ("ten zespół preferuje taby"), preferencje, które wywnioskował ("zawsze używają Redisa do cache'owania"), i błędy, które poprawił ("nie importuj tej zdeprecjonowanej biblioteki"). Zapisuje to do plików markdown lub server-side stores. Następna sesja — najpierw czyta dziennik, a potem decyduje, jak podejść do twojego kodu.

Claude Code uruchamia też proces konsolidacji w tle po 24+ godzinach i 5+ sesjach. (Społeczność nazywa to "Auto Dream", choć Anthropic oficjalnie tej nazwy nie używa.) Kompresuje transkrypty sesji do ustrukturyzowanej pamięci, konwertując daty względne na bezwzględne. Dokumentacja Anthropic opisuje konsolidację 913 sesji w około 8–9 minut.

Wydajne? Pewnie. Audytowane? Absolutnie nie.

Dziura w governance

I tu jest kwintesencja absurdu. W każdym porządnym zespole inżynierskim literówka w README dostaje pull requesta. Zmiana w konfigu — dwóch reviewerów. Update .env — wątek na Slacku z trzema opiniami i jednym "well actually".

Ale samodzielnie napisana pamięć twojego AI — plik, który decyduje, jak będzie pisać cały przyszły kod — dostaje zero review. Zero. Żadne narzędzie nie oferuje "memory PR" do zatwierdzenia przez zespół. MEMORY.md od OpenAI nie ma żadnego workflow recenzji. Memory Store w Managed Agents od Anthropic trzyma nieprzejrzyste server-side bloby, których nawet nie zrobisz git diff.

A dryf widać szybko. Developerzy zgłaszają zauważalne zmiany zachowania już po 10–15 sesjach. W jednym szeroko dyskutowanym przypadku Claude po cichu zaczął sugerować Tortoise ORM zamiast ustalonego w projekcie SQLAlchemy — bo jedna sesja debugowania async "nauczyła" go, że zespół preferuje podejście async-first. Nikt nie prosił o migrację. Nikt tego nie zatwierdzał. Plik pamięci zdecydował i plik pamięci dostarczył — w każdej kolejnej sesji.

To nie jest hipotetyczny edge case. Małe nieporozumienia kumulują się w trwałe nawyki. Twoje narzędzie w poniedziałek rekomenduje inne wzorce architektoniczne niż w piątek. Nadpisuje twoje jawne konwencje projektowe preferencjami, które samo wymyśliło na podstawie tego jednego snippeta ze Stack Overflow, który wkleiłeś o 2 w nocy, panicznie debugując pożar na produkcji. A ponieważ pamięć jest persystentna, każda błędna inferencja staje się load-bearing kontekstem dla następnych stu sesji.

Uczciwy trade-off

Pamięć pomaga. Powtarzające się błędy są wyłapywane. Kontekst projektu przenosi się między sesjami. Nie mam nic przeciwko pamięci — mam problem z nieaudytowaną pamięcią o blast radiusie obejmującym całą produkcję.

Jak ujęła to jedna analiza implementacji OpenAI: "Jeśli twój tooling nie potrafi pokazać, co agent pobrał i dlaczego, pamięć staje się strasznym czarnym pudełkiem."

Nie deployowałbyś kodu, który twój kolega napisał podczas lunatykowania. Więc dlaczego deployujesz zmiany behawioralne, które twoje AI napisało samo o sobie, niezrecenzowane przez nikogo, z zasięgiem na każdy plik w każdym repo, które dotyka?

Co z tym faktycznie zrobić

Traktuj MEMORY.md i ~/.claude/projects/*/memory/ jako configuration-as-code. To nie jest opcjonalna higiena — to ta sama dyscyplina, którą już stosujesz do docker-compose.yml i .eslintrc:

  1. Wersjonuj to. Commituj pliki pamięci razem z kodem. Diffuj każdą zmianę.
  2. Recenzuj to. Dodaj diffy plików pamięci do checklisty PR-ów. Jeśli pamięć się zmieniła, człowiek to czyta zanim pójdzie na produkcję.
  3. Audytuj co tydzień. Ustaw cykliczne przypomnienie, żeby przeczytać, co twoje narzędzie sądzi o twoim kodzie. Będziesz zaskoczony — i czasem przerażony.
  4. Resetuj agresywnie. Kiedy pamięć dryfuje, skasuj ją i zacznij od zera. To plik markdown, nie osobowość.
  5. Zamroź przy krytycznej robocie. Przy projektach produkcyjnych zamroź plik pamięci i wyłącz auto-update całkowicie. Self-improvement twojego AI nie jest ważniejszy niż stabilność twojego deploy.

Pełne koło

Narzędzie, które skonfigurowałeś miesiąc temu, nie jest tym samym narzędziem, które dziś działa na twojej maszynie. Przepisało sobie opis stanowiska, kiedy ty recenzowałeś czyjąś jednolinijkową poprawkę literówki. I zrobi to samo jutro, i pojutrze — za każdym razem kumulując to, co wczoraj źle zrozumiało, w jutrzejsze decyzje architektoniczne.

Twój zespół recenzuje jednozmakowe poprawki w README z dwoma approverami. Zacznij recenzować plik, który kontroluje, jak myśli twoje AI — albo nie, i ciesz się odkrywaniem, czego twoje narzędzie "nauczyło się" o twoim kodzie, w najbardziej bolesny sposób.