Agent nie stał się mądrzejszy — to projekt się zmienił

Sześć miesięcy temu zadanie programistyczne wymagało całej sesji wyjaśnień. W zeszłym tygodniu to samo zadanie zajęło jedno zdanie. Model nie zmienił się między tymi dwiema sesjami. Claude Opus 4.6 obsługiwał obydwie. Te same wagi, ta sama architektura, to samo okno kontekstu, te same możliwości.

Agent AI nie stał się mądrzejszy między sesją 1 a sesją 500; zmieniła się infrastruktura projektu. To główna teza obszaru AI engineering: model jest stałą, a zmienną jest wszystko, co budujemy wokół niego. W długotrwałych projektach model odpowiada za około 30% jakości sesji, podczas gdy pozostałe 70% zapewnia zakumulowany kontekst: dokumenty konwencji, pamięć decyzji, artefakty przekazania, hooki, umiejętności i pokrycie testami. Gorszy model w bogatym projekcie często przewyższa lepszy model w projekcie pustym.

Projekt się zmienił.

Niewłaściwa rozmowa

Rozmowa o produktywności AI niemal w całości dotyczy możliwości modeli. Który model jest najszybszy. Który model pisze najlepszy kod. Który model obsługuje najdłuższy kontekst. Domniemane założenie jest takie, że zmienną jest model: zaktualizuj model, popraw wynik.

To założenie jest błędne w przypadku długotrwałych projektów. W projekcie, nad którym pracuję od sześciu miesięcy i który liczy ponad 500 sesji agenta, model odpowiada może za 30% jakości sesji. Pozostałe 70% pochodzi z zakumulowanej infrastruktury projektu: dokumentów konwencji, pamięci decyzji, artefaktów przekazania, hooków behawioralnych, skodyfikowanych umiejętności i pokrycia testami.

Lepszy model w pustym projekcie daje lepsze wyniki niż gorszy model w pustym projekcie. Gorszy model w projekcie z 500 sesjami zakumulowanego kontekstu często daje lepsze wyniki niż lepszy model w pustym projekcie. Infrastruktura dominuje nad modelem. Dlatego właśnie kontekst to architektura – zakumulowana wiedza projektowa nie jest informacją uzupełniającą, lecz strukturą nośną.

Dowody

Naprawa wydajności strony rynku ilustruje tę kwestię. Jedno zdanie: „napraw wydajność strony rynku”. Agent:

Przeczytał dokument przekazania z poprzedniej sesji, w którym zdiagnozowano wąskie gardło
Zidentyfikował właściwą ścieżkę kodu (market_hub(), nie _fetch_market_data())
Zaimplementował paginowane zapytanie do bazy danych z agregującym RPC
Napisał testy
Wdrożył

Austin przeszedł z 14 sekund na 108 milisekund. 132-krotne ulepszenie z pojedynczego polecenia.¹

Nie stało się to dlatego, że model jest mądry. Stało się, ponieważ istniał dokument przekazania. Przekazanie zachowało diagnozę, która przetrwała trzy korekty z code review i dwie zmiany priorytetów w ciągu czterech dni. Bez przekazania agent zacząłby od zera. Zbadałby niewłaściwą ścieżkę kodu (tak jak zrobiła to pierwsza wersja przekazania). Zaproponowałby niepotrzebne partiale HTMX (tak jak pierwotny plan). Przekazanie zawierało już popełnione i poprawione błędy. Agent odziedziczył skorygowane rozumienie.

Wkładem modelu było przeczytanie przekazania i wdrożenie poprawki. Wkładem infrastruktury było posiadanie właściwego przekazania do przeczytania.

Co się zmienia, a co nie

Między sesją 1 a sesją 500 w tym samym projekcie dokładnie jedna rzecz pozostaje stała: model. Wszystko inne się zmienia.

Co się zmienia:

CLAUDE.md rośnie od pustego do kompletnego. Pytania o konwencje znikają. Wpis AGENTS.md patterns opisuje konkretne wzorce, które sprawiają, że pliki te są skuteczne.
Pliki pamięci akumulują się. Decyzje są buforowane. Kompromisy są rejestrowane. Projekt przestaje ponownie rozstrzygać rozstrzygnięte kwestie.
Hooki akumulują się. Każdy z nich zapobiega klasie awarii, która wystąpiła w poprzedniej sesji. 84 hooki przechwytujące 15 z 26 typów zdarzeń cyklu życia, które ujawnia Claude Code, każdy jest blizną po wcześniejszym incydencie.
Umiejętności akumulują się. Powtarzalne przepływy pracy stają się operacjami jednego polecenia. Nightcheck, którego zaprojektowanie zajęło całą sesję, teraz wykonuje się w 2 minuty.
Testy akumulują się. Agent dokonuje odważniejszych zmian, ponieważ może je natychmiast zweryfikować.
Dokumenty przekazania akumulują się. Złożone dochodzenia trwają między granicami sesji.

Co pozostaje takie samo:

Model. Te same wagi. Te same możliwości. Ta sama tendencja do zbaczania z zadania, fantomowej weryfikacji wyników testów (zobacz the evidence gate) i proponowania niepotrzebnych abstrakcji.

Tryby awarii modelu są stałe. Zdolność infrastruktury do wychwytywania tych trybów awarii rośnie z każdą sesją. Sesja 500 jest lepsza od sesji 1 nie dlatego, że model się poprawił, ale dlatego, że infrastruktura nauczyła się kompensować stałe słabości modelu.

Perspektywa inwestycyjna

Jeśli model nie jest zmienną, to wybór modelu nie jest główną decyzją inwestycyjną. Główną inwestycją jest infrastruktura kontekstu.

Zespół, który wydaje 200 USD miesięcznie na Claude Max (który domyślnie uruchamia Opus 4.7) i intensywnie inwestuje w pliki CLAUDE.md, systemy pamięci, hooki, umiejętności i pokrycie testami, przewyższy zespół, który wydaje 200 USD miesięcznie na ten sam plan bez inwestycji w infrastrukturę. Koszt modelu jest identyczny. Jakość wyników się rozchodzi, ponieważ infrastruktura się rozchodzi.

Takie ujęcie zmienia pytanie o produktywność. Pytanie nie brzmi „jakiego modelu powinniśmy użyć?”. Pytanie brzmi „co zbudowaliśmy wokół modelu, co sprawia, że każda sesja jest lepsza od poprzedniej?”.

Organizacje, które — jak widzę — zmagają się z produktywnością AI, nie używają niewłaściwego modelu. One zaczynają każdą sesję od zera. Brak dokumentu konwencji. Brak systemu pamięci. Brak hooków. Brak umiejętności. Brak zakumulowanego kontekstu. Każda sesja jest sesją 1, niezależnie od tego, ile sesji było wcześniej.

Model się poprawi

Modele będą się dalej rozwijać. Claude Opus 4.7 był lepszy od Claude Opus 4.6, Opus 5 będzie jeszcze lepszy. Poprawa jest realna i wartościowa. Ale poprawa jest addytywna, nie multiplikatywna.

Model, który jest o 20% lepszy w generowaniu kodu, daje o 20% lepsze wyniki w pustym projekcie. Ten sam model z 500 sesjami zakumulowanego kontekstu daje wyniki, które są jakościowo inne, a nie tylko ilościowo lepsze. Infrastruktura kontekstu nie dodaje 20% do możliwości modelu. Dostarcza diagnozę, ograniczenia, kryteria weryfikacji i historię operacyjną, których model nie może wytworzyć samodzielnie, niezależnie od tego, jak jest zdolny.

Żaden model, niezależnie od możliwości, nie może wiedzieć, że market_hub() ładuje wszystkie wiersze company_markets i paginuje w Python, jeśli coś mu tego nie powie. Dokument przekazania mu to mówi. Model czyta i działa. Inteligencja jest rozproszona między model (czytanie, rozumowanie, implementacja) a infrastrukturę (wiedza, ograniczanie, weryfikacja).

Sesja 500

Sesja 500 wygląda tak: w jednym zdaniu formułuję, czego chcę. Ralph agent architecture to system, który to umożliwia. Agent czyta CLAUDE.md i zna konwencje. Czyta pliki pamięci i zna decyzje. Czyta przekazanie i zna diagnozę. Natrafia na hooka, który zapobiega temu samemu błędowi, który inny agent popełnił trzy miesiące temu. Sprawdza swoją pracę względem zestawu testów. Raportuje ukończenie z dowodami dla każdego twierdzenia.

Sesja 1 wygląda tak: wyjaśniam schemat bazy danych, konwencje routingu, dziedziczenie szablonów, warstwę cache, pipeline wdrożeniowy i wzorce testowania. Agent zadaje pytania wyjaśniające. Proponuje podejście, które narusza trzy konwencje. Koryguję go. Wdraża poprawkę. Raportuje „testy przechodzą” bez uruchamiania pytest.

Model jest taki sam w obu sesjach. Projekt nie.

FAQ

Czy jakość modelu nadal ma znaczenie?

Tak. Silniejszy model czyta kontekst skuteczniej, dokładniej rozumuje o kompromisach i czyściej implementuje rozwiązania. Jakość modelu wyznacza dolny próg. Infrastruktura podnosi górny pułap. W dojrzałym projekcie pułap ma większe znaczenie niż dolny próg.

Czy dotyczy to tylko agentów kodujących?

Nie. Każdy przepływ pracy AI, w którym ta sama domena zadań powtarza się między sesjami, korzysta z zakumulowanego kontekstu. Pisanie, badania, analiza, obsługa klienta. Konkretna infrastruktura różni się (przewodniki stylu zamiast CLAUDE.md, bazy wiedzy zamiast hooków), ale dynamika jest taka sama: projekt staje się lepszy, ponieważ kontekst wokół modelu się akumuluje.

A co z modelami multimodalnymi lub modelami rozumującymi?

Ta sama zasada. Model rozumujący, który może myśleć przez 10 minut nad problemem, nadal musi wiedzieć, o jakim problemie ma myśleć. Dokument przekazania, plik konwencji i system pamięci dostarczają definicję problemu. Model zapewnia rozumowanie. Lepsze rozumowanie nad dobrze zdefiniowanym problemem daje lepsze wyniki niż gorsze rozumowanie, ale lepsze rozumowanie nad niezdefiniowanym problemem daje lepiej brzmiące zamieszanie.

Jak zacząć, jeśli nie mam żadnej infrastruktury kontekstu?

Napisać plik CLAUDE.md, który opisuje konwencje projektu. Ten pojedynczy plik to inwestycja o największym oddziaływaniu. Wszystko inne kumuluje się od tego miejsca.²

Źródła

Blake Crosley, “Compound Context: Why AI Projects Get Better the Longer You Stay With Them,” blakecrosley.com, marzec 2026. ↩
Anthropic, “Manage Claude’s memory,” Anthropic Documentation, 2026. ↩