Parallele Sessions und Subagents

Ein Entwickler kann mehrere Arbeitsströme gleichzeitig vorantreiben.

Eine parallele Session ist eine weitere vollständige Claude Code-Instanz, die eine separate Aufgabe in ihrem eigenen Git-Worktree bearbeitet. Jede unabhängige Session weiß nichts von den anderen, und der Entwickler, der sie steuert, ist das Einzige, was sie gemeinsam haben.

Ein Subagent läuft innerhalb einer einzelnen Session als abgegrenzter Helfer mit eigenem Kontextfenster und eigenen Tool-Limits und eignet sich für Aufgaben, die in mehreren Tasks wiederkehren, wie etwa die Überprüfung, ob die App wie erwartet läuft.

Parallele Sessions erhöhen die Anzahl der Aufgaben, die ein Entwickler gleichzeitig bearbeiten kann, während Subagents jede Session auf ihre eigene Aufgabe fokussiert halten. Die Aufgabe des Entwicklers besteht darin, sie alle zu steuern und zu überprüfen.

Was sich ändert

Erste Schritte

• Voraussetzungen: Die CLAUDE.md, da alle Sessions die Datei lesen. Die Feedback-Schleife (Stufe 4: Testen) hilft hier ebenfalls, da weniger Aufsicht durch den Entwickler nötig ist, wenn eine Session ihre eigene Arbeit überprüfen kann.
• Infrastruktur: Ein Git-Repository, da die Isolation von Worktrees kommt, sowie Berechtigungseinstellungen, die so abgestimmt sind, dass Sessions nicht auf Freigabeaufforderungen für Befehle warten, die die Organisation als sicher einstuft.

So setzt du es um

1. Der Entwickler teilt die Arbeit in Aufgaben auf, die unterschiedliche Dateien betreffen, und nutzt dabei den Plan aus dem Plan-Modus-Play (Stufe 3: Erstellen), um zu erkennen, wo die Arbeit unabhängig ist. Aufgaben, die sich Dateien teilen, laufen nacheinander in einer einzigen Session.
2. Jede parallele Aufgabe erhält ihren eigenen Worktree, zum Beispiel claude --worktree feature-auth in einem Terminal und claude --worktree fix-rate-limit in einem anderen. Ein Worktree ist ein separater Checkout auf einem eigenen Branch, wodurch verhindert wird, dass Sessions bei Dateien kollidieren.
3. Zwei oder drei Sessions sind ein sinnvoller Ausgangspunkt. Die praktische Obergrenze ist, wie viele Streams eine Person ordentlich überprüfen kann, also füge nur so lange weitere Sessions hinzu, wie das Review mithalten kann.
4. Verwandle wiederkehrende Jobs in Subagents, definiert in Markdown-Dateien unter .claude/agents/, jeweils mit einem Namen, einer Beschreibung, wann er zu verwenden ist, und den Tools, auf die er zugreifen darf. Beispiele sind ein Code-Simplifier, der unnötige Komplexität entfernt, nachdem der Hauptagent fertig ist, ein Verifier, der die App ausführt und das Verhalten prüft, sowie ein Researcher, der die Codebase erkundet und zurückmeldet, ohne den Hauptkontext zu überfluten. Committe die Definitionen in Git, damit das gesamte Team sie gemeinsam nutzt.

So sieht es aus

.claude/agents/verifier.md:

---

name: verifier
description: Runs the app and checks the change works before the session reports done
tools: Bash, Read

---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

Governance-Überlegungen

Mehr Sessions bedeuten mehr Output, daher müssen die Kontrollen aus der Konfiguration im Repo kommen. Hooks und Berechtigungseinstellungen dort gelten für alle Sessions, und was eine Session tut, wird protokolliert und dem Entwickler zugeordnet, der sie ausgeführt hat.

Wie man es misst

• Frühindikator: Gleichzeitige Sessions pro Entwickler, solange die Review-Qualität stabil bleibt, gezählt aus dem OpenTelemetry-Export, sowie der Anteil des Tages, der mit Steuern statt Warten verbracht wird.
• Spätindikator: Pro Woche und Entwickler gemergte Änderungen, betrachtet zusammen mit der Nacharbeitsrate, wie sie aus der PR-Historie ermittelt wird.