Agentic Engineering in der Praxis: Parallele KI-Terminals, Git Worktrees und die Realität professioneller KI-Workflows

Dieser Beitrag ist ein ausführliches Tutorial basierend auf dem Video “The Agentic Engineer Workflow You Need In 2026” von Zen van Riel. Das vollständige Video findest du hier:

Zen van Riel hat KI-Code in echten Engineering-Teams ausgeliefert. Enterprises, Startups, mit Code-Reviews, Produktionsnutzern und voller Verantwortung für alles, was gemergt wird. In diesem Video zeigt er seinen konkreten Workflow, der auf echten Engineering-Praktiken basiert. Keine Theorie, keine Hype-Methoden. Ein praxiserprobter Prozess.

Schritt 1: Vier parallele Terminals einrichten

Der erste Schritt im Workflow ist das Aufsetzen der Arbeitsumgebung. Zen van Riel startet mit einem einzigen Shortcut vier Cloud-Code-Fenster gleichzeitig:

# Shortcut 't' startet vier Cloud-Code-Fenster
t

Die vier Fenster sind nicht identisch konfiguriert. Sie haben unterschiedliche Effort-Level:

• Oben links → High Effort: Komplexe Planungsaufgaben, große Batches
• Oben rechts → High Effort: Parallele umfangreiche Implementierung
• Unten links → Medium Effort: Mittlere Aufgaben, gezielte Recherche
• Unten rechts → Low Effort: Schnelle Fragen, Codebase-Exploration

Die Logik dahinter: Manche Aufgaben benötigen tiefe Analyse und viel Token-Budget. Andere sind einfache Informationsfragen, die in Sekunden beantwortet werden sollen. Wer alles auf High stellt, wartet unnötig lang auf triviale Antworten.

Ein konkretes Beispiel aus dem Video: Im High-Effort-Terminal oben links wird eine kreative Planungsaufgabe gestartet:

scope out five potential features we can work on

Diese Aufgabe läuft lange. Währenddessen stellt er im Low-Effort-Terminal unten rechts eine einfache Frage:

explore the codebase to tell me which languages are used

Innerhalb weniger Sekunden kommt die Antwort: Java, Python, HTML und etwas SQL. Das High-Effort-Terminal arbeitet noch. Genau diese Parallelisierung macht den Unterschied.

Warum genau vier Terminals? Zen van Riel hat nach mehreren größeren Projekten festgestellt, dass vier parallele Arbeitsströme das kognitive Maximum für einen einzelnen Entwickler sind. Wer behauptet, 50 Agenten gleichzeitig zu steuern, verliert die Kontrolle über den Output. Das widerspricht direkt dem Grundprinzip des agentischen Codings: Wer die Aufsicht verliert, verliert die Qualität.

Schritt 2: Kontextfenster aktiv managen

Jedes Cloud-Code-Terminal zeigt in der Statusleiste die aktuelle Kontextfenster-Auslastung an. Diese Information ist kritisch.

Wenn sich das Kontextfenster füllt, passieren zwei Dinge gleichzeitig. Die KI wird langsamer. Und die KI beginnt vom ursprünglichen Kontext der Konversation abzudriften. Alte Kontexte, verworfene Ansätze und überholte Anweisungen sedimentieren sich. Das Modell verliert den Fokus.

Die Lösung: Kontextfenster bewusst zurücksetzen.

# Kontext komprimieren, Kerninfos bleiben erhalten
/compact

# Konversation komplett zurücksetzen
/clear

Es gibt keine magische Regel, wann welcher Befehl der richtige ist. Das hängt von der Projektkomplexität und dem aktuellen Arbeitsschritt ab. Genau das ist der Punkt des agentischen Engineerings. Du entwickelst ein Gespür dafür, wann der Kontext zu verrauscht wird. Dieses Gespür entsteht nur durch Praxis.

Schritt 3: Hype-Methoden ignorieren, Prinzipien anwenden

Zen van Riel positioniert sich klar gegen kurzlebige Methodiken. Warum spricht er nicht über Spec-Driven Development, die BMAT-Methode oder die Unterscheidung zwischen Context Engineer, Font Engineer und Agentic Engineer?

Weil die meisten dieser Konzepte Gimmicks sind, die den Praxistest nicht überleben. Er verweist auf die Halbwertszeit von KI-Projekten der letzten drei Jahre. Die wenigsten sind heute noch relevant.

Seine Regel: Alles, was drei bis vier Monate im praktischen Einsatz überlebt, ist vermutlich ein solides Pattern. Alles andere ist Hype. Und gute Patterns werden ohnehin in die Tools integriert. Beispiel: Cloud Code hat mittlerweile ein eingebautes To-Do-Tracking. Die Notwendigkeit, das manuell mit Markdown-Dateien zu organisieren, entfällt.

Das Video zeigt ausschließlich Prinzipien, die in sechs Monaten noch relevant sein werden. Diese Haltung deckt sich mit der Erkenntnis, dass zeitlose Fundamente wichtiger sind als aktuelle Tools.

Schritt 4: Code-Qualität durch Engineering-Pattern-Commands sichern

In professionellen Teams ist Code-Qualität nicht optional. Wenn du 10.000 Zeilen Code pro Stunde produzierst, wird niemand diesen Code reviewen können. Entweder schickt dich das Team zurück, um kleinere Pull Requests zu erstellen, oder alle leiden unter Langzeitbugs durch überhastet generierten KI-Code.

Zen van Riel nutzt einen eigenen smell-Command. Dieser Command basiert auf etablierten Engineering-Patterns aus Büchern wie Clean Code und den klassischen Architektur-Design-Patterns.

# Prüft den aktuellen Code auf Code Smells
# basierend auf Clean Code und Design Patterns
/smell

Der Command erinnert das Sprachmodell aktiv an Konzepte aus diesen Engineering-Büchern. Das ist effektiver als generische Prompts wie “Du bist ein Senior Engineer. Code und mache keine Fehler.”

Seine Position dazu ist eindeutig: Man kann Prompt-Repositories mit 60.000 Stars auf GitHub kopieren. Oder man wendet die Patterns aus bewährten Engineering-Büchern an, die bereits genutzt wurden, um die beste Software der Welt zu bauen.

Schritt 5: KI-Code-Reviews einrichten

Zen van Riel verbindet GitHub mit verschiedenen KI-Code-Review-Plattformen. Ob das eine gehostete Lösung wie Cloud Code Reviews ist oder eine selbstgebaute Pipeline, die Code automatisch im Headless-Modus von CodeX prüft, ist zweitrangig.

Wichtig sind zwei Punkte:

1. Es gibt mindestens eine automatisierte KI-Review in jedem Pull Request.
2. Die KI-Review ersetzt niemals die menschliche Review.

Er teilt seine konkreten Review-Commands nicht öffentlich. Der Grund: Es gibt keinen universellen Review-Command. Der richtige Command hängt ab von der Programmiersprache, der Komplexität der Arbeit, der Anzahl der menschlichen Reviewer, deren Präferenzen und dem vereinbarten Code-Style des Teams.

Das ist eine zentrale Erkenntnis für jeden, der agentisches Coding professionell betreibt: One-size-fits-all existiert nicht.

Schritt 6: Externe Dienste über CLI statt MCP verbinden

Für die Anbindung externer Dienste demonstriert Zen van Riel einen pragmatischen Ansatz. Er nimmt eine GitHub-URL und sagt zu Cloud Code:

create a test issue in this URL

Cloud Code kennt die GitHub CLI bereits. Die Authentifizierung läuft über das GitHub CLI, das separat eingerichtet wurde. Kein zusätzlicher Authentifizierungsmechanismus nötig.

Wann Bash, wann MCP?

Die Entscheidung zwischen Bash-Tools und MCP-Servern ist eine Frage des Kontexts:

Bash-Tools eignen sich für:

• Gängige Plattformen mit etablierten CLIs wie gh issue create für GitHub oder aws für AWS
• Direkte API-Anfragen über curl oder wget
• Einmalige Scripts wie python3 scripts/check-deployment.py für komplexere Abläufe

MCP-Server eignen sich für:

• Interne Diagnosesysteme ohne standardisiertes CLI
• Spezialisierte Backends wie Context7 (zieht aktuelle Framework-Dokumentation in optimiertem Format)
• Language-Server-Integration wie Serena (macht Suchoperationen im Code effizienter)

Zen van Riels Faustregel: Wenn die Plattform eine etablierte CLI hat (GitHub, Jira, AWS), reicht Bash. Wenn du einen Coding-Agenten mit unbekannten internen Diensten verbinden willst, kann ein MCP-Server sinnvoll sein. Aber auch hier gilt: Für eine einzelne, einfache Operation ist Bash fast immer die bessere Wahl.

Speziell zu Context7 erwähnt er, dass die Web-Suche in Cloud Code zwar funktioniert, aber generisch ist. Context7 durchsucht die Dokumentation gezielt und liefert sie dem Sprachmodell im effizientesten Format. Das ist ein messbarer Unterschied bei Framework-spezifischen Fragen.

Schritt 7: Git Worktrees für konfliktfreie Parallelarbeit

Hier wird es technisch interessant. Alle vier Cloud-Code-Terminals teilen sich denselben Git-Kontext. Wenn ein Terminal den Branch wechselt, betrifft das alle anderen.

Zen van Riel demonstriert das Problem live. Er lässt Cloud Code in einem Terminal einen Branch auschecken:

git checkout -b random-branch-name

Die Statusleiste aller Terminals aktualisiert sich sofort auf den neuen Branch. Das funktioniert bei trivialem Parallelarbeiten, wird aber bei ernsthafter Arbeit schnell chaotisch.

Die Lösung: Git Worktrees.

# Neuen Worktree erstellen
git worktree add ../worktrees/feature-auth feature-auth

# In den Worktree wechseln (Cloud Code erkennt das)
cd ../worktrees/feature-auth

# Alle aktiven Worktrees auflisten
git worktree list

Ein Git Worktree erstellt eine unabhängige Arbeitskopie des Repositories. Jedes Terminal kann in einem eigenen Worktree arbeiten, ohne die anderen zu beeinflussen. Das ist besonders wertvoll, wenn du Cloud Code drei verschiedene Ansätze für dasselbe Problem generieren lässt.

# Drei Worktrees für Parallelvergleich
git worktree add ../worktrees/approach-a approach-a
git worktree add ../worktrees/approach-b approach-b
git worktree add ../worktrees/approach-c approach-c

Nach Abschluss der Arbeit müssen die Worktrees wieder entfernt werden. Die Festplatte soll nicht mit Kopien des Repositories volllaufen:

# Worktree entfernen
git worktree remove ../worktrees/approach-a

# Oder Cloud Code direkt beauftragen
# "exit and delete the WT"
# Cloud Code versteht den Kontext und räumt auf

Ein wichtiger Hinweis: Je nach Programmiersprache und Projektstruktur müssen nach dem Erstellen eines Worktrees die Projektabhängigkeiten neu installiert werden. Zen van Riel empfiehlt, dafür einen eigenen Skill oder Command zu erstellen, der bei jeder Worktree-Erstellung automatisch ausgeführt wird.

# Beispiel: Post-Worktree-Setup-Script
#!/bin/bash
npm install  # oder pip install -r requirements.txt
cp .env.example .env

Die Realität: Produktivitätsgewinne und professionelle Verantwortung

Zen van Riel spricht offen über seine Erfahrungen als Freelancer, bei Startups und in Enterprises. Die Realität ist in jedem Kontext anders.

Freelancing und Proof of Concepts

Als Freelancer bei MVPs und Proof of Concepts fühlt sich KI-Coding wie Superkraft an. Man pusht massiv Code, hat wenig Verantwortung gegenüber einem Entwicklerteam und kann bei Bugs einfach einen Fix vibe-coden. Das funktioniert, aber es ist nicht nachhaltig.

Im professionellen Team

In einem Entwicklerteam gelten andere Regeln. Jeder Code braucht Reviews. Wenn du täglich 10.000 Zeilen Code in Pull Requests einreichst, passiert eines von zwei Dingen: Das Team schickt dich zurück. Oder alle leiden unter Langzeitbugs.

Zen van Riel teilt eine persönliche Erfahrung. Er hat in einem komplexen Repository ein komplett neues Feature in nur zwei Tagen erstellt. Der Plan: Pull Request erstellen, Ende der Woche gemergt. Das Ergebnis: erheblicher Pushback von erfahreneren Engineers. Der Code war funktional, aber es fehlte das architektonische Langzeitdenken.

Als er den Code zum ersten Mal wirklich las statt ihn nur zu überfliegen, musste er dem erfahrenen Engineer Recht geben. Der Code verfehlte das größere Bild und hätte langfristig Bugs verursacht. Genau dieses Muster des blinden Durchwinkens ist die zentrale Falle des Vibe-Codings, bei der sieben Monate unkontrollierter KI-Code in 1.690 Zeilen God-Object enden können.

Realistische Zahlen

Die Entwickler, die am meisten von agentischem Coding profitieren, schreien nicht von den Dächern, dass sie fünfmal produktiver sind. Die realistischen Produktivitätsgewinne liegen bei 30 bis 60 Prozent. In bestimmten Fällen, etwa bei einmaligen Scripts für Produktionstests, kann es schneller gehen. Aber im Durchschnitt sind die Gewinne solide, nicht revolutionär.

Das deckt sich mit einer zentralen Erkenntnis: Der Coding-Anteil der Engineering-Arbeit wird kleiner. Das bedeutet nicht, dass Entwickler keine Arbeit mehr haben. Engineering ist weit mehr als Coding. Aber die Verteilung der täglichen Arbeitszeit verschiebt sich.

Mindset: Vibe Coder oder AI-Native Engineer?

Zen van Riel stellt die entscheidende Frage: Was für ein Engineer willst du sein?

Ein Vibe Coder pusht tausende Zeilen KI-Code täglich in die Produktion. Die Geschwindigkeit fühlt sich gut an, solange nichts bricht.

Ein AI-Native Engineer nutzt die Produktivitätsgewinne der KI, weiß aber auch, wann Systeme wirklich kaputtgehen und kann den gesamten Stack beherrschen.

Agentisches Engineering ist keine Tool-Frage. Es ist eine Haltungsfrage. Welche Antwort du gibst, bestimmt die Qualität deiner Software und die Nachhaltigkeit deiner Karriere.

Zusammenfassung: Der Workflow als Checkliste

1. Vier Terminals mit unterschiedlichen Effort-Leveln aufsetzen.
2. Kontextfenster aktiv überwachen und rechtzeitig zurücksetzen.
3. Engineering-Pattern-Commands statt generischer Prompts verwenden.
4. KI-Reviews automatisieren, aber immer mit menschlicher Review kombinieren.
5. CLI-Tools für gängige Plattformen nutzen, MCP-Server für spezialisierte interne Dienste.
6. Git Worktrees für konfliktfreie Parallelarbeit einrichten.
7. Code lesen, nicht nur Diffs überfliegen.
8. Pull Requests klein halten und architektonisches Langzeitdenken bewahren.
9. Hype-Methoden ignorieren und auf bewährte Engineering-Prinzipien setzen.