Vibe Coding: Warum weniger oft mehr ist (und wie wir die Agentic Trap vermeiden)

Wir leben in einer Zeit, in der Entwickler dazu neigen, Komplexität mit Produktivität zu verwechseln. Wir bauen große Orchestrierungs-Setups für KI-Agenten, definieren unnötig komplexe Protokolle und starren auf Pull-Requests, anstatt endlich Software auszuliefern. Inspiriert von der Philosophie des „Agentic Engineering“ von Peter Steinberger (Creator von OpenClaw) haben wir analysiert, warum wir Komplexität radikal reduzieren müssen, um echte Geschwindigkeit zu erreichen.

Hier ist unser Weg aus der Komplexitätsfalle – und hin zu 600 Commits am Tag.

1. Die Flucht aus “Slop Town”

Viele Teams landen heute in der sogenannten Agentic Trap. Sie verbringen Wochen oder Monate damit, ausgeklügelte Tooling-Ökosysteme zu bauen: Bürgermeister, Beobachter, Unter-Agenten, Reaktionsketten. Steinberger nennt solche Konstrukte treffend „Slop Town“.

Das Problem: Diese Systeme erzeugen oft nur Slop – unnötigen Ballast – weil sie die wichtigste Komponente vergessen: menschlichen Geschmack und Vision. Mehr Agenten bedeuten nicht automatisch besseren Code.

Weniger Orchestrierung und direkterer Kontakt zum Modell führen oft deutlich schneller zum Ziel. Wir müssen aufhören, „Manager für unsere Agenten“ zu bauen, und anfangen, selbst wieder die Piloten zu sein.

2. Warum CLIs die modernen MCPs schlagen

Ein perfektes Beispiel für „weniger ist mehr“ ist die technische Schnittstelle. In vielen Teams gilt das Model Context Protocol (MCP) inzwischen als neuer Standard. Es lädt schnell riesige JSON-Objekte in den Kontext und führt regelmäßig zu „Context Rot“.

Unser Ansatz ist einfacher: einfache CLIs. Statt komplexer APIs reichen oft klare Terminal-Befehle. Ein Agent kann mit Unix-Tools wie curl oder jq gezielt filtern, statt dass ihm vorab ein schweres Modell-Datenpaket untergeschoben wird.

Die alte UNIX-Philosophie – Text rein, Text raus – gewinnt hier oft gegen aufgeblähte moderne Protokolle. Agenten sind hervorragend trainiert, Terminals zu bedienen.

3. „Prompt Requests“ sind die neuen Pull Requests

Traditionelle Prozesse werden bei uns zunehmend zum Flaschenhals: Warten auf CI/CD, auf menschliches Review und wiederkehrende Rückfragen.

Wir brauchen ein neues Modell:

• Code nicht immer lesen: Bei Routine-Aufgaben ist es oft unnötig, jede Zeile zu lesen. Entscheidend ist das Verständnis der Systemarchitektur.
• Vom PR zum Prompt Request: Ein Antrag auf Änderung beschreibt die Intention. Wenn ein Request klar ist, kann der Agent den Code prüfen, neu schreiben oder korrigieren.
• Loop schließen: Der Agent schreibt den Code, testet ihn lokal und verifiziert das Ergebnis selbst. Dann kann viel direkter in den main-Branch gemergt werden – ohne auf externe Review-Schleifen zu warten.

Das verändert die Geschwindigkeit massiv.

4. Das Setup: High-End-Minimalismus

Wie das Setup aussieht, ist überraschend simpel. Wir brauchen kein futuristisches Control-Panel, sondern einfach das Terminal.

• Kommandozentrale: Steinberger arbeitet oft mit zwei Macs parallel (Laptop plus Studio) und offenem Jump Desktop. In mehreren Terminal-Fenstern laufen 3 bis 8 Agenten-Sessions parallel – wie Teammitglieder, die unterschiedliche Aufgaben übernehmen.
• Tech-Stack: Für Web-Projekte nutzen wir vor allem TypeScript. Für CLIs nutzen wir bewusst Go – nicht aus Stylegründen, sondern weil es sich in solchen Kontexten extrem stabil schreibt und von Agenten sehr sauber gehandhabt wird.
• Standard-Modelle als Daily Driver: Statt exotischer Toolchains setzen wir auf GPT-5 Codex für harte Refactors und Claude Opus für kreative Passagen. Weniger Wrappers, weniger Reibung.

5. Do It Yourself: Die drei Regeln gegen den „Ralph Loop”

Wir müssen nicht auf teure Enterprise-Setups warten. Unsere Praxis zeigt: Diese drei Regeln verhindern teure und endlose Fehler-Fixing-Loops:

Regel 1: Bekämpfe Context Rot und MCP-Wahnsinn

Viele Modelle werden durch zu viele MCP-Server verwirrt und teuer im Kontextverbrauch. Unsere Lösung:

• Nutze CLIs statt schwerer Kontext-Overlays. Ein Agent kennt gh pr create oft besser als ein eigenes Dashboard.
• Cross-Referencing statt Wiedererklärungen: Statt dem Modell jedes Detail erneut zu erklären, verweisen wir auf bereits vorhandenen Code im Nachbarordner: „Sieh dir ../anderes-projekt an und implementiere das Logging genauso“.

Regel 2: Verhindere den Ralph Loop durch Dialog

Der klassische „Lauf, bis Tests grün sind“-Loop ist oft der teuerste Weg zum Burnout – für Geld und Zeit. Wenn das Modell den Kontext nicht versteht, fängt es an zu raten.

• Just Talk To It: Wir bleiben Pilot und fahren den Dialog so lange, bis die Richtung sitzt.
• Kein starres Plan Mode: Wir bauen den Plan im Chat und geben den konkreten Auftrag erst dann: „Build this“. So bleibt die KI auf dem Problem statt im Loop aus Endlosschleifen.

Regel 3: Nutze visuelle Kommunikation

Wir hören auf, CSS-Probleme nur mit Worten zu beschreiben.

• Screenshot statt Prompt-Flut: Ein Bild mit dem Hinweis „Fix padding“ spart oft 1000 Wörter und reduziert Missverständnisse dramatisch.
• Schnelleres Verstehen: Viele Probleme sind visuell lösbar, auch wenn die Formulierung im Chat stockt.

Fazit

Unsere Optimierung bedeutet nicht, mehr Tools hinzuzufügen. Wir entfernen die Barrieren zwischen Idee und Ausführung:

• weniger Bürokratie
• weniger komplizierte Protokolle
• weniger manuelles Coden

Die Aufgabe des Teams ist heute nicht, jede Zeile zu tippen. Sondern wie ein Bildhauer den Marmorblock zu bearbeiten: die Richtung vorgeben, Widerstände zu spüren und präzise zu steuern.

Wer das Terminal öffnet, Kontext sauber hält und einfach anfängt zu bauen, gewinnt.