Claude Code jako infrastruktura

Andrej Karpathy ukuł termin na to, co narasta wokół agenta LLM: pazury (claws). Hooki, skrypty i orkiestracja, które pozwalają agentowi chwycić świat poza jego oknem kontekstowym.¹ Większość ludzi traktuje Claude Code jak czat z dostępem do plików. Wpisują prompt, patrzą jak edytuje plik i idą dalej. To ujęcie pomija to, czym narzędzie faktycznie jest.

Claude Code to nie funkcja IDE. To infrastruktura. A przepaść między traktowaniem go jako jednego lub drugiego decyduje o tym, czy rozwój wspomagany przez AI zatrzyma się na 10% wzrostu produktywności, czy przebije się do czegoś zasadniczo odmiennego.

TL;DR

Claude Code udostępnia 17 zdarzeń cyklu życia, z których każde można podpiąć za pomocą skryptów powłoki uruchamianych przed, w trakcie lub po każdym wywołaniu narzędzia.² Złożenie hooków w dispatchery, dispatcherów w umiejętności, umiejętności w agentów, agentów w przepływy pracy daje programowalną warstwę między użytkownikiem a modelem, która wymusza ograniczenia, których model nie może pominąć. Zbudowałem 84 hooki, 48 umiejętności, 19 agentów i ~15 000 linii orkiestracji w ciągu dwóch miesięcy. Zero frameworków. Zero zewnętrznych zależności. Wyłącznie bash i JSON. Rezultatem jest autonomiczny system rozwoju oprogramowania, który pisze, recenzuje i wdraża kod, gdy śpię. Ten post wyjaśnia architekturę, dlaczego ujęcie IDE hamuje ludzi i co zmienia się teraz, gdy Remote Control sprawia, że ta infrastruktura jest dostępna z dowolnego miejsca.

Ujęcie IDE jest błędne

Domyślny model mentalny: Claude Code to inteligentniejsze autouzupełnianie. Użytkownik siedzi przy terminalu, zleca zadania i nadzoruje wynik. Ten model ogranicza produktywność do tego, co można osobiście skontrolować.

Model infrastrukturalny: Claude Code to programowalne środowisko uruchomieniowe z jądrem LLM. Każda akcja modelu przechodzi przez hooki, które kontroluje użytkownik. Definiuje się polityki, nie prompty. Model działa w ramach infrastruktury tak samo, jak serwer webowy działa w ramach reguł nginx. Nikt nie siada przy nginx i nie wpisuje żądań ręcznie. Konfiguruje się go, wdraża i monitoruje.

To rozróżnienie ma znaczenie, ponieważ infrastruktura się kumuluje. Hook blokujący dane uwierzytelniające w poleceniach bash chroni każdą sesję, każdego agenta, każde autonomiczne uruchomienie. Umiejętność kodująca rubrykę ewaluacji bloga stosuje się konsekwentnie, niezależnie od tego, czy wywołuje ją użytkownik, czy agent. Agent recenzujący kod pod kątem bezpieczeństwa przeprowadza te same kontrole bez względu na to, czy ktoś patrzy.

Simon Willison ujmuje obecny moment jedną obserwacją: pisanie kodu jest teraz tanie.³ Słusznie. Ale wniosek, którego nikt nie chce usłyszeć, jest taki, że weryfikacja jest teraz tą kosztowną częścią. Tani kod bez infrastruktury weryfikacyjnej produkuje błędy na skalę. Inwestycja, która się zwraca, to nie lepszy prompt. To system wokół modelu, który wyłapuje to, co model przeoczy.

Warstwa infrastruktury

System hooków Claude Code uruchamia polecenia powłoki przy 17 zdarzeniach cyklu życia.² PreToolUse uruchamia się przed wykonaniem narzędzia i może je zablokować. PostToolUse uruchamia się po i może dostarczyć informację zwrotną. UserPromptSubmit uruchamia się po wpisaniu tekstu i może wstrzyknąć kontekst. Stop uruchamia się, gdy model próbuje zakończyć pracę i może wymusić kontynuację. Każde zdarzenie otrzymuje JSON na stdin z pełnym kontekstem: identyfikator sesji, nazwa narzędzia, dane wejściowe narzędzia, bieżący katalog roboczy.

System hooków to nie system wtyczek. To architektura sterowana zdarzeniami. Różnica: wtyczki rozszerzają funkcje narzędzia. Zdarzenia pozwalają przechwytywać, modyfikować i kontrolować każdą akcję narzędzia. Użytkownik staje się middleware.

Hooki: warstwa deterministyczna

Hooki to skrypty powłoki. Nie da się ich zhallucynować, przekonać pochlebstwami ani obejść wstrzyknięciem promptu. Model chce uruchomić rm -rf /? 10-liniowy skrypt bash sprawdza polecenie względem listy blokowanych i odrzuca je, zanim powłoka je zobaczy. Model próbuje odczytać .env? Wyrażenie regularne na ścieżce pliku przechwytuje wywołanie narzędzia Read. Nic z tego nie wymaga współpracy modelu. Hook uruchamia się niezależnie od tego, czy model tego chce.

Używam 84 hooków w 17 typach zdarzeń. Podział opowiada historię: 35 wymusza ocenę (bramki, strażnicy, walidatory), a 49 obsługuje automatyzację (injektory, loggery, trackery). Początkowo stosunek wynosił 1:6. Dwa miesiące awarii w autonomicznych przebiegach przesunęły go do 4:5. Każdy hook oceniający istnieje, ponieważ coś zawiodło bez niego. Agent zacommitował kod z komentarzami TODO. Agent uruchomił destrukcyjne polecenie git. Agent ujawnił ścieżkę do danych uwierzytelniających w pliku logu. Po każdej awarii pojawiła się bramka.

Najważniejsza lekcja: dispatchery zamiast niezależnych hooków. Miałem siedem hooków uruchamiających się na UserPromptSubmit, każdy czytający stdin niezależnie, dwa zapisujące do tego samego pliku stanu JSON. Równoczesne zapisy obcinały JSON. Każdy hook niżej w łańcuchu, który parsował ten plik, się psuł. Jeden dispatcher na zdarzenie, uruchamiający hooki sekwencyjnie z buforowanego stdin, rozwiązał problem. Niewidoczny narzut, 200 ms na prompt.

Umiejętności: warstwa wiedzy

Umiejętności to zestawy instrukcji w Markdown, które aktywują się na żądanie lub przez hooki.⁴ Każda koduje wiedzę domenową, z której model korzysta po wywołaniu. Moja umiejętność blog-evaluator definiuje ważoną rubrykę z 6 kategoriami, konkretnymi kryteriami oceny, minimami kategorii i współzależnościami. Moja umiejętność jiro koduje 7-krokową pętlę jakości z bramką dowodową wymagającą konkretnych dowodów dla każdego kryterium.

Umiejętności komponują się z hookami. Umiejętność może definiować własne hooki we frontmatter, które aktywują się tylko podczas jej działania. Umiejętności filozoficzne aktywują się automatycznie przez hooki SessionStart, wstrzykując ograniczenia jakościowe do każdej sesji bez jawnego wywołania.

48 umiejętności obejmujących: jakość kodu (jiro, testing-philosophy, debugging-philosophy), treść (blog-writer-core, blog-evaluator, citation-verifier), architekturę (fastapi, swiftui, database, htmx-alpine), operacje (deploy, cache, analytics, security) i meta-orkiestrację (deliberation, scan-intel, ralph). Badania preferencji samego Claude Code wykazały, że ciąży on ku określonym frameworkom i wzorcom.⁹ Umiejętności pozwalają nadpisać te domyślne ustawienia własnymi.

Agenci: warstwa delegowania

Agenci to wyspecjalizowani subagenci z izolowanymi oknami kontekstowymi.⁵ Każdy otrzymuje skoncentrowane zadanie i świeży kontekst. Mój system code review uruchamia trzech agentów równolegle: poprawność, bezpieczeństwo i konwencje. Każdy recenzuje niezależnie. Rozbieżności między recenzentami ujawniają dokładnie te problemy, które pojedynczy recenzent by przeoczył.

Kluczowe ograniczenie: zabezpieczenie przed rekurencją. Skrypt powłoki uruchamia się przed każdym wywołaniem narzędzia Task, sprawdza licznik głębokości zagnieżdżenia we współdzielonym pliku stanu i blokuje wywołanie, jeśli głębokość przekracza próg. Bez tego agenci delegują do agentów, którzy delegują do kolejnych agentów, z których każdy traci kontekst i spala tokeny. Domyślny limit to 3 poziomy. W praktyce użyteczna praca odbywa się na głębokości 1 (główny agent plus jeden subagent). Cokolwiek głębszego niż 2 zwykle oznacza, że dekompozycja zadania była błędna.

19 agentów obejmujących: rozwój (ios-developer, backend-architect), recenzję (code-reviewer, security-reviewer, conventions-reviewer, yagni-reviewer), eksplorację (project-scout, code-explorer, code-architect) i walidację (test-runner, correctness-reviewer).

Remote Control zmienia zasady gry

25 lutego 2026 roku Anthropic udostępnił Remote Control: możliwość połączenia się z lokalną sesją Claude Code z dowolnej przeglądarki lub aplikacji mobilnej Claude.⁶ Funkcja zdobyła 531 punktów i 313 komentarzy na Hacker News, w większości narzekania na błędy. Narzekania są uzasadnione. Funkcja wciąż jest przełomowa.

Oto dlaczego. Przed Remote Control infrastruktura, którą opisałem, miała dwa tryby: nadzorowany (obserwuję terminal) lub nienadzorowany (odchodzę i mam nadzieję). Żaden nie jest idealny. Nadzorowany ogranicza przepustowość do mojej zdolności skupienia uwagi. Nienadzorowany ryzykuje, że model podejmie złe decyzje, których nikt nie wyłapie.

Remote Control tworzy trzeci tryb: asynchroniczny nadzór. Uruchamiam autonomiczne pętle, które przetwarzają PRD z wieloma historiami przez noc. Zapytania o zatwierdzenie zewnętrznych akcji (git push, wywołania API, cokolwiek co opuszcza maszynę) trafiają na mój telefon. Zatwierdzam, odrzucam lub przekierowuję z dowolnego miejsca. Warstwa nadzoru pozostaje taka sama. Opóźnienie między „agent potrzebuje zatwierdzenia” a „człowiek je udziela” spada z „kiedy sprawdzę laptopa” do „10 sekund z telefonu”.

Przepływ zatwierdzeń łączy się z klasyfikacją zasięgu rażenia z moich hooków. Operacje lokalne (zapis plików, uruchamianie testów) zatwierdzają się automatycznie. Operacje współdzielone (commity git) ostrzegają. Operacje zewnętrzne (push, wywołania API, wdrożenia) czekają na recenzję człowieka. Remote Control zamienia tę ścieżkę oczekiwania z blokującego postoju w asynchroniczne powiadomienie. Agent kontynuuje pracę nad następną historią, podczas gdy recenzuję poprzednią.

Narzędzia takie jak Agent Multiplexer już zarządzają sesjami Claude Code przez tmux.¹⁰ Alternatywy open-source takie jak Emdash zapewniają pełne agentowe środowiska programistyczne.¹¹ Osoby sugerujące SSH plus tmux jako alternatywę mają rację, że sprawdza się to dla dostępu terminalowego. Żadne z nich nie zapewnia routingu zatwierdzeń. To właśnie ten routing sprawia, że operacje bez nadzoru są bezpieczne, a nie tylko możliwe.

Koszt jako architektura

Post „Making MCP Cheaper via CLI” (304 punkty na HN) udokumentował wzorzec: opakowywanie wywołań narzędzi MCP w wywołania CLI, aby uniknąć narzutu utrzymywania połączenia z serwerem MCP.⁷ Szerszy wniosek jest taki, że koszt to decyzja architektoniczna, a nie późniejsza refleksja operacyjna.

Moja infrastruktura zarządza kosztami na trzech poziomach:

Poziom tokenów. Kompresja promptu systemowego. Używam ~3500 tokenów promptu systemowego rozłożonego na plik CLAUDE.md i 8 plików reguł. Najskuteczniejsze cięcia: usunięcie przykładów kodu z tutoriali (model zna API), scalanie zduplikowanych reguł między plikami i zastępowanie wyjaśnień ograniczeniami. „Odrzucaj wywołania narzędzi pasujące do wrażliwych ścieżek” robi to samo co 15-liniowe wyjaśnienie, dlaczego nie powinno się czytać danych uwierzytelniających. Gęstość semantyczna ponad surową kompresję.⁸

Poziom agentów. Świeże instancje zamiast długich konwersacji. Każda historia w autonomicznym przebiegu otrzymuje nowego agenta z czystym oknem kontekstowym. W momencie uruchomienia agent otrzymuje briefing: aktualny stan git, co osiągnęli poprzedni agenci, co ma zrobić. Briefing zamiast pamięci. Modele realizują jasny briefing lepiej niż nawigują przez 30 kroków skumulowanego kontekstu. Kontekst nigdy nie puchnie, ponieważ każdy agent zaczyna od zera. Geoffrey Huntley udokumentował podobny wzorzec w „The Ralph Loop”, prowadząc autonomiczny rozwój za 10,42 $/godzinę na Sonnet.¹³ Wieloagentowe orkiestratory takie jak OpenSwarm formalizują pipeline worker-reviewer z eskalacją modelu.¹⁴

Poziom architekturalny. CLI w pierwszej kolejności zamiast MCP, gdy operacja jest bezstanowa. Wywołanie claude --print do jednorazowej ewaluacji kosztuje mniej i nie dodaje narzutu połączenia. Serwer MCP ma sens, gdy narzędzie potrzebuje trwałego stanu lub streamingu. Context Mode zademonstrował odwrotne podejście: kompresję 315 KB danych wyjściowych MCP do 5,4 KB przy użyciu indeksowania FTS5 z rankingiem BM25.¹² Oba podejścia redukują zużycie tokenów, z różnych kierunków. Większość moich wywołań umiejętności to operacje jednorazowe. Moja analiza buforowania promptów wykazała, że Claude Code CLI domyślnie buforuje prompty systemowe powyżej 4096 tokenów. Bez potrzeby konfiguracji.

Studium przypadku: jak 84 hooki wyglądają w praktyce

Konkretny ślad sesji z autonomicznego przebiegu z zeszłego tygodnia, przetwarzającego PRD z 5 historiami:

1. Uruchamia się SessionStart. Dispatcher wstrzykuje: aktualną datę, detekcję projektu, ograniczenia filozoficzne, kontrolę wydajności systemu, inicjalizację śledzenia kosztów. Pięć hooków, łącznie 180 ms.

2. Agent czyta PRD, planuje pierwszą historię. UserPromptSubmit uruchamia się na wewnętrznym prompcie. Dispatcher wstrzykuje: kontekst aktywnego projektu, baseline dryfu sesji (embedding Model2Vec pierwszego promptu do późniejszych kontroli podobieństwa). 120 ms.

3. Agent wywołuje Bash, aby uruchomić testy. Uruchamia się PreToolUse:Bash. Dispatcher wykonuje: kontrolę danych uwierzytelniających (brak ścieżek .env w poleceniu), walidację sandboxa (polecenie nie jest na liście blokowanych), detekcję projektu. 90 ms. Testy się uruchamiają. Uruchamia się PostToolUse:Bash: logowanie pulsu aktywności, kontrola dryfu względem baseline (podobieństwo cosinusowe 0,63, znacznie powyżej progu 0,30).

4. Agent wywołuje Write, aby utworzyć plik. Uruchamia się PreToolUse:Write: kontrola zakresu pliku (czy ta ścieżka jest w katalogu projektu?). Uruchamia się PostToolUse:Write: kontrola lint zapisanego pliku, śledzenie commitów, puls aktywności.

5. Agent kończy historię. Uruchamia się Stop. Hook bramki jakości sprawdza: czy agent podał dowody dla każdego kryterium? Czy użył języka niepewności („should”, „probably”)? Czy w diffie są komentarze TODO? Jeśli jakakolwiek kontrola zawiedzie, hook zwraca exit 2 i agent kontynuuje pracę.

6. Niezależna weryfikacja: świeży agent uruchamia zestaw testów bez ufania samoocenie poprzedniego agenta.

7. Trzech agentów code review uruchamia się równolegle. Każdy recenzuje diff niezależnie. Wyniki się łączą. Jeśli którykolwiek recenzent oznaczy problem jako CRITICAL, historia wraca do kolejki.

8. Historia przechodzi. Ładuje się następna. Cykl powtarza się dla wszystkich 5 historii.

Łącznie hooków uruchomionych na 5 historii: ~340. Łączny czas w hookach: ~12 sekund. Niewidoczny narzut, który zapobiegł trzem wyciekom danych uwierzytelniających, jednemu destrukcyjnemu poleceniu i dwóm niekompletnym implementacjom w jednym nocnym przebiegu.

Kluczowe wnioski

Claude Code to środowisko uruchomieniowe, nie narzędzie. 17 zdarzeń cyklu życia czyni go programowalnym. Hooki, umiejętności i agenci to zestaw instrukcji. Model to silnik wykonawczy. Użytkownik to architekt systemów.

Nadzór skaluje się z automatyzacją. Każdy hook dodający ograniczenie redukuje ryzyko operacji bez nadzoru. Stosunek hooków oceniających do hooków automatyzujących to margines bezpieczeństwa. Mój wynosi 4:5 i rośnie.

Infrastruktura się kumuluje, prompty nie. Dobry prompt poprawia jedną interakcję. Dobry hook poprawia każdą interakcję. Dobra umiejętność poprawia każdego agenta, który ją wywołuje. Dobry agent poprawia każdy przepływ pracy, który do niego deleguje. Warto inwestować w warstwę, która mnoży.

Remote Control czyni infrastrukturę przenośną. Routing zatwierdzeń zamienia „nienadzorowane” w „asynchronicznie nadzorowane”. To rozróżnienie to różnica między nadzieją, że model podejmie dobre decyzje, a weryfikacją, że tak jest.

Koszt to architektura, nie optymalizacja. Świeże instancje agentów, priorytet CLI, kompresja promptu systemowego i buforowanie promptów to decyzje strukturalne, które się kumulują. Optymalizacja po fakcie kosztuje więcej niż projektowanie z myślą o kosztach.

Zero wymaganych frameworków. 84 hooki, 48 umiejętności, 19 agentów, ~15 000 linii orkiestracji. Skrypty bash w katalogu. Pliki stanu JSON. Brak zależności uruchomieniowych. Można zaadoptować jeden hook lub cały stos. Infrastruktura rośnie organicznie z rozwiązywania rzeczywistych problemów, nie z implementowania czyjegoś frameworka.

Ten artykuł jest częścią serii AI Engineering. Poprzednio: Why My AI Agent Has a Quality Philosophy. Zobacz także: Thinking With Ten Brains i The Blind Judge.