Dlaczego agenci programistyczni takie jak Claude Code potrzebują warstwy zarządzania, a nie lepszych promptów

Jasniejsze instrukcje rzeczywiście przynoszą lepsze odpowiedzi. Redukują nieporozumienia, precyzują polecenia i nadają jednej sesji wyraźny kierunek, przez co na chwilę wydaje się, że poprawiasz cały sposób pracy z AI. To wrażenie znika, gdy agenci stają się częścią codziennej pracy. Przestajesz prosić o jedną przekonującą odpowiedź na pojedynczą prośbę. Oczekujesz, że agent zna projekt, szanuje już podjęte decyzje, wybierze odpowiednią procedurę, działa w ramach swoich uprawnień, użyje odpowiednich narzędzi i pozostawi dowody, które możesz sprawdzić.

Instrukcja kształtuje wymianę informacji przed tobą. Nie może jednak kontrolować wszystkiego, co ją otacza.

Codex i Claude Code już zawierają wiele przydatnych elementów. Brakuje jednak kompletnego, przenośnego systemu, który decyduje, które zasady obowiązują, jaki kontekst ma znaczenie, co może robić agent programistyczny, jak przekierowywane są zadania oraz co stanowi dowód. Ktoś musi stworzyć tę warstwę wokół środowiska wykonawczego. Jedną z nazw dla niej jest jądro: warstwa zarządzania, którą sami kontrolujemy i która przenosi zadania od intencji człowieka aż po dowód. Nie zawiera żadnego modelu wewnętrznego i sama nic nie wykonuje.

W praktyce takie jądro może powstać jako zbiór przenośnych, ustrukturyzowanych plików Markdown: zasady, protokoły, indeksy, przyjęte decyzje, stan projektu oraz zasady zarządzania pamięcią. Gdy pisemne instrukcje nie wystarczają, lukę wypełniają umiejętności, skrypty, skróty i elementy powiązane.

Kontekst był tylko objawem

Pierwszym widocznym problemem jest utrata kontekstu. Nowa sesja często nie ma pojęcia o architekturze, ostatnich zmianach ani o uzasadnieniu danej zadania, więc przed wznowieniem użytecznej pracy konieczne jest przeprowadzenie kolejnej weryfikacji. Ta powtarzalność marnuje czas, zasoby oraz cierpliwość.

Oczywistym rozwiązaniem jest umieszczenie brakujących zasad i informacji tła w pliku AGENTS.md, CLAUDE.md lub podobnym pliku bootstrapowym. To rozsądne, ale niewystarczające. Te pliki rzeczywiście ułatwiają proces wprowadzania, ale oczekiwanie, że będą one regulować cały proces pracy, jest błędem. Plik bootstrapowy może zawierać stabilne zasady i wskazywać na wiarygodne źródła. Sam nie może jednak utrzymywać aktualnego stanu projektu, wybierać odpowiedniego kontekstu dla każdego zadania, decydować o tym, co agent może robić, ani sprawdzać wyników.

W centrum znajduje się jedna zasada: należy zdefiniować, co oznacza „zakończenie” przed wykonaniem, a następnie na końcu żądać dowodów.

Usunięcie powtórzeń nigdy nie było głównym celem. Sztuczna inteligencja przeszła od sporadycznych eksperymentów do codziennej nieodzowności, a interesujące pytanie brzmiało, ile wartości może wydobyć środowisko stworzone z zwykłą starannością w projektowaniu oprogramowania. Sztuczna inteligencja pojawiła się jednocześnie przez kilka drzwi – w edytorach, w Xcode i VS Code, a także w narzędziach takich jak Codex i Claude Code. Każde z nich ułatwiało korzystanie z zaawansowanych modeli, ale łatwiejszy dostęp w niczym nie pomagał w uporządkowaniu tego, co działo się wokół tej interakcji.

W dobry dzień agent może przejrzeć kod, wyjaśnić nieznany framework, zaproponować architekturę lub pomóc w wdrożeniu nowej funkcji, co może bardzo przypominać współpracę z innym programistą. Im bardziej na to polegasz, tym ważniejsze stają się otaczające to pytania. Gdy dwie źródła są sprzeczne, które zwycięża? Jakie zasady obowiązują w tym zadaniu? Czy agent może podejmować decyzje, czy tylko je rekomendować? Jeśli twierdzi, że praca jest zakończona, co powinno się pojawić?

Kontekst odpowiada na pierwszą część tego pytania, ponieważ dostarcza agentowi odpowiednich informacji. Reszta dotyczy sposobu wykorzystania tych informacji. Termin „zarządzanie” dobrze opisuje cały ten zbiór elementów: praktyczny związek pomiędzy intencją, wiarygodnymi informacjami, zasadami, autorytetem, realizacją i dowodem. Pozostaje on praktyczny, gdy kluczowe etapy procesu są na tyle jasne, by można je było sprawdzić, poprawić i ponownie wykorzystać.

Dla inżyniera, który lubi projektować systemy, w których poszczególne elementy współpracują efektywnie, improwizowanie procesu pracy z agentami wydaje się marnotrawstwem. Staje się to czymś, co trzeba zaprojektować, a nie serią rozmów, którymi trzeba się zajmować. Dobrze to zrobić oznacza długotrwałe obserwowanie własnych nawyków: czego sprawdzasz przed rozpoczęciem pracy nad projektem, jakie wzorce powtarzasz, kiedy zwalniasz tempo oraz jakie sprawdzenia naprawdę przekonują cię, że praca została wykonana. Celem jest przekształcenie tych nieujawnionych nawyków w zachowania, których może przestrzegać agent, a które może audytować człowiek.

Co potrafi, a czego nie potrafi bootstrap

Rozwijający się programista dołączający do już istniejącego projektu potrzebuje czegoś więcej niż tylko talentu. Musi nauczyć się, jak zorganizowany jest kod, jakie decyzje zostały podjęte, co zmieniło się ostatnio oraz gdzie leżą granice. Bez tego nawet doskonały kandydat spędza dni na ponownym poznawaniu środowiska.

Sesje agentów borykają się z skróconą wersją tego samego problemu. Wyjaśniasz architekturę, cele, obecną sytuację oraz ograniczenia, agent wykonuje dobrą pracę, a w następnej sesji konieczne jest ponowne stworzenie dużej części tej informacji.

Umieszczenie tego materiału w pliku AGENTS.md lub CLAUDE.md znacznie obniża koszty wdrożenia. Słowo „bootstrap” służy jako granica i nie jest skargą – dobry dokument określa minimalną umowę operacyjną oraz wskazuje agentowi, gdzie znajdują się wiarygodne informacje. Dokumenty Codex zawierają warstwowe pliki AGENTS.md, których łączna wielkość jest ograniczona, a Claude Code proponuje krótkie instrukcje projektowe, przy czym rzadko potrzebne procedury są wyodrębniane jako umiejętności. Oba te aspekty są omówione w dokumentacji dostawców: w przewodniku Claude Code Memory oraz w dokumencie Codex AGENTS.md. Umiejętność pakuje procedurę, którą można powtarzać, dzięki czemu może być używana w różnych projektach, a „hooks” mogą wymuszać określone zachowanie za każdym razem. Mimo to jakaś inna część systemu musi decydować, kiedy każdy z tych mechanizmów ma zastosowanie oraz jak sprawdzać jego wyniki.

Problemy pojawiają się wtedy, gdy oczekuje się, że jeden plik będzie zawierał całe środowisko pracy. Nie może on być krótki i jednocześnie mieścić w sobie każdą decyzję architektoniczną, aktualny plan, poprzednie raporty, protokoły oraz szczegóły zadań. A nawet gdyby okno kontekstowe mogło pomieścić wszystko, wypełnianie go podczas każdej sesji przyniosłoby własne problemy: istotne instrukcje musiałyby konkurować z przestarzałym lub niepowiązanym tekstem. Naprawa błędu wymaga innego kontekstu niż analiza architektury. Wypuszczenie produktu odbywa się inaczej niż podczas wczesnego spotkania dotyczącego produktu, a szybka pytanie nie powinno generować takich kosztów koordynacji jak rozwój dużego funkcjonalności.

Dlatego bootstrap powinien zapewnić dostęp do systemu, a nie próbować być samym systemem.

Od bootstrapu do mapy

W tym projekcie bootstrap zawiera krótki kontrakt operacyjny, a następnie wskazuje na poszczególne źródła w momencie, gdy stają się istotne. Przyjęte decyzje pozostają przy projekcie. Protokoły opisują powtarzające się rodzaje zadań, umiejętności obejmują procedury, które można wykonać wielokrotnie, skróty kompresują częste żądania, a aktualne plany przechowują informacje, których może potrzebować kolejna sesja.

W jądrze nie kryje się nic inteligentnego. Jego wartość wynika z sposobu, w jaki pliki są rozdzielane, łączone, wybierane i utrzymywane pomiędzy sesjami oraz w różnych okresach działania.

Rozdzielenie to chroni również znaczenie informacji. Przyjęta decyzja określa, w jaki sposób rozwija się projekt, raport stanu opisuje konkretny moment, a wynik testu rejestruje dowody. Jeśli połączy się te trzy elementy w jedną nierozróżnioną pamięć, stara obserwacja zaczyna przypominać aktualną instrukcję.

W miarę rozwoju tej struktury obejmuje ona politykę zarządzania pamięcią, złożoność zadań, ilość wysiłku poznawczego potrzebnego do ich wykonania oraz wybór odpowiedniego modelu, szybkie sposoby działania, ciągłość między sesjami, a także weryfikację i koordynację pomiędzy kilkoma agentami. Pełny spis takich elementów ukryłby istotę architektury. Ważne jest, aby agent mógł je odkrywać stopniowo, w zależności od wymagań zadania. Za tą „mapą” kryją się cztery obowiązki, które nie opisują wszystkich mechanizmów, ale wyjaśniają, dlaczego należą one do siebie.

Część wiedzy musi przetrwać po zakończeniu rozmowy

Chat funkcjonuje podczas realizacji zadania, ale nie powinien stanowić oficjalnego zapisu decyzji projektowych. Zaakceptowana architektura, ograniczenia oraz wybory kodowe powinny znajdować się w kontrolowanych źródłach, które mogą być odczytywane podczas późniejszych sesji, a bieżące plany wymagają własnego stanu, który można wznowić. Utrzymanie trwałej prawdy nie jest tym samym co archiwizowanie każdej rozmowy, ponieważ większość z nich stanowi tymczasowe narzędzia pomocnicze. Lepiej zapytać, co nadal powinno być uznawane za autorytatywne po zakończeniu sesji.

Ładuj to, czego potrzebuje zadanie

Agent musi mieć wystarczająco dużo informacji, by zrozumieć swoje zadanie, a nie wszystko, co system kiedykolwiek przechowywał. Mała zmiana w kodzie może wymagać zasad projektu oraz kilku plików. Złożona funkcjonalność może natomiast potrzebować celu produktu, decyzji architektonicznych, opinii specjalistów oraz planu weryfikacji. Celem jest minimalny, wystarczający kontekst, a nie maksymalny dostępny kontekst. Ciągłość oznacza możliwość znalezienia odpowiednich informacji we właściwym momencie, a nie przenoszenie całej historii do każdego zadania.

Znalezienie czegoś to nie upoważnienie

Znalezienie pliku, wiadomości lub rekomendacji nie upoważnia do podjęcia wobec nich działań. System musi oddzielić informacje od uprawnień, szczególnie w przypadku działań destruktywnych, ostatecznej weryfikacji, publikacji oraz wszystkiego, co dotyczy świata poza przestrzenią roboczą. Warstwa ta jest mniej widoczna niż inteligencja modelu, ale ma znaczenie za każdym razem, gdy błąd popełniony z przekonaniem kosztuje więcej niż chwila zastanowienia przed podjęciem decyzji.

Dopełnienie wymaga dowodu

Biegłość w mówieniu nie oznacza poprawności, a wiarygodność nie oznacza ukończenia pracy. Dlatego jądro systemu pyta, co należy zweryfikować, jakie dowody należy zachować oraz gdzie zapisany ma być potwierdzony stan. Jeśli agent edytuje kod i zgłasza „gotowe”, otrzymujesz jedynie takie stwierdzenie, nic więcej. Weryfikacja może polegać na pozytywnych testach, udanym skompilowaniu, zachowaniu widocznym w działającej aplikacji oraz zapisanym stanie. Inne obszary wymagają innych dowodów, ale zasada pozostaje ta sama: zakończenie rozmowy nie oznacza zakończenia pracy.

Organizacja jako analogia

Wyobraź sobie firmę, która posiada budynek, komputery i doskonałe wyposażenie, ale nie ma wspólnego sposobu pracy. Ma potencjał, jednak nie jest spójna. Ludzie nadal potrzebują wspólnej wiedzy, procedur, uprawnień do podejmowania decyzji, jasnych obowiązków oraz kontroli jakości. To porównanie jest uproszczone, ponieważ agent to nie pracownik, a środowisko wykonawcze robi więcej niż tylko umieszcza ludzi przy biurkach. Pokazuje ono jednak, jak ze sobą współgrają poszczególne elementy: agenci pełnią określone role, narzędzia stanowią wyposażenie, a środowisko wykonawcze to miejsce, gdzie realizowane są zadania. Jądro to wspólna warstwa reguł, wiedzy, metod i kontrol, która umożliwia im współpracę. Lepsze modele nie automatycznie tworzą lepszego systemu.

Gdzie znajduje się ta warstwa

Jądro nie konkuruje z Codexem, Claude Code, Geminiem ani żadnym innym środowiskiem wykonawczym, które może się pojawić w przyszłości. To one dostarczają środowisko w czasie rzeczywistym: modele, narzędzia, sesje, ustawienia rozumowania oraz coraz większą liczbę własnych podagentów, elementów łączących i umiejętności. Warstwa zarządzania działa w tym środowisku i rozstrzyga trzy kwestie: to, co powinno pozostać, co agent może robić oraz jakie dowody uznaje się za potwierdzenie wykonania zadania.

Wartość tego rozwiązania rośnie z każdym razem, gdy nowa wersja środowiska wykonawczego wprowadza funkcję przypominającą coś, co już zostało stworzone ręcznie. Ponowne budowanie każdej możliwości środowiska wykonawczego pochłaniałoby czas, który lepiej wykorzystać na projekty obsługiwane przez agenty. Pozwolenie środowiskom wykonawczym na obsługę wykonywania zadań, podczas gdy warstwa zarządzania pozostaje przenośna, to bardziej zrównoważona droga. Dostawcy różnią się modelami, narzędziami, interfejsami i stylem wyjścia, a przenośność zapewnia, że twoje zasady pozostaną niezależne od żadnego z nich, bez konieczności udawania, że te różnice zniknęły.

Zarządzanie nie gwarantuje pewności

Zapisanie zasady nie gwarantuje, że agent ją przeczyta, zrozumie lub zastosuje we właściwym czasie. Skrypt startowy może wskazywać na właściwy protokół, a mimo to zostać zignorowany. Decyzja kanoniczna może być idealnie zachowana, podczas gdy jej treść po cichu staje się przestarzała. Hook może wiernie egzekwować zasadę długo po tym, jak przestała być przydatna.

Doswiadczenie pokazuje, że rozwój jest szybki. Zasady dodawane dla drzew roboczych i haczyków zaczynają się nakładać, kolidować i blokować zadania, które miały chronić, dlatego trzeba je uproszczać i naprawiać. Zarządzanie wymaga ciągłej konserwacji, a koszty na tym się nie kończą: interfejsy i indeksy zużywają czas i zasoby, a nadal mogą nie odzwierciedlać najnowszego stanu; agenci pomijają instrukcje w miarę rozwoju systemu, a zaufanie trudno odbudować, gdy proces pracy zgłasza sukces bez oczekiwanych dowodów.

Taki system nigdy nie jest ukończony ani uniwersalny. To osobista konfiguracja, która jest testowana, psuta i korygowana przez miesiące. Poprawia ona Twoją zdolność do obserwowania i dostosowywania zachowania agentów, jednak żadna zasada, protokół, skrót ani mechanizm pamięci nie jest przestrzegany idealnie. Zarządzanie może ułatwić inspekcję i naprawę zachowań, ale nie może uczynić agenta probabilistycznego deterministycznym.

Trzy pytania, które należy zadać najpierw

Utrata kontekstu to to, co skłania ludzi na tę drogę. To, co utrzymuje ich tam, to większe pytanie inżynieryjne: jak powinien być zaprojektowany ścieżka wokół sprawnego modelu, przy takim samym uwzględnieniu jakiejkolwiek innej ważnej architektury?

Czy można więc udowodnić, że praca jest zakończona? Tylko wtedy, gdy „zakończenie” zostało zdefiniowane przed wykonaniem, a wynik zawiera dowody odpowiadające zadaniu. Bez tego to, co mamy, to jedynie twierdzenie, a twierdzenie nie jest dowodem.

Nie potrzeba takiego systemu, aby zacząć myśleć w ten sposób. Zanim dodasz kolejne polecenie lub plik, zapytaj:

1. Które źródła mogą określać, co jest prawdą?
2. Które decyzje i działania wymagają ludzkiej autorytetu?
3. Jakie dowody pokażą, że praca jest zakończona?

Te pytania przekształcają odrębne funkcje sztucznej inteligencji w elementy niezawodnego procesu pracy, zamiast w możliwości, które jedynie współistnieją. Nie każda mała prośba powinna ciągnąć za sobą cały system. Kontrole powinny być dostosowywane do konsekwencji: łagodne, gdy ryzyko jest niskie, bardziej restrykcyjne, gdy błąd mógłby mieć poważne skutki. Modele dostarczają możliwości, a ustalony szlak od intencji do dowodu to to, co buduje się wokół nich.