CLI ist alles, was du brauchst

Leute fragen mich oft: "Claude Code ist offensichtlich besser als andere KI-Coding-Tools, aber ich kann nicht genau erklären, warum." Der folgende Blogpost von Marco Franzon erklärt den Grund hervorragend. Sowohl Claude Code als auch das kürzlich populäre OpenClaw teilen ein grundlegendes Merkmal: Beide verbinden die Fähigkeiten großer Sprachmodelle direkt mit der Terminal-Kommandozeile des Systems. Genau deshalb kann KI mehr als nur "eine Empfehlung geben" -- sie kann tatsächlich in dein Projektverzeichnis gehen und loslegen: suchen, ändern, ausführen, testen, committen und debuggen -- ein enger, automatisierter Entwicklungsloop. Viele Menschen halten das Terminal für eine "altmodische Eingabemethode", aber in Wirklichkeit ist das Gegenteil der Fall. Die wichtigsten Informationssysteme der Welt laufen alle auf der Kommandozeile: Banktransaktionen, Flugbuchungen und -planung, Logistik-Sortierung und -Tracking sowie die Kerngeschäftsprozesse von Regierungen und öffentlichen Institutionen. Die Kommandozeile ist schon so lange die "universelle Schnittstelle", weil sie stabil genug, universell genug, komponierbar genug und einfach genug zu automatisieren ist. LLMs wurden auf enormen Mengen an Kommandozeilendaten trainiert und können die Kommandozeile mit bemerkenswerter Präzision bedienen. Wenn also leistungsstarke LLMs auf die Flexibilität der Kommandozeile treffen, entsteht eine Kombination, wie die Menschheit sie noch nie gesehen hat.
Der MCP-Hype ist vorbei.
MCP (Model Context Protocol), das in den letzten zwei Jahren weitgehend als die Zukunft der KI-Agent-Tools galt, hat sich in der Praxis als zu umständlich erwiesen. Im Jahr 2026 kehren Entwickler, die Geschwindigkeit und Effizienz schätzen, zur Kommandozeile zurück.
Sie geben KI-LLMs direkten Zugriff auf die Shell und erlauben so den Agenten, Tools aufzurufen, die seit Jahrzehnten im Einsatz erprobt sind -- Tools wie git, rg, grep, npm, docker, curl, jq und tail. Entwickler brauchen keine Custom-Server oder aufgeblähte Schema-Beschreibungen mehr, die ihre Context-Windows füllen.
Alles, was du brauchst, ist ein leistungsstarkes KI-Modell gepaart mit Bash oder Zsh, und KI-unterstützte Coding-Tools wie Deep Code liefern bemerkenswerte Ergebnisse.
Warum MCP im Alltagsentwicklerworkflow an Reiz verloren hat
Für typische Entwicklerworkflows fügt MCP oft Reibung hinzu, anstatt sie zu reduzieren, aus mehreren Gründen:
- Token-Overhead: Umfangreiche Tool-Kataloge und Schema-Beschreibungen verbrauchen wertvollen Context-Space.
- Das Rad neu erfinden: Custom-MCP-Server duplizieren häufig Funktionalität, die Standard-CLI-Tools bereits zuverlässig abdecken.
- Schlechte Komponierbarkeit: Entwickler verlieren die Piping-, Chaining- und On-the-fly-Modifikationsfähigkeiten, die Unix-Systeme vor Jahrzehnten perfektioniert haben.
- Modellkompatibilität: Führende LLMs wurden umfassend im Umgang mit Shell trainiert. Diese Modelle verstehen Parameter, Pipes, Fehlermeldungen und Dokumentation mit beeindruckender Genauigkeit.
Die Best Practice ist einfach: Öffne dein Projektverzeichnis in Deep Code, erteile Shell-Ausführungsberechtigungen innerhalb von Sicherheitsleitplanken und gib dann Befehle ein, die beschreiben, was du erreichen möchtest. Deep Code wird automatisch planen, Befehle ausführen, Dateien editieren, Tests ausführen, Code committen und debuggen.
MCP hat immer noch seinen Wert in regulierten Unternehmensumgebungen und SaaS-API-Integrationen, die strikte Typsicherheit erfordern. Aber für 80 bis 90 Prozent der alltäglichen Arbeit ist es nur Rauschen.
Szenarien, in denen die Kommandozeile MCP überstrahlt
In meinem täglichen Entwicklungsalltag stößt man häufig auf Situationen, die MCPS Grenzen schmerzhaft deutlich machen.
Projektweites Code-Refactoring
Deep Code beginnt mit einem Befehl wie: rg "oldDeprecatedFunction".
Es kartiert den Umfang der Änderungen. Es macht gezielte Edits über mehrere Dateien. Es prüft mit git diff. Es führt npm test oder cargo test aus. Dann committet es: refactor: remove deprecated API calls
In solchen Szenarien braucht man keinen GitHub-MCP-Server -- nur rg und git.
Full-Stack-Debugging von Produktions-Bugs
Ich gebe Deep Code diese Anweisung: Reproduce the user authentication failure in the staging environment.
Deep Code holt den Code, startet die Staging-Umgebung und überwacht Log-Fehler. Es testet APIs mit curl, startet Datenbanken mit docker-compose und führt spezifische Testfälle aus.
Kein Docker-MCP nötig. Kein Logging-MCP nötig. Nur eine kompetente Shell.
Scaffolding eines neuen Microservice
Ich gebe Deep Code diese Anweisung: Build a Rust user profile API with Axum + sqlx. Use Postgres for the database.
Deep Code verwendet das bereits auf der Maschine installierte Toolchain (wie Rusts cargo), um das Projekt zu erstellen, Abhängigkeiten hinzuzufügen und den Service zu starten.
Das vorhandene Toolchain reicht aus -- kein Datenbank-MCP nötig.
Flaky CI/CD-Fehler beheben
Deep Code klont das Repo. Es führt den Workflow lokal mit act aus. Es ortet den Fehler. Es ändert .github/workflows/ci.yml oder die Dockerfile. Es verifiziert mit docker build. Es pushed einen Branch. Es öffnet einen PR mit gh.
Alles Standard-CLI-Tools. Keine Custom-CI-Integrationschicht nötig.
Muster im Entwickler-Feedback
Teams, die Deep Codes native Kommandozeilen-Ansatz nutzen, berichten von folgenden Vorteilen:
- Deutlich schnellere Auslieferung.
- Vorhersagbarerer Token-Verbrauch.
- Größere Transparenz im KI-unterstützten Tool-Verhalten.
- Einfachere Überwachung und Debugging von KI-Operationen.
Zusammenfassend ist der entstehende Konsens klar: Hört auf, Integrationen zu bauen. Baut stattdessen CLI-Tools. Denn Bash ist das ultimative MCP.
Das Terminal war schon immer die universelle Entwicklungsumgebung
Im Jahr 2026 ist das Terminal auch die mächtigste Schnittstelle für KI-Coding-Agents. Es sei denn, du arbeitest mit spezialisierten Enterprise-Tools -- dann kannst du den gesamten schweren MCP-Stack komplett überspringen.
Öffne einfach dein Projektverzeichnis in Deep Code, erteile Shell-Zugriff, beschreibe deine Aufgabe und schau zu, wie es arbeitet.