Parallel entwickeln mit KI-Agenten:
Git Worktrees als Produktivitätsmultiplier

Der blinde Fleck der meisten Entwickler

Es gibt einen Workflow-Fehler, den fast jeder Entwickler macht, der zum ersten Mal mit KI-Coding-Agenten arbeitet: Er startet einen Agenten, wartet bis dieser fertig ist, reviewed das Ergebnis, merged – und startet dann den nächsten Agenten. Seriell. Nacheinander. Als wäre Zeit keine Ressource.

Das klingt vernünftig. Es fühlt sich ordentlich an. Und es verschwendet den größten Teil des Produktivitätspotenzials, das KI-Agenten bieten.

Simon Willison, einer der profiliertesten KI-Tooling-Forscher der Branche, hat dieses Problem im Oktober 2025 präzise beschrieben: Während ein Agent an Task A arbeitet, wartet dein Rechner, wartet die API-Verbindung, wartet das nächste Ticket. In der Zeit, in der ein Agent zehn Minuten an einem Feature baut, könnte ein zweiter Agent bereits das nächste Feature halb fertig haben. Serielles Arbeiten halbiert den Output nicht – es drittelt ihn.

Die Lösung ist konzeptionell simpel: Starte mehrere Agenten parallel. Die technische Herausforderung dahinter ist, wie man das tut, ohne dass sich die Agenten gegenseitig in die Quere kommen – in denselben Dateien schreiben, dieselben Branches überschreiben, Merge-Konflikte erzeugen, die mehr Zeit kosten als die gewonnene Parallelität einsparen würde.

Git Worktrees lösen genau dieses Problem. Und Claude Code hat dafür eine native Integration gebaut.

Was sind Git Worktrees?

Git Worktrees sind ein oft übersehenes Feature von Git, das seit Version 2.5 (2015) im Core enthalten ist – aber erst durch die KI-Agenten-Welle seinen Durchbruch als Produktivitätswerkzeug erlebt. Die Grundidee: Ein Git-Repository kann mehrere Arbeitsverzeichnisse gleichzeitig haben.

Normalerweise hat ein Repository genau ein Arbeitsverzeichnis – den Ordner, in dem du deine Dateien siehst und bearbeitest. Alles andere lebt in der .git-Datenbank. Mit Worktrees kannst du dieses Arbeitsverzeichnis beliebig oft „auschecken" – jedes auf einem eigenen Branch, in einem eigenen Ordner auf deinem Dateisystem. Dabei teilen sich alle Worktrees dieselbe .git-Datenbank.

Der entscheidende Unterschied zu einem frischen Clone

Viele Entwickler lösen das Problem der Parallelarbeit, indem sie das Repository mehrfach klonen. Das funktioniert – aber es hat erhebliche Nachteile:

• Jeder Clone dupliziert die gesamte .git-Datenbank. Bei großen Repos (100 MB+) kostet das Zeit und Speicher.
• Commits in Clone A sind in Clone B erst nach einem git fetch und git pull sichtbar.
• Es ist einfach, den Überblick zu verlieren, welcher Clone welchen Stand hat.
• Node Modules, Python Virtual Environments, Build-Artefakte – alles wird dupliziert, sofern nicht sorgfältig konfiguriert.

Mit Worktrees erstellt Git lediglich ein neues Arbeitsverzeichnis, das auf einen Branch zeigt. Die gesamte Objekt-Datenbank (Commits, Blobs, Trees) existiert weiterhin nur einmal. Ein neuer Worktree ist in Sekunden angelegt – egal ob das Repo 10 MB oder 10 GB groß ist.

Die drei wichtigsten Worktree-Befehle

# Neuen Worktree anlegen (erstellt Branch feature/payment-api und Ordner ../repo-payment)
git worktree add ../repo-payment feature/payment-api

# Neuen Worktree aus einem bestehenden Remote-Branch
git worktree add ../repo-auth -b feature/auth-refactor origin/main

# Alle aktiven Worktrees anzeigen
git worktree list

# Worktree entfernen (nach erfolgtem Merge)
git worktree remove ../repo-payment

# Prunen: veraltete Worktree-Referenzen bereinigen
git worktree prune

Die Ausgabe von git worktree list zeigt alle aktiven Verzeichnisse auf einen Blick:

/home/user/mein-projekt              a3f9b21  [main]
/home/user/mein-projekt-payment      8c4d032  [feature/payment-api]
/home/user/mein-projekt-auth         1e7f994  [feature/auth-refactor]
/home/user/mein-projekt-tests        9a2c551  [feature/test-coverage]

Claude Code's nativer Worktree-Support

Was Git Worktrees von einem nützlichen Tool zu einem echten Produktivitätsmultiplier macht, ist die native Integration in Claude Code – Anthropics CLI für den Einsatz von Claude als Coding-Agent. Claude Code hat zwei Flags, die speziell für den parallelen Worktree-Workflow gebaut wurden:

# Claude Code startet in einem neuen Worktree (isolierter Branch)
claude --worktree

# Claude Code + tmux: Agent läuft in einem dedizierten tmux-Pane
claude --worktree --tmux

Was passiert, wenn du claude --worktree aufrufst? Claude Code:

1. Legt automatisch einen neuen Worktree an – mit einem sauber generierten Branch-Namen basierend auf deiner Task-Beschreibung.
2. Startet die Claude-Session in diesem isolierten Arbeitsverzeichnis.
3. Alle Änderungen des Agenten landen auf diesem Branch, nicht auf main.
4. Nach Abschluss der Task kannst du reviewen, anpassen und mergen – oder den Worktree verwerfen.

Das --tmux-Flag fügt eine weitere Ebene hinzu: Jeder Agent bekommt ein eigenes tmux-Pane in deinem Terminal. Du kannst zwischen den laufenden Agenten wechseln, den Fortschritt beobachten und bei Bedarf eingreifen – alles in einem einzigen Terminalfenster.

# Typischer paralleler Workflow: 3 Agenten gleichzeitig starten
# Terminal 1: Feature A
claude --worktree "Implementiere Payment-Integration mit Stripe"

# Terminal 2: Feature B (gleichzeitig starten)
claude --worktree "Refactore Auth-Modul auf JWT"

# Terminal 3: Tests (gleichzeitig starten)
claude --worktree "Erhoehe Test-Coverage auf 80% fuer User-Service"

# Oder alles in einer tmux-Session:
claude --worktree --tmux "Implementiere Payment-Integration mit Stripe"

Architektur-Diagramm: So sieht paralleles Arbeiten aus

Das folgende Diagramm zeigt, wie ein zentrales Repository auf mehrere Worktrees aufgeteilt wird, jeder mit einem eigenen Agenten – und wie die Ergebnisse zurück in main fließen:

3 konkrete Einsatzszenarien

Szenario 1: Parallele Feature-Entwicklung

Das naheliegendste Szenario – und der häufigste Anwendungsfall in Entwicklerteams, die parallel mit KI-Agenten arbeiten. Du hast mehrere Tickets im Sprint: Feature A, Feature B, ein Bugfix in einem unabhängigen Modul. Normalerweise würde ein Entwickler diese nacheinander abarbeiten, oder das Team würde Tasks aufteilen.

Mit parallelen Agenten startest du alle drei Tasks gleichzeitig:

# Task 1: Payment-Integration (in Terminal 1)
cd /workspace/mein-projekt
claude --worktree "Implementiere Stripe-Webhook-Handler fuer Subscription-Events.
Anforderungen:
- POST /webhooks/stripe empfangen
- Events: customer.subscription.updated, invoice.payment_failed
- Logging in Tabelle webhook_events
- Retry-Logik bei DB-Fehler"

# Task 2: Auth-Refactoring (in Terminal 2, gleichzeitig)
cd /workspace/mein-projekt
claude --worktree "Refactore src/auth/ von Session-Cookies auf JWT.
Alle bestehenden Tests muessen weiterhin gruenen.
Neue Tests fuer Token-Refresh-Flow erwartet."

# Task 3: Datenbank-Migration (in Terminal 3, gleichzeitig)
cd /workspace/mein-projekt
claude --worktree "Erstelle DB-Migration fuer neue user_preferences Tabelle.
Schema: user_id (FK), key VARCHAR(64), value JSONB, updated_at.
Inklusive Rollback-Script."

Während du einen Kaffee holst oder das nächste Meeting vorbereitest, laufen alle drei Agenten parallel. Wenn du zurückkommst, hast du drei Pull Requests, die reviewed und gemerged werden können. Bei einer durchschnittlichen Laufzeit von 8–15 Minuten pro Task hast du statt 45 Minuten seriellem Warten nur einmal 15 Minuten gewartet.

Wichtig: Die Tasks müssen wirklich unabhängig sein. Payment-Integration und Auth-Refactoring berühren unterschiedliche Module – das ist ideal. Würden beide Agenten an src/middleware/auth.ts arbeiten, wären Merge-Konflikte vorprogrammiert.

Szenario 2: Modellvergleich – Claude Opus 4.8 vs. Codex vs. GPT-5.5

Ein besonders mächtiges Szenario: Du sendest dieselbe Task an drei verschiedene Modelle gleichzeitig und vergleichst die Ergebnisse. Das klingt ineffizient – ist es aber nicht, wenn du eine komplexe Implementierungsentscheidung vor dir hast und wissen willst, welcher Ansatz der beste ist.

Praktisches Beispiel: Du musst eine Caching-Strategie für eine hochfrequentierte API implementieren. Redis? In-Memory LRU? Edge Caching? Drei Modelle, drei Ansätze – du reviewst die Unterschiede und wählst das Beste:

# Worktrees anlegen
git worktree add ../project-cache-claude  -b experiment/cache-claude
git worktree add ../project-cache-codex   -b experiment/cache-codex
git worktree add ../project-cache-gpt     -b experiment/cache-gpt

# Agenten starten (verschiedene Modelle, gleiche Task)
cd ../project-cache-claude && claude --model opus "Implementiere Caching fuer GET /api/products..."
cd ../project-cache-codex  && codex "Implementiere Caching fuer GET /api/products..."
cd ../project-cache-gpt    && gpt-code "Implementiere Caching fuer GET /api/products..."

# Ergebnisse vergleichen
git diff experiment/cache-claude experiment/cache-codex -- src/cache/
git diff experiment/cache-claude experiment/cache-gpt   -- src/cache/

Was du dabei regelmäßig beobachten wirst: Die Modelle wählen unterschiedliche Abstraktionsebenen. Claude Opus 4.8 tendiert zu vollständigeren Implementierungen mit Fehlerbehandlung und Tests. Codex produziert oft kompakteren Code, der dichter an den bestehenden Patterns des Repositories ist. GPT-5.5 glänzt häufig mit durchdachten Typen und Interfaces.

Das Ergebnis ist keine Frage von „welches Modell ist besser", sondern welcher Ansatz zu dieser konkreten Codebase, diesem Team und diesen Anforderungen passt.

Szenario 3: Scout-Modus – Erkunden ohne Commitment

Der Scout-Modus ist ein Pattern, das Simon Willison in seinem Oktober-2025-Post beschrieben hat und das in der Praxis sehr wertvoll ist: Du schickst einen Agenten in einen Worktree, um eine Frage zu beantworten, ohne zu beabsichtigen, den Code zu mergen.

Typische Scout-Fragen:

• „Wie schwer wäre es, dieses Modul auf TypeScript 5.x zu migrieren?"
• „Welche Tests brechen, wenn wir die Datenbank-Verbindung auf Connection Pooling umstellen?"
• „Kann unser API-Layer GraphQL unterstützen, ohne die REST-Endpunkte zu brechen?"

# Scout-Worktree anlegen
git worktree add ../project-scout -b scout/typescript-migration

# Agent erkundet – kein Merge geplant
cd ../project-scout
claude "Versuche, src/api/ auf TypeScript 5.5 zu migrieren.
Schreibe am Ende eine Zusammenfassung:
- Wie viele Dateien muessen geaendert werden?
- Welche Breaking Changes gibt es?
- Schaetzung: wie viele Stunden manuelle Arbeit?
Du musst NICHT alles reparieren, nur erkunden und berichten."

# Nach dem Scout: Ergebnis lesen, dann Worktree entfernen
cat SCOUT_REPORT.md
git worktree remove ../project-scout

Der entscheidende Vorteil: Der Scout-Agent kann und darf Fehler machen, unvollständige Implementierungen hinterlassen, Tests brechen – das ist Absicht. Das Ergebnis ist nicht mergefähiger Code, sondern eine Aufwandsschätzung und ein Risikoassessment. Für Planungsgespräche und Sprint-Schätzungen ist das unschätzbar wertvoll.

Quick-Start Guide: In 10 Minuten zum parallelen Workflow

Hier ist der vollständige Schritt-für-Schritt-Guide, um sofort mit parallelen KI-Agenten auf Worktrees zu starten:

Schritt 1: Repository vorbereiten

# Stelle sicher, dass main sauber ist
git checkout main
git pull origin main
git status  # keine uncommitted Changes!

Schritt 2: Worktrees anlegen

# Ordern: [parent-dir]/[repo]-[ticket-id]
git worktree add ../mein-projekt-123 -b feature/TICKET-123
git worktree add ../mein-projekt-124 -b feature/TICKET-124
git worktree add ../mein-projekt-125 -b feature/TICKET-125

# Alle Worktrees pruefen
git worktree list

Schritt 3: .env-Dateien kopieren

# .env ist in .gitignore – manuell kopieren
cp mein-projekt/.env ../mein-projekt-123/.env
cp mein-projekt/.env ../mein-projekt-124/.env
cp mein-projekt/.env ../mein-projekt-125/.env

# Optional: Skript fuer automatisches Setup
cat > setup-worktree.sh << 'EOF'
#!/bin/bash
WT_PATH=$1
cp .env "$WT_PATH/.env"
echo "Worktree $WT_PATH bereit."
EOF
chmod +x setup-worktree.sh

Schritt 4: Agenten parallel starten

# Option A: Separate Terminals
# Terminal 1:
cd ../mein-projekt-123 && claude "TICKET-123: ..."
# Terminal 2:
cd ../mein-projekt-124 && claude "TICKET-124: ..."
# Terminal 3:
cd ../mein-projekt-125 && claude "TICKET-125: ..."

# Option B: tmux (alle in einem Fenster)
tmux new-session -d -s agents
tmux send-keys -t agents "cd ../mein-projekt-123 && claude --worktree 'TICKET-123...'" Enter
tmux split-window -h
tmux send-keys -t agents "cd ../mein-projekt-124 && claude --worktree 'TICKET-124...'" Enter
tmux split-window -v
tmux send-keys -t agents "cd ../mein-projekt-125 && claude --worktree 'TICKET-125...'" Enter
tmux attach -t agents

Schritt 5: Review und Merge

# Diff reviewen bevor du mergst
cd ../mein-projekt-123
git diff main...HEAD

# Tests laufen lassen
npm test

# Zum main-Repo zurueck und mergen
cd mein-projekt
git merge feature/TICKET-123
git merge feature/TICKET-124
git merge feature/TICKET-125

# Worktrees aufraeumen
git worktree remove ../mein-projekt-123
git worktree remove ../mein-projekt-124
git worktree remove ../mein-projekt-125
git worktree prune

Best Practices und haeufige Fallstricke

Wie das mit OpenClaw funktioniert

Wer OpenClaw als Agenten-Framework einsetzt, bekommt native Unterstützung für parallele Worktree-Workflows – und deutlich mehr Komfort als beim manuellen Ansatz mit Claude Code CLI.

OpenClaw hat seit Version 0.8 einen eingebauten Worktree Dispatcher, der Tasks automatisch auf verfügbare Worktrees verteilt. Das Grundprinzip:

1. Task Queue: Du übergibst mehrere Tasks an OpenClaw. Der Dispatcher ordnet sie nach Abhängigkeiten und Ressourcenkonkurrenz.
2. Automatisches Worktree-Management: OpenClaw legt Worktrees an, kopiert .env-Dateien und konfiguriert den korrekten Branch automatisch.
3. Parallelisierung: Unabhängige Tasks laufen gleichzeitig. Abhängige Tasks warten auf ihre Voraussetzungen.
4. Review Dashboard: Alle Ergebnisse landen in einem zentralen Review-Interface – Du siehst den Diff, kannst Feedback geben und mit einem Klick mergen oder ablehnen.
5. Cleanup: Nach dem Merge werden Worktrees automatisch entfernt und Branches bereinigt.

# OpenClaw parallele Task-Queue
openclaw dispatch \
  --task "TICKET-123: Payment Integration" \
  --task "TICKET-124: Auth Refactoring" \
  --task "TICKET-125: DB Migration" \
  --parallel \
  --model claude-opus-4-8 \
  --review-before-merge

# OpenClaw startet 3 Worktrees automatisch und zeigt Dashboard
> Dispatching 3 tasks to parallel worktrees...
> worktree-1 [feature/ticket-123]: RUNNING (Claude Opus 4.8)
> worktree-2 [feature/ticket-124]: RUNNING (Claude Opus 4.8)
> worktree-3 [feature/ticket-125]: RUNNING (Claude Opus 4.8)
> Open dashboard: http://localhost:8080/review

Für Enterprise-Teams, die OpenClaw on-premises betreiben, bietet Clawgency zusätzlich ein zentrales Monitoring-System, das alle parallelen Agenten-Aktivitäten in Echtzeit sichtbar macht – inklusive Token-Verbrauch, Laufzeiten und Audit-Log für DSGVO-Compliance.

FAQ: Alle Fragen zu parallelen KI-Agenten mit Git Worktrees