Teza CLI

Trzy wątki na Hacker News w ciągu jednego tygodnia. 1638 punktów łącznie. Jeden wniosek: IDE jest dla ludzi. CLI jest dla agentów.¹²³

Podział na planowanie i wykonanie opisany przez Borisa Tane’a (716 punktów) działa w całości w terminalu.¹ Analiza „Making MCP Cheaper via CLI” (304 punkty) wykazała 94% redukcję tokenów po zastąpieniu wywołań narzędzi MCP poleceniem claude --print.³ Projekt just-bash zespołu Vercel (87 punktów) udowodnił, że usunięcie 80% narzędzi agenta przyspieszyło działanie, obniżyło koszty i zwiększyło niezawodność.⁴ Osobny benchmark wykazał, że podejście CLI zużywa 35 razy mniej tokenów niż MCP przy równoważnych zadaniach.¹⁰

Ten wzorzec pojawia się nieustannie, ponieważ architektura go wymusza. Agenty potrzebują kompozycyjności, skryptowalności i minimalnego narzutu. CLI zapewnia wszystkie trzy cechy. IDE nie zapewnia żadnej.

TL;DR

Architektura agentów oparta na CLI kosztuje o 94% mniej pod względem narzutu tokenów niż podejścia oparte na MCP, działa 3,5 razy szybciej i integruje się ze standardowymi narzędziami Unix. Podział na planowanie i wykonanie sprawdza się, ponieważ artefakty CLI to przenośne pliki markdown, a nie stan IDE. Remote Control umożliwia zdalny nadzór nad agentami CLI bez utraty przewagi kompozycyjności. Każdy poważny system agentowy zmierza ku terminalowi, ponieważ terminal to miejsce, w którym automatyzacja już funkcjonuje.

Podział na planowanie i wykonanie

Boris Tane udokumentował trzyetapowy przepływ pracy, który 454 komentujących na HN potwierdziło własnymi wariacjami: badanie, planowanie, implementacja.¹ Kluczowa obserwacja: nigdy nie pozwalać agentowi pisać kodu, dopóki nie przejrzy się i nie zatwierdzi pisemnego planu.

Przepływ pracy generuje artefakty markdown na każdym etapie. research.md zawiera analizę bazy kodu. plan.md zawiera strategię implementacji z fragmentami kodu. Programista przegląda w edytorze, dodaje adnotacje inline i odsyła opatrzony komentarzami plan z wyraźną instrukcją: „nie implementuj jeszcze”. Cykl adnotacji powtarza się od jednego do sześciu razy, zanim napisana zostanie choćby jedna linia kodu.

Cała pętla działa przez claude w terminalu. Bez wtyczki IDE. Bez wizualnego narzędzia porównywania. Pliki markdown na wejściu, pliki markdown na wyjściu. Artefakty przetrwają kompakcję okna kontekstowego, ponieważ istnieją jako pliki, a nie jako stan konwersacji.

Moja autonomiczna pętla implementuje ten sam podział w skali maszynowej. Plik PRD definiuje historie z kryteriami akceptacji. Dla każdej historii uruchamiany jest świeży agent, który otrzymuje briefing o aktualnym stanie git i osiągnięciach poprzednich agentów. Agent implementuje, niezależny weryfikator uruchamia testy (nigdy nie ufając samoocenie agenta), a trzech recenzentów kodu ocenia diff równolegle. Cała orkiestracja działa przez wywołania claude --print w skryptach bash. Bez frameworka, bez środowiska uruchomieniowego, bez serwera.

Podział na planowanie i wykonanie sprawdza się w terminalu, ponieważ terminal czyni ten podział strukturalnym. Planowanie generuje pliki. Wykonanie konsumuje pliki. Granica między dwiema fazami to plik na dysku — widoczny i audytowalny — a nie przejście stanu ukryte wewnątrz wtyczki IDE.

Dlaczego CLI wygrywa z IDE dla agentów

Argumentacja opiera się na trzech filarach: kosztach, kompozycyjności i efektywności kontekstu.

Koszty: 94% redukcji tokenów

Kan Yilmaz zmierzył narzut tokenów MCP w porównaniu z CLI w czterech scenariuszach.³ Liczby mówią same za siebie:

MCP wstrzykuje schematy narzędzi do każdej konwersacji. Przy 84 narzędziach sam narzut schematów pochłania 15 540 tokenów, zanim agent wykona jakąkolwiek pracę. Wywołania CLI nie niosą narzutu schematów, ponieważ modele już rozumieją standardowe interfejsy wiersza poleceń.¹⁰ Jeden użytkownik udokumentował, że MCP_DOCKER zużywa 125 964 tokenów przy 135 narzędziach.¹⁴

Jannik Reinhard przeprowadził równoległy benchmark na zadaniu zgodności Intune: 145 000 tokenów przez MCP wobec 4 150 tokenów przez CLI przy równoważnym wyniku.¹⁰ Agent CLI miał 95% okna kontekstowego dostępnego na rozumowanie. Agent MCP wydał większość budżetu na definicje narzędzi.

Kompozycyjność: potoki Unix już działają

Zespół v0 firmy Vercel usunął 80% narzędzi swojego agenta i zastąpił je pojedynczym środowiskiem bash.⁹ Wyniki:

Andrew Qu wyjaśnił uzasadnienie: „Rozwiązywaliśmy problemy, z którymi model radził sobie samodzielnie.” Systemy plików, grep, potoki i przekierowania już się komponują. Modele je rozumieją. Budowanie niestandardowych narzędzi MCP dla operacji, które cat | grep | jq obsługuje natywnie, dodaje narzut bez dodawania możliwości.¹³

Własna dokumentacja Anthropic potwierdza ten wzorzec. Claude Code podąża za filozofią Unix: przekazywanie logów potokiem, uruchamianie w CI, łączenie z innymi narzędziami.⁵ Tryb bezobsługowy (claude -p) obsługuje strukturalne wyjście JSON, wymuszanie schematów i wznawianie sesji za pomocą przechwyconych identyfikatorów sesji. Anthropic pozycjonuje tryb bezobsługowy jako podstawową ścieżkę integracji dla CI/CD i przepływów skryptowych.⁵

Simon Willison ujmuje implikację następująco: pisanie kodu jest teraz tanie.⁶ Wniosek, którego nikt nie chce słyszeć, jest taki, że weryfikacja stała się teraz kosztowną częścią. Agenty CLI integrują się z istniejącą infrastrukturą weryfikacyjną. Narzędzia do uruchamiania testów, lintery, narzędzia do sprawdzania typów, skanery bezpieczeństwa, potoki wdrożeniowe — wszystko to narzędzia wiersza poleceń. Agent IDE potrzebuje wtyczki do każdego z nich. Agent CLI po prostu je potokuje.

Efektywność kontekstu: rozumowanie nad sygnałem, nie nad szumem

Okno kontekstowe jest skończone. Każdy token wydany na schematy narzędzi, historię konwersacji i narzut MCP to token niedostępny dla rozumowania. Architektura CLI utrzymuje budżet kontekstu z natury szczupłym.

Świeże wywołanie claude --print otrzymuje skupiony prompt (~2 tys. tokenów) zamiast dziedziczenia pełnego kontekstu konwersacji (~100 tys.+ tokenów). Każda operacja zaczyna od zera. Brak skumulowanego stanu. Brak przestarzałych definicji narzędzi. Brak dryftu konwersacyjnego.

Moja infrastruktura uruchamia 84 hooki w ramach 17 zdarzeń cyklu życia, wszystkie orkiestrowane przez wywołania CLI. Każdy uruchomiony agent otrzymuje briefing: aktualny stan git, podsumowanie osiągnięć poprzednich agentów i kryteria akceptacji dla jednego zadania. Briefing zamiast pamięci. Modele lepiej wykonują jasny briefing niż nawigują przez 30 kroków skumulowanego kontekstu.

Akademicka analiza filozofii Unix w systemach agentowych sformalizowała tę zasadę: zredukowanie różnorodnych interfejsów do jednolitej abstrakcji, akceptując pewną utratę specjalizacji w zamian za kompozycyjność i sterowalność.¹¹ Abstrakcje oparte na plikach i specyfikacje oparte na kodzie zmniejszają obciążenie poznawcze i inżynieryjne. Agenty CLI dziedziczą 50 lat tej pracy projektowej.

Remote Control zmienia reguły gry

Oczywisty zarzut wobec agentów opartych na CLI: traci się wizualną informację zwrotną IDE. Anthropic dostarczyło odpowiedź 25 lutego 2026 roku. Remote Control łączy 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.

Remote Control nie przenosi niczego do chmury. Agent nadal działa lokalnie. Sesja terminala rejestruje się w API Anthropic przez TLS i odpytuje o zadania. Cały ruch przechodzi przez wychodzące HTTPS. Żadne porty przychodzące nie są otwarte.²

Funkcja rozwiązuje lukę w nadzorze. Przed Remote Control agenty CLI miały dwa tryby: nadzorowany (siedzieć przy terminalu) lub nienadzorowany (odejść i mieć nadzieję). Remote Control tworzy trzeci: asynchroniczne zarządzanie. Prośby o zatwierdzenie trafiają na telefon. Można zatwierdzić, odrzucić lub przekierować z dowolnego miejsca.

Mój system hooków klasyfikuje operacje według promienia rażenia. Operacje lokalne (zapis plików, uruchamianie testów) zatwierdzają się automatycznie. Operacje współdzielone (commity git) ostrzegają. Operacje zewnętrzne (pushe, wdrożenia) przekazują do recenzji ludzkiej. Remote Control zamienia tę ścieżkę „przekaż” z blokującego oczekiwania w asynchroniczne powiadomienie. Agent kontynuuje pracę nad kolejną historią, podczas gdy ja recenzuję poprzednią z telefonu.

IDE staje się warstwą wyświetlania, a nie środowiskiem wykonawczym. Postęp monitoruje się przez Remote Control. Interweniuje się, gdy bramki jakości sygnalizują problem. Agent CLI wykonuje pracę. IDE pokazuje wynik.

Wzorzec agenta Bash

just-bash od Vercel to symulowane środowisko bash z wirtualnym systemem plików w pamięci, zbudowane specjalnie dla agentów AI.⁴ Projekt kodyfikuje trzy przekonania dotyczące architektury agentów:

Izolacja zamiast sandboxingu. Każde wywołanie działa w izolacji. Zmienne środowiskowe, funkcje i katalog roboczy resetują się między wywołaniami. System plików jest trwały. Leniwe ładowanie plików oznacza, że pliki wczytują się przy pierwszym odczycie i są buforowane — nigdy nie wczytują plików, które agent zapisał przed odczytaniem. Agent nie może zanieczyścić własnego środowiska między operacjami.

Istniejące narzędzia zamiast niestandardowych. Grep ma 50 lat i robi dokładnie to, co replikują niestandardowe narzędzia wyszukiwania MCP. jq parsuje JSON. curl pobiera adresy URL. Model zna te interfejsy z danych treningowych. Niestandardowe narzędzia wymagają wstrzyknięcia schematów i dokumentacji. Standardowe narzędzia nie wymagają ani jednego, ani drugiego.

Minimalna architektura zamiast architektura frameworkowej. Andrew Qu uchwycił tę zasadę: „Modele stają się coraz inteligentniejsze, a okna kontekstowe coraz większe, więc może najlepsza architektura agenta to prawie żadna architektura.”¹³

Mój harness waliduje ten wzorzec w skali produkcyjnej. Około 15 000 linii bash orkiestrujących Claude Code. 84 hooki w 17 typach zdarzeń. Dispatchery, bramki jakości, integracja wyszukiwania semantycznego, autonomiczne pętle. Bez środowiska uruchomieniowego Python, bez zależności od frameworka. Ostre krawędzie basha (brak natywnego JSON, brak asynchroniczności, brak właściwych struktur danych) są realne, ale rozwiązywalne. jq obsługuje JSON. Przetwarzanie sekwencyjne jest w istocie zaletą: bramki powinny działać w kolejności, a nie współzawodniczyć.

Wzorzec działa, ponieważ orkiestracja agentów sprowadza się zasadniczo do czytania stdin, podejmowania decyzji i pisania na stdout. Ten opis odpowiada dokładnie celowi projektowemu basha. Wszystko bardziej złożone wskazuje, że dekompozycja zadania była błędna, a nie narzędzia.

Koszt jako decyzja architektoniczna

Decyzje kosztowe kumulują się. Wybór CLI zamiast MCP dla operacji bezstanowych oszczędza 94% na jedno wywołanie.³ Przy 100 operacjach dziennie oszczędności sięgają 228$/miesiąc wyłącznie na narzucie definicji narzędzi.³ Oszczędności te uwalniają budżet na więcej operacji, co generuje kolejne oszczędności. Architektura finansuje sama siebie.

Trzy warstwy kosztowe kumulują się niezależnie:

Warstwa tokenów. Kompresja promptu systemowego. Używam ~3 500 tokenów promptu systemowego rozłożonego na plik CLAUDE.md i 8 plików reguł. Ograniczenia działają lepiej niż wyjaśnienia. „Odrzuć wywołania narzędzi pasujące do wrażliwych ścieżek” wykonuje tę samą pracę co 15-liniowe wyjaśnienie, dlaczego dane uwierzytelniające powinny pozostać chronione. Dokumentacja najlepszych praktyk Anthropic podkreśla ten sam punkt: wydajność okna kontekstowego spada w miarę jego zapełniania.⁷ Każdy zmarnowany token kosztuje podwójnie: raz jako bezpośrednie opłaty za API, drugi raz jako pogorszona jakość rozumowania.

Warstwa agentów. Świeże uruchomienia zamiast długich konwersacji. Każda historia w autonomicznym przebiegu otrzymuje nowego agenta z czystym oknem kontekstowym. Geoffrey Huntley udokumentował podobny wzorzec zwany „The Ralph Loop”, uruchamiający autonomiczny rozwój za 10,42$/godzinę na Sonnet.¹² Kontekst nigdy nie rozrasta się, ponieważ każdy agent zaczyna od zera. Trafienia w cache na prompcie systemowym kosztują o 90% mniej (0,50$ vs 5,00$ za milion tokenów na Opus 4.6), więc powtarzany prompt systemowy przy świeżych uruchomieniach niesie minimalny narzut.⁸

Warstwa architektoniczna. CLI dla operacji bezstanowych, MCP dla stanowych. Wywołanie claude --print dla jednorazowej ewaluacji nie dodaje narzutu połączenia. MCP ma sens, gdy narzędzie potrzebuje trwałego stanu lub strumieniowania. Większość operacji agentów to jednorazowe ewaluacje, klasyfikacje lub zadania generowania kodu. CLI obsługuje je wszystkie przy niższym koszcie i prostszym debugowaniu.

Konkretny przykład z mojej autonomicznej pętli z zeszłego tygodnia: pięć historii PRD przetworzonych w nocy.¹⁵ Każda historia uruchamiała świeżego agenta (~2 tys. tokenów briefingu), przeprowadzała implementację (~15 tys. tokenów średnio), a następnie uruchamiała trzech agentów recenzujących (~2 tys. tokenów każdy). Łącznie na historię: ~23 tys. tokenów. Ten sam przepływ pracy w długotrwałej konwersacji MCP niósłby ~100 tys.+ tokenów skumulowanego kontekstu na historię już przy trzeciej historii. Pięć historii przez CLI: ~115 tys. tokenów łącznie. Pięć historii przez konwersację MCP: ~500 tys.+ tokenów łącznie. Stosunek kosztów kumuluje się z każdą kolejną historią.

Kiedy MCP nadal wygrywa

Teza CLI nie jest argumentem przeciwko MCP w ogóle. MCP wygrywa w konkretnych scenariuszach, w których CLI zawodzi.

Stanowe serwery narzędzi. Przeglądarka baz danych utrzymująca pulę połączeń między wywołaniami korzysta z trwałego modelu serwera MCP. Ponowne łączenie przy każdym wywołaniu CLI dodaje opóźnienie i narzut uwierzytelniania. Jeśli narzędzie potrzebuje stanu między wywołaniami, MCP jest właściwym wyborem.

Walidacja strukturalna. Schematy narzędzi MCP wymuszają kontrakty wejścia/wyjścia. Wywołanie CLI akceptuje dowolny tekst. Gdy agent musi dostarczyć strukturalne dane wejściowe zgodne z precyzyjnym schematem (format klucza API, zakresy dat, opcje wyliczeniowe), schemat MCP przechwytuje nieprawidłowe dane wejściowe, zanim narzędzie je przetworzy. Walidacja CLI wymaga, by samo narzędzie lub skrypt opakowujący wymuszały ograniczenia.

Kontrola dostępu w środowiskach wielodostępnych. Serwery MCP mogą centralnie wymuszać uprawnienia per użytkownik. Narzędzia CLI dziedziczą uprawnienia użytkownika systemu operacyjnego. W środowiskach zespołowych, gdzie różni agenci potrzebują różnych poziomów dostępu, MCP zapewnia bardziej szczegółową autoryzację.

Odpowiedzi strumieniowe. Długotrwałe operacje generujące przyrostowe wyjście (śledzenie logów, postęp budowania, eksport bazy danych) działają lepiej przez protokół strumieniowania MCP niż przez wywołanie CLI, które blokuje do zakończenia.

Reguła decyzyjna: jeśli operacja jest bezstanowa i jednorazowa — użyj CLI. Jeśli wymaga trwałego stanu, strukturalnych kontraktów lub strumieniowania — użyj MCP. W moim harnessie około 90% operacji jest bezstanowych. Te 10%, które potrzebują MCP, naprawdę z tego korzysta. Optymalizacja tych 90% przynosi największy zwrot.

Co można zbudować już dziś

Trzy wzorce, każdy możliwy do zbudowania w jedno popołudnie, każdy wzmacniający pozostałe.

Wzorzec 1: Podział na planowanie i wykonanie

# Plan phase: research and plan, no implementation
claude -p "Research the codebase and write research.md" \
  --allowedTools "Read,Glob,Grep,Write"

# Review: read annotations in research.md, write plan.md
claude -p "Read my annotations in research.md and write plan.md" \
  --allowedTools "Read,Write"

# Implement: follow the approved plan
claude -p "Implement the plan in plan.md" \
  --allowedTools "Read,Write,Edit,Bash"

Każda faza otrzymuje ograniczone uprawnienia narzędzi. Agent planujący nie może edytować kodu. Agent implementujący nie może przeglądać sieci. Granice plików wymuszają podział. Flaga --allowedTools realizuje to na poziomie CLI. Bez pliku konfiguracyjnego. Bez ustawień wtyczki. Jedna flaga na wywołanie, ograniczona dokładnie do uprawnień wymaganych przez daną fazę.

Cykl adnotacji jest kluczowym wyróżnikiem od „po prostu lepszego promptowania”. Przegląda się plan w edytorze. Skreśla się części, z którymi się nie zgadza. Dodaje się notatki na marginesach. Agent czyta opatrzony komentarzami plik i go poprawia. Plan staje się lepszy z każdym przejściem, ponieważ dwie różne inteligencje (ludzka wiedza dziedzinowa, generowanie kodu przez model) zbiegają się na tym samym dokumencie.

Wzorzec 2: Świeże uruchomienie na każde zadanie

for story in $(jq -r '.stories[].id' prd.json); do
  # Each story gets fresh context with a focused briefing
  criteria=$(jq -r ".stories[] | select(.id==\"$story\")" prd.json)
  state=$(git diff --stat HEAD~1)
  briefing="Git state: $state --- Story: $criteria"

  claude -p "Implement: $briefing" \
    --output-format json \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    | jq -r '.result'

  # Independent verification: never trust self-report
  python -m pytest -v
done

Brak skumulowanego kontekstu. Brak dryftu konwersacyjnego. Każdy agent otrzymuje czyste okno ze skupionym briefingiem. Flaga --output-format json przechwytuje strukturalne wyjście wraz z identyfikatorami sesji, umożliwiając deterministyczne wznowienie konwersacji, jeśli historia wymaga kontynuacji.

Krok niezależnej weryfikacji ma większe znaczenie niż krok implementacji. Agenty wykazują to, co nazywam Phantom Verification: twierdzą, że testy przeszły, bez ich uruchamiania. Uruchomienie pytest poza oknem kontekstowym agenta eliminuje ten tryb awarii całkowicie. Agent nie może fałszywie przedstawiać wyników, których nigdy nie wygenerował.

Wzorzec 3: Równoległy potok recenzji

diff=$(git diff HEAD~1)

# Three reviewers with independent context
claude -p "Review for bugs: $diff" --output-format json > /tmp/correctness.json &
claude -p "Review for vulnerabilities: $diff" --output-format json > /tmp/security.json &
claude -p "Review for style issues: $diff" --output-format json > /tmp/conventions.json &
wait

# Merge findings from all three
jq -s 'map(.result)' /tmp/correctness.json /tmp/security.json /tmp/conventions.json

Trzech agentów. Trzy perspektywy. Zero współdzielonego stanu. Rozbieżności między recenzentami ujawniają dokładnie te problemy, które pojedynczy recenzent pomija. Operator & i wbudowane polecenie wait obsługują równoległość. Bez środowiska uruchomieniowego async. Bez puli wątków. Bez frameworka orkiestracji. Kontrola zadań w bashu wykonuje tę pracę.

Siła tego wzorca: każdy recenzent otrzymuje pełne okno kontekstowe dla jednego zagadnienia. Pojedynczy recenzent dzielący uwagę między poprawność, bezpieczeństwo i styl radzi sobie gorzej niż trzech specjalistów z dedykowanym kontekstem. CLI sprawia, że podział jest trywialny, ponieważ każde wywołanie to niezależny proces z niezależną pamięcią.

Kluczowe wnioski

Dla programistów budujących systemy agentowe: - Zacznij od claude -p dla wszystkich uruchomień agentów. Dodawaj MCP tylko wtedy, gdy wymagany jest trwały stan. - Ogranicz uprawnienia narzędzi na fazę. Agenty planujące czytają. Agenty implementujące piszą. Agenty recenzujące czytają diffy. - Planuj o 94% mniejszy budżet na narzut tokenów, wybierając CLI zamiast MCP dla operacji bezstanowych.³

Dla zespołów skalujących autonomiczne przepływy pracy: - Świeże uruchomienia agentów zapobiegają dryftu kontekstu i ograniczają koszty tokenów na operację. - Remote Control zamienia „nienadzorowane” w „asynchronicznie nadzorowane” bez zmiany architektury CLI.² - Dane Vercel dowodzą kontraintuicyjnego wyniku: mniej narzędzi oznacza wyższy wskaźnik sukcesu, nie niższy.⁴

Dla architektów wybierających infrastrukturę agentową: - Agenty CLI integrują się z istniejącymi narzędziami CI/CD, testowania i wdrażania. Bez dodatkowej pracy integracyjnej. - Filozofia Unix (komponowanie małych narzędzi przez potoki) poprzedza i przewyższa każdy framework specyficzny dla agentów.¹¹ - Mur produktywności 10% przełamuje się, gdy przestanie się traktować agenta jako narzędzie czatu i zacznie traktować go jako infrastrukturę.

Część serii AI Engineering. Zobacz także: Claude Code jako infrastruktura, Anatomia pazura, Autonomiczna pętla i Mur 10%.