Die CLI-These

Drei Hacker-News-Threads in einer Woche. 1.638 Punkte insgesamt. Ein Ergebnis: Die IDE ist für Menschen. Das CLI ist für Agents.¹²³

Boris Tanes Planungs-/Ausführungs-Trennung (716 Punkte) läuft vollständig im Terminal.¹ Die Analyse „Making MCP Cheaper via CLI” (304 Punkte) ergab eine 94-prozentige Token-Reduktion durch den Ersatz von MCP-Tool-Aufrufen durch claude --print.³ Vercels just-bash-Projekt (87 Punkte) zeigte, dass das Entfernen von 80 % der Tools eines Agents alles schneller, günstiger und zuverlässiger machte.⁴ Ein separater Benchmark ergab, dass CLI-Ansätze 35-mal weniger Tokens verbrauchen als MCP bei gleichwertigen Aufgaben.¹⁰

Das Muster taucht immer wieder auf, weil die Architektur es erzwingt. Agents brauchen Komponierbarkeit, Skriptfähigkeit und minimalen Overhead. CLIs bieten alle drei. IDEs bieten nichts davon.

TL;DR

CLI-first-Agent-Architektur kostet 94 % weniger Token-Overhead als MCP-basierte Ansätze, läuft 3,5-mal schneller und lässt sich mit Standard-Unix-Tools komponieren. Die Planungs-/Ausführungs-Trennung funktioniert, weil CLI-Artefakte portierbare Markdown-Dateien sind, nicht IDE-Zustand. Remote Control macht CLI-Agents fernüberwachbar, ohne den Komponierbarkeitsvorteil zu opfern. Jedes ernsthafte Agent-System konvergiert auf das Terminal, weil das Terminal der Ort ist, an dem Automatisierung bereits lebt.

Die Planungs-/Ausführungs-Trennung

Boris Tane dokumentierte einen dreiphasigen Workflow, den 454 HN-Kommentatoren mit eigenen Variationen bestätigten: Recherche, Planung, Implementierung.¹ Die entscheidende Erkenntnis: Lassen Sie den Agent niemals Code schreiben, bevor Sie einen schriftlichen Plan überprüft und genehmigt haben.

Der Workflow produziert in jeder Phase Markdown-Artefakte. research.md erfasst die Codebase-Analyse. plan.md erfasst die Implementierungsstrategie mit Code-Snippets. Der Entwickler überprüft im Editor, fügt Inline-Annotationen hinzu und sendet den annotierten Plan mit einer expliziten Anweisung zurück: „Noch nicht implementieren.” Der Annotationszyklus wiederholt sich ein- bis sechsmal, bevor eine einzige Zeile Code geschrieben wird.

Die gesamte Schleife läuft über claude im Terminal. Kein IDE-Plugin. Kein visuelles Diff-Tool. Markdown-Dateien rein, Markdown-Dateien raus. Die Artefakte überstehen die Kontextfenster-Komprimierung, weil sie als Dateien existieren, nicht als Konversationszustand.

Meine autonome Schleife implementiert dieselbe Trennung auf Maschinenebene. Eine PRD-Datei definiert Stories mit Akzeptanzkriterien. Für jede Story wird ein frischer Agent gestartet, der ein Briefing über den aktuellen Git-Zustand und die Ergebnisse vorheriger Agents erhält. Der Agent implementiert, ein unabhängiger Verifizierer führt die Tests aus (vertraut niemals dem Selbstbericht des Agents), und drei Code-Reviewer bewerten den Diff parallel. Die gesamte Orchestrierung läuft über claude --print-Aufrufe in Bash-Skripten. Kein Framework, keine Runtime, kein Server.

Die Planungs-/Ausführungs-Trennung funktioniert im Terminal, weil das Terminal die Trennung strukturell erzwingt. Planung produziert Dateien. Ausführung konsumiert Dateien. Die Grenze zwischen den beiden Phasen ist eine Datei auf der Festplatte, sichtbar und auditierbar, kein Zustandsübergang versteckt in einem IDE-Plugin.

Warum CLI für Agents besser ist als IDE

Die Argumentation stützt sich auf drei Säulen: Kosten, Komponierbarkeit und Kontexteffizienz.

Kosten: 94 % Token-Reduktion

Kan Yilmaz maß den Token-Overhead von MCP gegenüber CLI in vier Szenarien.³ Die Zahlen sprechen für sich:

MCP injiziert Tool-Schemas in jede Konversation. Mit 84 Tools verbraucht allein der Schema-Overhead 15.540 Tokens, bevor der Agent irgendeine Arbeit erledigt. CLI-Aufrufe tragen keinen Schema-Overhead, weil Modelle standardmäßige Kommandozeilen-Interfaces bereits verstehen.¹⁰ Ein Benutzer dokumentierte, dass MCP_DOCKER 125.964 Tokens über 135 Tools verbrauchte.¹⁴

Jannik Reinhard führte einen parallelen Benchmark für eine Intune-Compliance-Aufgabe durch: 145.000 Tokens via MCP gegenüber 4.150 Tokens via CLI für gleichwertigen Output.¹⁰ Dem CLI-Agent standen 95 % seines Kontextfensters für Reasoning zur Verfügung. Der MCP-Agent verbrauchte den Großteil seines Budgets für Tool-Definitionen.

Komponierbarkeit: Unix-Pipes funktionieren bereits

Vercels v0-Team entfernte 80 % der Tools ihres Agents und ersetzte sie durch eine einzelne Bash-Umgebung.⁹ Die Ergebnisse:

Andrew Qu erklärte die Überlegung: „Wir lösten Probleme, die das Modell selbst bewältigen konnte.” Dateisysteme, grep, Pipes und Redirects komponieren bereits. Modelle verstehen sie. Benutzerdefinierte MCP-Tools für Operationen zu bauen, die cat | grep | jq nativ bewältigt, fügt Overhead hinzu, ohne Fähigkeiten zu erweitern.¹³

Anthropics eigene Dokumentation bestätigt das Muster. Claude Code folgt der Unix-Philosophie: Logs hineinleiten, in CI ausführen, mit anderen Tools verketten.⁵ Der Headless-Modus (claude -p) unterstützt strukturierten JSON-Output, Schema-Validierung und Sitzungswiederaufnahme über erfasste Sitzungs-IDs. Anthropic positioniert den Headless-Modus als primären Integrationspfad für CI/CD und geskriptete Workflows.⁵

Simon Willison formuliert die Implikation: Code zu schreiben ist jetzt billig.⁶ Die logische Konsequenz, die niemand hören will: Verifizierung ist jetzt der teure Teil. CLI-Agents komponieren mit bestehender Verifizierungsinfrastruktur. Test-Runner, Linter, Type-Checker, Security-Scanner, Deployment-Pipelines: alles Kommandozeilen-Tools. Ein IDE-Agent braucht für jeden ein Plugin. Ein CLI-Agent piped zu ihnen.

Kontexteffizienz: Reasoning über Signal, nicht Rauschen

Das Kontextfenster ist endlich. Jeder Token, der für Tool-Schemas, Konversationshistorie und MCP-Overhead ausgegeben wird, ist ein Token weniger für Reasoning. CLI-Architektur hält das Kontextbudget konstruktionsbedingt schlank.

Ein frischer claude --print-Aufruf erhält einen fokussierten Prompt (~2K Tokens) statt eines vollständigen Konversationskontexts (~100K+ Tokens). Jede Operation startet sauber. Kein akkumulierter Zustand. Keine veralteten Tool-Definitionen. Kein Konversationsdrift.

Meine Infrastruktur betreibt 84 Hooks über 17 Lifecycle-Events, alle orchestriert durch CLI-Aufrufe. Jeder Agent-Spawn erhält ein Briefing: aktueller Git-Zustand, eine Zusammenfassung der Ergebnisse vorheriger Agents und die Akzeptanzkriterien für seine eine Aufgabe. Briefing statt Gedächtnis. Modelle führen ein klares Briefing besser aus, als sie 30 Schritte akkumulierten Kontext navigieren.

Eine akademische Analyse der Unix-Philosophie in agentischen Systemen formalisierte das Prinzip: Diverse Schnittstellen auf eine einheitliche Abstraktion kollabieren, wobei ein gewisser Verlust an Spezialisierung zugunsten von Komponierbarkeit und Handhabbarkeit akzeptiert wird.¹¹ Dateiähnliche Abstraktionen und codebasierte Spezifikationen reduzieren die kognitive und technische Belastung. CLI-Agents erben 50 Jahre dieser Designarbeit.

Remote Control verändert die Gleichung

Der offensichtliche Einwand gegen CLI-first-Agents: Sie verlieren das visuelle Feedback einer IDE. Anthropic lieferte am 25. Februar 2026 eine Antwort. Remote Control verbindet sich von jedem Browser oder der Claude-Mobile-App mit einer lokalen Claude Code-Sitzung.² Das Feature erzielte 531 Punkte und 313 Kommentare auf Hacker News.

Remote Control verschiebt nichts in die Cloud. Der Agent läuft weiterhin lokal. Die Terminal-Sitzung registriert sich bei Anthropics API über TLS und fragt nach Arbeit. Der gesamte Datenverkehr läuft über ausgehendes HTTPS. Keine eingehenden Ports offen.²

Das Feature schließt die Überwachungslücke. Vor Remote Control hatten CLI-Agents zwei Modi: überwacht (am Terminal sitzen) oder unüberwacht (weggehen und hoffen). Remote Control schafft einen dritten: asynchrone Steuerung. Genehmigungsanfragen werden an Ihr Telefon weitergeleitet. Sie genehmigen, lehnen ab oder leiten um – von überall.

Mein Hook-System klassifiziert Operationen nach Auswirkungsradius. Lokale Operationen (Datei-Schreibvorgänge, Testläufe) werden automatisch genehmigt. Gemeinsame Operationen (Git-Commits) warnen. Externe Operationen (Pushes, Deployments) werden zur menschlichen Überprüfung weitergeleitet. Remote Control verwandelt diesen „Weiterleitungs”-Pfad von einem blockierenden Warten in eine asynchrone Benachrichtigung. Der Agent arbeitet an der nächsten Story weiter, während ich die vorherige von meinem Telefon aus überprüfe.

Die IDE wird zur Anzeigeschicht, nicht zur Ausführungsumgebung. Sie überwachen den Fortschritt über Remote Control. Sie greifen ein, wenn Qualitätstore ein Problem markieren. Der CLI-Agent erledigt die Arbeit. Die IDE zeigt Ihnen das Ergebnis.

Das Bash-Agent-Muster

Vercels just-bash ist eine simulierte Bash-Umgebung mit einem In-Memory-Dateisystem, speziell für AI-Agents entwickelt.⁴ Das Design codiert drei Überzeugungen über Agent-Architektur:

Isolation statt Sandboxing. Jeder Aufruf läuft isoliert. Umgebungsvariablen, Funktionen und Arbeitsverzeichnis werden zwischen Aufrufen zurückgesetzt. Das Dateisystem bleibt bestehen. Lazy File Loading bedeutet, dass Dateien beim ersten Lesen geladen und gecacht werden, wobei Dateien, die der Agent schreibt, niemals geladen werden, bevor er sie liest. Der Agent kann seine eigene Umgebung nicht über Operationen hinweg kontaminieren.

Bestehende Tools statt benutzerdefinierter Tools. Grep ist 50 Jahre alt und bewältigt exakt das, was benutzerdefinierte Such-MCP-Tools replizieren. jq parst JSON. curl ruft URLs ab. Das Modell kennt diese Interfaces aus Trainingsdaten. Benutzerdefinierte Tools erfordern Schema-Injection und Dokumentation. Standard-Tools erfordern beides nicht.

Minimale Architektur statt Framework-Architektur. Andrew Qu formulierte das Prinzip: „Modelle werden intelligenter und Kontextfenster werden größer, also ist die beste Agent-Architektur vielleicht fast gar keine Architektur.”¹³

Mein Harness validiert das Muster im Produktionseinsatz. Etwa 15.000 Zeilen Bash, die Claude Code orchestrieren. 84 Hooks über 17 Event-Typen. Dispatcher, Qualitätstore, semantische Suchintegration, autonome Schleifen. Keine Python-Runtime, keine Framework-Abhängigkeit. Die rauen Kanten von Bash (kein natives JSON, kein Async, keine richtigen Datenstrukturen) sind real, aber lösbar. jq bewältigt JSON. Sequentielle Verarbeitung ist tatsächlich ein Feature: Gates sollten in Reihenfolge laufen, nicht um die Wette.

Das Muster funktioniert, weil Agent-Orchestrierung grundsätzlich darum geht, stdin zu lesen, eine Entscheidung zu treffen und stdout zu schreiben. Diese Beschreibung entspricht exakt dem Designzweck von Bash. Alles Komplexere deutet darauf hin, dass die Aufgabenzerlegung falsch war, nicht das Tooling.

Kosten als Architekturentscheidung

Kostenentscheidungen kumulieren. Die Wahl von CLI über MCP für zustandslose Operationen spart 94 % pro Aufruf.³ Bei 100 Operationen pro Tag erreichen die Einsparungen 228 $/Monat allein beim Tool-Definitions-Overhead.³ Diese Einsparungen setzen Budget für mehr Operationen frei, was weitere Einsparungen generiert. Die Architektur finanziert sich selbst.

Drei Kostenschichten kumulieren unabhängig voneinander:

Token-Schicht. System-Prompt-Komprimierung. Ich verwende ~3.500 Tokens System-Prompt über eine CLAUDE.md-Datei und 8 Rules-Dateien. Einschränkungen übertreffen Erklärungen. „Tool-Aufrufe ablehnen, die auf sensible Pfade zugreifen” leistet dasselbe wie eine 15-zeilige Erklärung, warum Anmeldedaten geschützt bleiben sollten. Anthropics Best-Practices-Dokumentation betont denselben Punkt: Die Kontextfenster-Leistung verschlechtert sich mit zunehmender Füllung.⁷ Jeder verschwendete Token kostet doppelt: einmal durch direkte API-Gebühren, noch einmal durch verschlechterte Reasoning-Qualität.

Agent-Schicht. Frische Spawns statt langer Konversationen. Jede Story in einem autonomen Lauf erhält einen neuen Agent mit einem sauberen Kontextfenster. Geoffrey Huntley dokumentierte ein ähnliches Muster namens „The Ralph Loop”, das autonome Entwicklung für 10,42 $/Stunde auf Sonnet betreibt.¹² Der Kontext bläht sich nie auf, weil jeder Agent frisch startet. Cache-Hits auf den System-Prompt kosten 90 % weniger (0,50 $ vs. 5,00 $ pro Million Tokens auf Opus 4.6), sodass der wiederholte System-Prompt über frische Spawns minimalen Overhead verursacht.⁸

Architektur-Schicht. CLI für zustandslose Operationen, MCP für zustandsbehaftete. Ein claude --print-Aufruf für eine einmalige Bewertung verursacht keinen Verbindungs-Overhead. MCP ist sinnvoll, wenn das Tool persistenten Zustand oder Streaming benötigt. Die meisten Agent-Operationen sind einmalige Bewertungen, Klassifizierungen oder Code-Generierungsaufgaben. CLI bewältigt alle davon zu geringeren Kosten mit einfacherem Debugging.

Ein konkretes Beispiel aus meiner autonomen Schleife letzte Woche: fünf PRD-Stories über Nacht verarbeitet.¹⁵ Jede Story startete einen frischen Agent (~2K Tokens Briefing), lief die Implementierung (~15K Tokens durchschnittlich), dann startete drei Review-Agents (~2K Tokens jeweils). Gesamt pro Story: ~23K Tokens. Derselbe Workflow in einer lang laufenden MCP-Konversation hätte ab Story drei ~100K+ Tokens akkumulierten Kontext pro Story mitgeschleppt. Fünf Stories via CLI: ~115K Tokens gesamt. Fünf Stories via MCP-Konversation: ~500K+ Tokens gesamt. Das Kostenverhältnis kumuliert mit jeder weiteren Story.

Wann MCP dennoch gewinnt

Die CLI-These argumentiert nicht universell gegen MCP. MCP gewinnt in spezifischen Szenarien, in denen CLI Schwächen zeigt.

Zustandsbehaftete Tool-Server. Ein Datenbank-Browser, der einen Verbindungspool über Aufrufe hinweg aufrechterhält, profitiert von MCPs persistentem Servermodell. Bei jedem CLI-Aufruf neu zu verbinden verursacht Latenz- und Authentifizierungs-Overhead. Wenn das Tool Zustand zwischen Aufrufen benötigt, ist MCP die richtige Wahl.

Strukturierte Validierung. MCP-Tool-Schemas erzwingen Input-/Output-Verträge. Ein CLI-Aufruf akzeptiert beliebigen Text. Wenn der Agent strukturierten Input liefern muss, der einem präzisen Schema entspricht (API-Schlüsselformat, Datumsbereiche, aufgezählte Optionen), fängt das MCP-Schema fehlerhaften Input ab, bevor das Tool ihn verarbeitet. CLI-Validierung erfordert das Tool selbst oder ein Wrapper-Skript zur Durchsetzung von Einschränkungen.

Multi-Tenant-Zugriffskontrolle. MCP-Server können Benutzerberechtigungen zentral durchsetzen. CLI-Tools erben die Berechtigungen des Betriebssystem-Benutzers. In Team-Umgebungen, in denen verschiedene Agents unterschiedliche Zugriffsebenen benötigen, bietet MCP feinkörnigere Autorisierung.

Streaming-Antworten. Lang laufende Operationen, die inkrementellen Output produzieren (Log-Tailing, Build-Fortschritt, Datenbank-Exporte), funktionieren besser über MCPs Streaming-Protokoll als über einen CLI-Aufruf, der bis zur Fertigstellung blockiert.

Die Entscheidungsregel: Wenn die Operation zustandslos und einmalig ist, verwenden Sie CLI. Wenn die Operation persistenten Zustand, strukturierte Verträge oder Streaming erfordert, verwenden Sie MCP. In meinem Harness sind etwa 90 % der Operationen zustandslos. Die 10 %, die MCP benötigen, profitieren tatsächlich davon. Die Optimierung der 90 % bringt den größten Ertrag.

Was Sie heute bauen können

Drei Muster, jedes an einem Nachmittag umsetzbar, jedes kumulierend mit den anderen.

Muster 1: Planungs-/Ausführungs-Trennung

# 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"

Jede Phase erhält eingeschränkte Tool-Berechtigungen. Der Planungs-Agent kann keinen Code bearbeiten. Der Implementierungs-Agent kann nicht im Web browsen. Dateigrenzen erzwingen die Trennung. Das --allowedTools-Flag übernimmt die Durchsetzung auf CLI-Ebene. Keine Konfigurationsdatei. Keine Plugin-Einstellungen. Ein Flag pro Aufruf, beschränkt auf genau die Berechtigungen, die diese Phase erfordert.

Der Annotationszyklus ist der entscheidende Unterschied zu „einfach besseres Prompting”. Sie überprüfen den Plan in Ihrem Editor. Sie streichen die Teile, mit denen Sie nicht einverstanden sind. Sie fügen Notizen am Rand hinzu. Der Agent liest Ihre annotierte Datei und überarbeitet. Der Plan wird mit jedem Durchgang besser, weil zwei verschiedene Intelligenzen (menschliches Domänenwissen, Modell-Code-Generierung) auf demselben Dokument konvergieren.

Muster 2: Frischer Spawn pro Aufgabe

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

Kein akkumulierter Kontext. Kein Konversationsdrift. Jeder Agent erhält ein sauberes Fenster mit einem fokussierten Briefing. Das --output-format json-Flag erfasst strukturierten Output einschließlich Sitzungs-IDs, was deterministische Konversationswiederaufnahme ermöglicht, falls eine Story Nacharbeit benötigt.

Der unabhängige Verifizierungsschritt ist wichtiger als der Implementierungsschritt. Agents zeigen, was ich Phantom Verification nenne: Sie behaupten, Tests bestanden zu haben, ohne sie auszuführen. Das Ausführen von pytest außerhalb des Kontextfensters des Agents eliminiert diesen Fehlermodus vollständig. Der Agent kann keine Ergebnisse falsch darstellen, die er nie produziert hat.

Muster 3: Parallele Review-Pipeline

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

Drei Agents. Drei Perspektiven. Null gemeinsamer Zustand. Meinungsverschiedenheiten zwischen Reviewern bringen genau die Probleme ans Licht, die ein einzelner Reviewer übersieht. Der &-Operator und das wait-Builtin handhaben die Parallelisierung. Keine Async-Runtime. Kein Thread-Pool. Kein Orchestrierungs-Framework. Bash-Job-Control erledigt die Arbeit.

Die Stärke des Musters: Jeder Reviewer erhält das vollständige Kontextfenster für sein einziges Anliegen. Ein einzelner Reviewer, der seine Aufmerksamkeit auf Korrektheit, Sicherheit und Stil aufteilt, schneidet schlechter ab als drei Spezialisten mit dediziertem Kontext. CLI macht die Aufteilung trivial, weil jeder Aufruf ein unabhängiger Prozess mit unabhängigem Speicher ist.

Zentrale Erkenntnisse

Für Entwickler, die Agent-Systeme bauen: - Beginnen Sie mit claude -p für alle Agent-Spawns. Fügen Sie MCP nur hinzu, wenn persistenter Zustand erforderlich ist. - Beschränken Sie Tool-Berechtigungen pro Phase. Planungs-Agents lesen. Implementierungs-Agents schreiben. Review-Agents lesen Diffs. - Planen Sie 94 % weniger Token-Overhead ein, indem Sie CLI statt MCP für zustandslose Operationen wählen.³

Für Teams, die autonome Workflows skalieren: - Frische Agent-Spawns verhindern Kontextdrift und begrenzen die Token-Kosten pro Operation. - Remote Control verwandelt „unüberwacht” in „asynchron überwacht”, ohne die CLI-Architektur zu verändern.² - Die Vercel-Daten beweisen das kontraintuitive Ergebnis: Weniger Tools bedeuten höhere Erfolgsraten, nicht niedrigere.⁴

Für Architekten, die Agent-Infrastruktur wählen: - CLI-Agents komponieren mit bestehender CI/CD-, Test- und Deployment-Tooling. Keine Integrationsarbeit nötig. - Die Unix-Philosophie (kleine Tools über Pipes komponieren) ist älter und leistungsfähiger als jedes Agent-spezifische Framework.¹¹ - Die 10%-Produktivitätsmauer fällt, wenn Sie aufhören, den Agent als Chat-Tool zu behandeln, und anfangen, ihn als Infrastruktur zu behandeln.

Teil der AI Engineering-Serie. Siehe auch: Claude Code als Infrastruktur, Anatomy of a Claw, Die autonome Schleife und Die 10%-Mauer.