Hör auf, deine CLI als Nachgedanke zu behandeln. Mach sie zum Kernel deines Agenten.

CLI ist das neue MCP. Slogan beiseite: CLI bedeutet Superkräfte für Claude, Codex und jeden Agent, der für dich programmiert. Wenn du Code-LLMs ihre eigene Arbeit programmatisch verifizieren lässt, verschaffst du ihnen einen unfairen Vorteil gegenüber klassischen Fullstack-Apps, die diese Oberfläche nicht mitgeliefert haben.

CLI ist der neue Full Stack.

Am Freitagabend vor meinem Urlaub an der Costa Brava wollte ich noch schnell eine Kleinigkeit shippen, bevor ich den Laptop zuklappe (ohne dass meine Frau mich anschreit).

Zwei Claude Code-Fenster nebeneinander. Derselbe Prompt für beide. Zwei verschiedene Apps, zu 95% derselbe Stack.

Als ich den Laptop zuklappte, hatte eine App ein Feature in drei autonomen Iterationen ausgeliefert. Bei der anderen klickte ich im Admin herum wie ein Junior, der versucht, Prod vom Handy aus zu debuggen. Derselbe Agent, derselbe ich, ein Ordner Unterschied.

Derselbe Stack, ein Ordner Unterschied

Erste App, linkes Fenster. Claude Code schreibt die Mutation, tippt einen Befehl ins Terminal, liest das zurückkommende JSON, erkennt, dass ein Feld falsch gecastet ist, korrigiert es, tippt erneut. Drei Iterationen in völliger Autonomie. Ich komme zurück, sage "schönes Wochenende". Der Commit ist fertig, zu 100% validiert.

Zweite App, rechtes Fenster. Claude Code schreibt die Mutation, dann stoppt es. Es pingt mich an. Kannst du das Admin öffnen und prüfen, ob das funktioniert? Ich klicke. Ich aktualisiere, dann klicke ich wieder. Erneuter Ping. Meine Frau wird lauter. Egal, schauen wir Montag. Sonst hätte ich den ganzen Abend damit verbracht, die Maus eines Agents zu sein, der eigentlich an meiner Stelle programmieren sollte.

Derselbe Stack, derselbe ich, dasselbe Claude Code bei beiden. Der einzige Unterschied passt in einen Ordner.

Die beiden Apps gehören mir. Eine ist ein Back-Office, das nachts einen WooCommerce-Katalog über eine Partner-API synchronisiert, plus einen wöchentlichen CSV-Feed von einem Distributor. Die andere ist ein Back-Office, das ein Netzwerk von WooCommerce-Client-E-Shops steuert (Deployments, Theme-Updates, Plugin-Sync, das übliche Fleet-Zeug). Beide seit sechs Monaten im Aufbau. Beide laufen mit Next.js, Convex, shadcn, Vercel. Dieselbe CLAUDE.md, dieselben Konventionen.

Eine hat eine CLI als zentrale Schicht. Die andere hat einen scripts/-Ordner.

Das ist alles. Das ist der ganze Unterschied.

Mit "CLI" meine ich einen echten Einstiegspunkt mit Unterbefehlen, die nach Geschäftsaktionen benannt sind (catalog refresh, partner sync, site init), verdrahtet mit derselben Business-Schicht, die auch das Dashboard verwendet. Du tippst bun run cli partner sync --dry-run, und derselbe Code-Pfad läuft, der auch läuft, wenn ein Admin auf "Sync" klickt, nur dass er JSON an stdout zurückgibt.

Die andere App hat nichts davon. Nur .mjs-Dateien mit Namen wie fix-thing-2025-08.mjs (gib zu, du hast auch so einen Ordner). Jede geschrieben, um "einmal zu laufen". Die meisten liefen nie ein zweites Mal.

Das ist der ganze Unterschied. Und er veränderte, wie der Agent auf jeder Ebene arbeitete.

30 Tage Commits lügen nicht: 1,8x mehr Features, halb so viele Fixes

Ich ging durch die Git-Historie beider Repos über dasselbe 30-Tage-Fenster im Mai.

Die CLI-App shippte 272 Commits. Die Scripts-App shippte 150. Das ist ein Verhältnis von 1,8x, bei demselben ich, demselben Agent, derselben täglichen Routine.

Im CLI-Repo wurde jeder einzelne Unterbefehl mindestens einmal während des Zeitfensters angefasst. 100%. Im scripts/-Ordner sahen nur 29% der Dateien Aktivität. Der Rest lag brach. 41% aller Script-Dateien in der Scripts-App waren geschrieben, einmal ausgeführt und nie wieder geöffnet worden. Die älteste, die ich fand und die in dieses Profil passt, war seit 57 Tagen nicht mehr angefasst worden. Ich hatte völlig vergessen, dass sie existiert, bis ich danach suchte.

Es gibt noch eine Zahl, die interessant ist, aber ich möchte sie als Hypothese kennzeichnen, nicht als Beweis. Bei Commit-Nachrichten mit fix: versus feat: hatte die CLI-App ein Fix-zu-Feature-Verhältnis von 0,44. Die Scripts-App lag bei 0,82. Etwa doppelt so viele Fix-Commits pro Feature auf der Seite ohne CLI.

Ich kann nicht beweisen, dass die CLI diese Lücke verursacht. Die beiden Apps haben unterschiedliche Domain-Reife, unterschiedliche Komplexität, unterschiedliche Abdeckung von Edge Cases. Die Hälfte des Unterschieds könnte daher kommen, dass das Back-Office für Client-Sites einfach älter und fummeliger ist als das für die Partner-API. Aber die Lücke ist konsistent mit dem, was ich täglich beobachte, und sie passt zur Autonomie-Lücke, die ich in der Einleitung beschrieben habe: Der Agent liefert sauberere Arbeit ab, wenn er eine Möglichkeit hat, sich selbst zu verifizieren, also schleichen sich weniger Regressionen durch.

Die Waisenrate (41% versus 0%) und die Geschwindigkeitslücke (1,8x) sind keine Hypothesen. Die kann ich direkt aus git log ablesen.

Der wahre Mechanismus: Agents brauchen eine textstrukturierte Oberfläche

Der Grund, warum die CLI-App autonome Iterationen produziert, während die Scripts-App Ping-Festivals produziert, hat nichts mit Code-Qualität oder Modellgröße zu tun.

Es geht um die Oberfläche, die der Agent hat, um seine eigene Arbeit zu validieren.

Denk daran, was Claude Code tatsächlich in einer Feature-Schleife macht. Es schreibt Code, dann muss es wissen, ob der Code das tut, was er tun sollte. Wenn der einzige Weg zu prüfen ist "öffne das Dashboard, klicke herum, schau auf den Bildschirm", kann der Agent das nicht. Browser geben DOM zurück. DOM ohne ein menschliches Auge, das interpretiert, was gerendert wird, ist für einen Agent undurchsichtig. Die Farben, die Ladezustände, das Modal, das aufpoppte, die Validierungsnachricht unten, all das ist für eine Person bedeutungsvoll und für ein Modell Rauschen. Der Agent hat keine Grundwahrheit, also stoppt er und fragt dich.

Eine CLI gibt Text zurück. JSON, strukturiertes stdout, Exit-Codes. Dinge, die ein Agent lesen, parsen und durchdenken kann. Der Agent führt den Befehl aus, liest die Ausgabe, sieht, dass partnerStatus: "rejected" bedeutet, dass die Mutation nicht durchgegangen ist, korrigiert den Code, führt ihn erneut aus. Kein Mensch in der Schleife. Das Feedback-Signal ist nativ lesbar für das Modell.

Das ist das ganze Prinzip. Oberfläche textstrukturiert gleich Agent autonom. Oberfläche nur-DOM gleich Agent, der dich bei jeder Iteration anpingt.

Deshalb funktionieren auch MCP-Server, REST-APIs, tRPC-Endpunkte, GraphQL alle für Agents, die deinen Service aufrufen. Sie sind alle textstrukturierte Oberflächen. Eine CLI ist nur die einfachste, lokalste Verkörperung dieses Prinzips für den Agent, der deine eigene App programmiert. Nicht einen Remote-Service aufruft. Code in deinem Repo schreibt und ihn jetzt testen muss.

Du kannst das mit Playwright simulieren, das auf dein Dashboard zeigt. Machen Leute. Funktioniert, irgendwie. Kostet auch eine 10x-Verlangsamung, eine flaky Retry-Schicht und einen Screenshot-Vergleichsschritt, der jedes Mal bricht, wenn du eine UI-Änderung shippst. Eine CLI gibt dieselbe Antwort in Millisekunden ohne Flakiness zurück, weil Text schon immer das war, was der Agent eigentlich wollte.

Der 2026-Stack vergaß eine Schicht (und jeder AI-Code-Gen-Tool überspringt sie auch)

Lies irgendeinen "bester Stack zum Launch deines AI-programmierten Tools"-Guide, der zwischen Februar und April 2026 geschrieben wurde. KDnuggets, Idlen, Context Studios, MindStudio, du kannst einen zufällig auswählen. Sie konvergieren alle auf dieselben sechs oder sieben Schichten. Next.js für das Frontend. shadcn für das UI-Kit. Supabase oder Convex für das Backend. Clerk für Auth. Stripe für Payments. Resend für Transaktions-E-Mails. Vercel für Hosting. Manche fügen Tailwind, OpenAI, Claude, Gemini hinzu.

Es gibt mindestens 50 solcher Guides, die in den letzten drei Monaten veröffentlicht wurden. Keiner von ihnen erwähnt eine CLI für deine App.

Derselbe blinde Fleck auf der AI-Seite. Cursor, v0, Bolt, Lovable, Claude Code selbst, wenn es ein neues Projekt scaffoldet. Alle generieren ein Frontend, ein Backend, eine Hosting-Config. Null von ihnen generieren eine CLI als erstklassige Schicht. Wenn du Claude Code bittest, "eine Next.js-App mit Convex und Stripe aufzusetzen", bekommst du diese drei Dinge und nichts anderes. Die CLI, falls vorhanden, erscheint später als Scaffolding (next dev, convex dev) und das war's.

Das war 2020 kein Problem. 2020 hast du deinen eigenen Code geschrieben, und deine IDE war deine Feedback-Schleife. F5, F12, console.log, console.log, console.log. Das DOM war in Ordnung, weil du derjenige warst, der es gelesen hat.

2026 bist du nicht derjenige, der den meisten Code schreibt. Der Agent ist es. Und der Agent hat keine Augen.

Ein 2026-Stack ohne CLI-Schicht zwingt den Agent, bei jeder Iteration von dir abhängig zu sein. Der Agent schreibt eine Mutation, du klickst im Admin, du sagst dem Agent, ob es funktioniert hat. Der Agent schreibt einen Sync-Job, du machst tail -f auf die Logs, du sagst dem Agent, was du gesehen hast. Jede Feature-Schleife hat dich als obligatorischen Mittelknoten. Du denkst, du promptest einen Agent, für dich zu shippen, tatsächlich spielst du Browser-Vermittler für den Agent.

Die vierte Schicht folgt aus einer Tatsache: Wenn du willst, dass der Agent autonom shippt, musst du ihm eine Oberfläche geben, die er lesen kann.

Idlens Artikel argumentiert, dass die Wahl des falschen Backends bedeutet, deine Datenmodelle um 2 Uhr nachts neu zu schreiben. Ja, und es ist schlimmer, wenn du keine CLI hast, weil du sie von Hand neu schreibst, anstatt bun run cli model migrate auszuführen.

Warum Scripts verrotten und CLIs leben

Die 41%-Waisenrate kommt nicht von Faulheit. Sie kommt daher, dass ein scripts/-Ordner architektonisch nichts von dir verlangt.

Du schreibst scripts/migrate-orders-2025-04.mjs, weil du einen Notfall hast. Du führst es einmal aus. Es funktioniert. Du committest es (oder auch nicht, je nachdem, wie panisch du warst). Drei Wochen später, ein weiterer Notfall. Du schreibst scripts/migrate-orders-fix.mjs. Dasselbe Problem, leicht anderer Name. Du verwendest das erste nicht wieder, weil du nicht daran denkst, dass es existiert. Es gibt kein scripts/ --help. Es gibt nur ein ls.

Der ganze Ordner wird wie Karens Aktenschrank aus der Buchhaltung: technisch organisiert, praktisch unbrauchbar. Alles ist "da", niemand weiß wo, sogar Karen hat aufgehört zu suchen.

Eine CLI erzwingt eine andere Form. Du kannst partner sync nicht als Unterbefehl hinzufügen, ohne es im Einstiegspunkt zu registrieren, was bedeutet, dass du alle anderen Unterbefehle siehst, jedes Mal wenn du einen neuen hinzufügst. Auffindbarkeit ist in das Tool eingebaut. Neue Unterbefehle erben dieselben Flags (--dry-run, --limit, --verbose), denselben Logger, dieselbe Fehlerbehandlung. Idempotenz wird einfach, weil du bereits durch eine gemeinsame Business-Schicht gehst, die auch das Dashboard verwendet.

Deshalb liegt die Berührungsrate bei 100% auf der CLI-Seite. Ich bin nicht disziplinierter, wenn ich eine CLI verwende. Die CLI ist nur architektonisch feindlich gegenüber Wegwerf-Code auf eine Art, wie es scripts/ nie ist.

Und --help hilft nicht nur dir. Es ist der Einstiegspunkt für jeden Agent, der in deinem Repo landet. Claude Code tippt einmal bun run cli --help und kennt jetzt jede Geschäftsaktion, die es auslösen kann, mit ihren Flags und ihrer Beschreibung. Kein Prompt-Engineering, keine Doku zum Füttern. Die CLI dokumentiert sich selbst, für Menschen und für Agents gleichzeitig. Das ist es, was scripts/ dir nie geben wird, egal wie sauber deine Dateinamen sind.

Caveat, den ich hier reinsetzen sollte, während ich prahle. Meine eigene CLI hat eine echte Schwäche. Von 14 Unterbefehlen haben 11 keine Beschreibung in der --help-Ausgabe. Das sind 79% meiner Befehle, die als nackte Namen ohne Erklärung erscheinen. Die CLI erzwang Ausführungsdisziplin. Sie erzwang keine Dokumentationsdisziplin. Claude Code kann immer noch jeden Befehl entdecken, die JSON-Ausgabe parsen und sie verwenden. Ein Junior-Dev, der das Repo zum ersten Mal öffnet, müsste den Quellcode lesen. Ich repariere es langsam, aber die Lektion steht: Die Architektur löst das Ausführungs-Problem, nicht das Lehr-Problem. Du musst immer noch die Docstrings schreiben.

Deine App ist bereits versehentlich agentisch

Das, was dir niemand in den Stack-2026-Guides sagt: Eine CLI, die die Business-Schicht mit deiner UI teilt, macht deine App nativ agent-ready. Nicht als separates Produkt. Als kostenloser Nebeneffekt.

Drei konkrete Wege, deine CLI einem Agent zu exponieren, der nicht in deiner IDE sitzt.

Als MCP-Server wrappen. Vielleicht 50 Zeilen TypeScript. Du schreibst einen dünnen MCP-Server, der jeden Unterbefehl deiner CLI als MCP-Tool registriert. Der Tool-Input mappt auf CLI-Flags. Der Tool-Output ist das JSON, das die CLI bereits zurückgibt. Boom, jeder MCP-Client (Claude Desktop, Cursor, alles was MCP spricht) kann deine CLI als natives Tool aufrufen. Du hast deine bestehende CLI gewrappt und es einen MCP-Server genannt.

Cron plus Agent. Ein Scheduler führt alle sechs Stunden bun run cli catalog refresh aus. Die JSON-Ausgabe geht in eine Convex-Tabelle. Ein Hintergrund-Agent liest die neueste Zeile, entscheidet, ob der Refresh einen Partner-Fehler hatte, und löst wenn ja ein Follow-up bun run cli partner reconnect aus. Kein Browser. Kein Mensch. Der Agent trifft Entscheidungen basierend auf Text, den die CLI ausgibt, dann löst er weitere CLI-Befehle aus. Du hast gerade dein Back-Office in eine selbstheilende Schleife verwandelt.

HTTP-Gateway Shell-out. Du exponierst einen winzigen Express- oder Hono-Endpunkt, der einen CLI-Befehlsnamen plus Args nimmt, zur CLI ausshellt, das JSON zurückgibt. Authentifiziert natürlich. Jetzt kann jeder externe Agent, der HTTP spricht, deine App steuern. Kein SDK zu maintainen. Die CLI ist das SDK.

Keiner dieser drei verlangt ein Refactoring deiner Business-Logik. Sie sind reine Expositions-Schichten auf Code, den du bereits geschrieben hast. Ein Stack, zwei Modi: Dashboard für Menschen, CLI für Agents. Das Dashboard wusste nicht, dass es einen Zwilling hatte. Jetzt schon.

Die drei Integrationsmuster (wähle eins, wähle richtig)

Wenn du eine CLI in deinen Stack einbacken willst, gibt es drei Wege, sie zu verdrahten. Nur einer davon gibt dir die Autonomie-Lücke, die ich früher beschrieben habe.

Muster 1: CLI teilt die Business-Schicht mit der UI. Der Dashboard-"Sync partner"-Button ruft eine Convex-Mutation auf. Der CLI-partner sync-Befehl ruft dieselbe Mutation auf, mit demselben Drizzle-Schema, denselben TypeScript-Typen end-to-end. Dieselben Idempotenz-Garantien. Dasselbe Audit-Log. Das ist das, was du willst. Alles, was ich beschrieben habe, setzt dieses Muster voraus. (Convex paart sich besonders gut mit Claude Code für genau dieses Setup, weil die typisierte end-to-end API die CLI zu einem dünnen Wrapper um Mutationen macht, anstatt zu einer parallelen Implementierung.)

Muster 2: CLI als HTTP-Client deiner eigenen API. Die CLI ruft deine REST- oder tRPC-Endpunkte auf. Einfacher zu isolieren, sprachagnostisch, du kannst die CLI an Clients shippen, die dein Monorepo nicht laufen lassen. Aber du verlierst die Typing-Vorteile, musst Auth manuell handhaben, und Idempotenz liegt bei demjenigen, der den Endpunkt geschrieben hat. Akzeptabel als Fallback, wenn dein Backend in einem anderen Repo ist als dein CLI-Consumer. Nicht optimal.

Muster 3: DevOps-CLI, getrennt von der App. Deploy-Befehle, Backup-Scripts, Monitoring-Tools. Nützlich, aber es ist kein Ersatz. Wenn deine App lebt, brauchst du auch Muster 1 oder 2 daneben. Muster 3 allein ist das, was die meisten Teams shippen und was mit "wir haben eine CLI" verwechselt wird. Es ist nur ein Deploy-Script.

Urteil: Muster 1 ist das einzige, das die Geschwindigkeitslücke zurückgibt. Muster 2 ist die halbe Arbeit für einen Bruchteil des Nutzens. Muster 3 ist Hosting-Klempnerei, die als CLI verkleidet ist.

Wenn du nur ein Muster bauen kannst, baue das erste.

Tooling: cac vs citty vs der Rest in 2026

Kurzer Überblick über das, was tatsächlich lohnt, um die CLI selbst zu bauen, da hier die meisten Leute ein Wochenende hängenbleiben.

cac ist mein Standard. Etwa 2 KB, null Dependencies, ESM-first. Wenn deine CLI weniger als 20 Unterbefehle hat, ist das das richtige Tool. Klein genug, dass du nicht darüber nachdenkst, und Claude Code generiert sauberen cac-Code beim ersten Versuch.

citty von den UnJS-Leuten ist die aufsteigende Wahl für 2026. Type-safe, lazy-loading Unterbefehle (wichtig, wenn du anfängst, 30+ zu erreichen), ESM-first, spielt schön mit Nitro und dem Rest der UnJS-Welt. Migriere dazu, wenn deine CLI über das hinauswächst, wo sich cac beengt anfühlt.

commander ist die Legacy-reife Option. Stabil, gut dokumentiert, wird den Job machen, aber die API fühlt sich älter an und das Bundle ist schwerer als nötig. Wähle es nur, wenn dein Team es bereits kennt.

clipanion ist OOP-flavored, wird von Yarn verwendet. Gut, wenn du Klassen magst und striktes Typing willst. Nische.

oclif ist over-architected, es sei denn, deine CLI selbst ist das Produkt (denk Heroku, Salesforce). Für eine CLI, die eine App unterstützt, ist oclif wie einen Gabelstapler zu bringen, um ein Sofa zu bewegen.

Für den Rest der Erfahrung willst du clack für Prompts (wunderschöne TUI, sehr recent), picocolors für Farben (kleiner und schneller als chalk jetzt), consola für Logging, listr2 wenn du mehrstufige Tasks mit Progress-Bars hast, und bun shell oder zx für eingebettete Scripts.

Starte mit cac. Migriere zu citty, wenn du 20 Unterbefehle überschreitest.

Überdenke es nicht.

Wenn die fehlende CLI wehtut (vier Szenarien)

Vier Momente, wo die Abwesenheit einer CLI dich spezifisch kostet, falls das abstrakte Argument noch nicht angekommen ist.

Onboarding eines neuen Client-E-Shops. Ohne CLI ist jeder neue Client zwei bis drei Stunden Klicken im Admin: Domain bereitstellen, Theme setzen, Plugins installieren, Katalog seeden, DNS konfigurieren. Multipliziere mit zehn Clients in einem Monat. Mit CLI führt site init shop.example.com die ganze Sequenz in fünf Minuten aus. Der Agent kann es selbst ausführen, wenn ein Stripe-Webhook "neuer Kunde" feuert.

Wiederkehrender Datenfix. Ein Partner gibt manchmal malformierte Preise in ihrer API zurück. Ohne CLI bedeutet jeder Incident, die Fix-Mutation von Hand neu zu schreiben oder durch scripts/ zu graben, um "die zu finden, die letztes Mal funktioniert hat". Mit CLI hast du bun run cli prices reconcile --dry-run, idempotent, versioniert, dokumentiert in --help. Der Agent ruft es selbst auf, wenn der Alert feuert.

Audit während Incident. Etwas ist in Prod kaputt gegangen, du musst wissen, welche Bestellungen betroffen waren. Ohne CLI grepst du durch scripts/ nach "dem Audit-Ding, das ich im März geschrieben habe". Mit CLI existiert cli orders audit --since=2026-04-01, ist dokumentiert, und der Agent kann es ausführen, während du noch in Slack tippst.

Externe Datenaktualisierung. Cron muss jede Nacht einen Partner-Katalog aktualisieren. Ohne CLI zeigt der Cron auf node scripts/old-thing.mjs und die Datei driftet langsam aus der Synchronisation mit dem Schema, bis sie eines Dienstags 48 Stunden lang stillschweigend fehlschlägt, bevor es jemand bemerkt. Mit CLI zeigt der Cron auf bun run cli partner refresh, was dieselbe Business-Schicht wie das Dashboard teilt, also bricht eine Schema-Änderung den Cron beim nächsten Deploy, anstatt mitten in der Nacht.

Dieselben vier Probleme. Die CLI macht jedes langweilig.

Der 30-Sekunden-Test, den dein Stack heute bestehen muss

Öffne dein Terminal. cd in dein Repo. Tippe bun run cli --help (oder yarn cli --help, oder npm run cli -- --help, was auch immer dein Package-Manager ist).

Es gibt genau drei mögliche Ergebnisse.

Ergebnis A. Nichts kommt raus. Oder "command not found". Oder package.json hat kein cli-Script. Du hast keine CLI. Du hast eine UI, die auf ein Backend geschraubt ist. Der Agent, der deine App programmiert, hängt bei jeder Iteration von dir ab, und die Waisenrate deines scripts/-Ordners klettert langsam Richtung 41%, ob du es misst oder nicht.

Ergebnis B. Eine Liste taucht auf, aber die Unterbefehle sind generische DevOps-Sachen (build, dev, test, deploy) ohne Geschäftsaktionen. Du hast DevOps-Scaffolding. Nützlich, aber der Agent kann deinen Code deployen und nicht validieren, dass ein Feature funktioniert. Du bist bei Muster 3 der drei Muster oben. Halbe Strecke.

Ergebnis C. Eine Liste taucht auf mit Unterbefehlen, die nach Geschäftsaktionen benannt sind (site init, partner sync, catalog refresh), jeder mit einer Beschreibung. Du hast einen 2026-ready Stack. Der Agent, der deinen Code schreibt, hat eine Möglichkeit, ihn zu verifizieren. Dein scripts/-Ordner ist leer oder hat weniger als fünf Dateien. Du kannst aufhören zu lesen.

Wenn du A oder B bekommen hast, hier fängst du an. Wähle ein oder zwei Geschäftsaktionen, die du am häufigsten machst (die, die in deinem scripts/-Ordner unter drei verschiedenen Namen auftauchen), und mache sie zu den ersten zwei Unterbefehlen einer echten CLI. Verdrahte sie durch dieselbe Business-Schicht, die das Dashboard verwendet. Mache die Ausgabe JSON-förmig. Das ist das kleinstmögliche Muster 1, und es wird ändern, wie Claude Code morgen früh an deinem Repo arbeitet.

Ich habe bereits über CLIs als Interface für Agents, die deine Tools aufrufen geschrieben. Dieser hier geht um CLIs als Interface für den Agent, der deinen Code von innen schreibt. Anderes Problem, dieselbe Schicht. Der erste ging um MCP versus CLI als Remote-Calling-Convention. Dieser geht darum, ob der Agent in deiner IDE eine Möglichkeit hat zu shippen.

Das nächste Mal, wenn du eine App startest, entscheide am ersten Tag, ob die CLI ein Kernel oder ein Nachgedanke ist. Diese Wahl entscheidet, wie viel Zeit Claude Code damit verbringt, für dich zu programmieren, versus wie viel Zeit du damit verbringst, die Maus von Claude Code zu sein.

---

Sechs Monate lang zwei Apps parallel zu bauen und ich merkte nicht, dass ich ein kontrolliertes Experiment an mir selbst durchführte. Als alter Linux-Kopf wusste ich bereits intuitiv, dass CLI die meisten Dinge schlägt. Was ich nicht kommen sah, war der Teil, der am meisten zählte: nicht nur Geschwindigkeit und Skriptbarkeit, sondern dem Agent eine Feedback-Schleife zu geben, die er selbst lesen konnte.

Claude und Codex werden das nicht standardmäßig vorschlagen. Also sag es ihnen selbst: backe eine CLI-Schicht als Kernel ein, Tag eins.

Ich bin weg, Piña Colada wartet 😎

CLI war die ganze Zeit die Schicht.

Quellen

• KDnuggets, Tech Stack for Vibe Coding Modern Applications (Februar 2026)
• Idlen, The Best Stack to Launch Your AI-Coded Tool in 2026 (April 2026)
• Context Studios, The Perfect Vibe Coding Tech Stack 2026: 10 Tools Every App Needs (Februar 2026)
• Ersthand-Audit, zwei meiner eigenen Apps, 30 Tage Git-Historie (Mai 2026)