Die offizielle Claude-Code-Dokumentation nennt 4 GB Arbeitsspeicher als Mindestanforderung für einen einzelnen lokalen Agenten. Daraus folgt für Ihre Planung: Parallel AI Coding wird nicht durch möglichst viele Agents schnell, sondern durch klare Abhängigkeiten, getrennte Arbeitsbereiche und ein gemeinsames Prüfverfahren. Starten Sie mit zwei oder drei sauber definierten Aufgaben, nicht mit einer beliebigen Anzahl paralleler Terminals.
Diese Anleitung richtet sich an:
- unabhängige Entwickler, die von einem einzelnen Agenten auf parallele Entwicklung umsteigen möchten,
- kleine Entwicklungsteams, die die Lieferzeit eines Features verkürzen wollen,
- Plattformingenieure, die lokale, temporäre oder dauerhaft entfernte Arbeitsumgebungen dimensionieren müssen.
Vor dem Start: Prüfen Sie, ob Ihr Projekt überhaupt parallelisierbar ist
Der häufigste Fehler besteht darin, ein großes Ticket in mehrere Chat-Aufträge zu zerlegen, ohne die technischen Abhängigkeiten zu prüfen. Drei Agents können dann gleichzeitig dieselbe zentrale Datei ändern, widersprüchliche Schnittstellen erzeugen und am Ende mehr Abstimmungsarbeit verursachen als ein einzelner Agent.
Beginnen Sie deshalb mit einer Abhängigkeitskarte. Markieren Sie für jedes Teilproblem:
- welche Dateien gelesen werden müssen,
- welche Dateien geändert werden dürfen,
- welche Schnittstellen vorausgesetzt werden,
- welche Datenbank- oder API-Verträge betroffen sind,
- welche Tests den Abschluss bestätigen,
- welche Dateien für andere Aufgaben gesperrt bleiben.
Ein gutes Parallelpaket besitzt eine klare Eingangs- und Ausgangsbedingung. Beispiele sind eine isolierte REST-Ressource, ein eigenständiges Frontend-Modul, eine Testabdeckung für einen bestehenden Dienst oder eine Dokumentationsänderung ohne Einfluss auf die Laufzeit.
Ein schlechtes Parallelpaket lautet dagegen „Überarbeite die Authentifizierung“. Dieser Auftrag berührt wahrscheinlich Middleware, Datenmodelle, Tests, Konfiguration, Benutzeroberfläche und Sicherheitsregeln. Solange die Zielarchitektur nicht entschieden ist, sollte diese Arbeit seriell erfolgen.
Wie sollten Sie Aufgaben für Parallel AI Coding aufteilen?
Nutzen Sie eine einfache Aufteilung nach Änderungsgrenzen:
- Vertragsaufgabe: API-Schema, Typdefinitionen oder Datenmodell festlegen.
- Implementierungsaufgabe: Eine klar abgegrenzte Funktion anhand dieses Vertrags entwickeln.
- Testaufgabe: Unit-, Integrations- oder Regressionstests für einen bereits stabilen Vertrag ergänzen.
- Prüfaufgabe: Sicherheits-, Performance- oder Kompatibilitätsrisiken untersuchen.
- Dokumentationsaufgabe: Beispiele und Betriebsdokumentation aktualisieren.
Die Vertragsaufgabe sollte häufig vor den Implementierungsaufgaben abgeschlossen werden. Wenn Agent A eine neue Schnittstelle entwirft, während Agent B bereits die alte Schnittstelle implementiert, entsteht kein produktives Parallelmodell. In diesem Fall ist die richtige Entscheidung: erst den Vertrag einfrieren, dann die abhängigen Arbeiten starten.
Ein nützliches Stoppsignal lautet: Wenn zwei Aufgaben dieselbe zentrale Datei ändern müssen, ist eine zusätzliche Entkopplung nötig. Sie können zunächst eine neue Schnittstelle oder ein separates Modul anlegen. Wenn das nicht möglich ist, führen Sie diese Schritte nacheinander aus.
Die ersten 30 Minuten: Erstellen Sie einen gemeinsamen Task-Vertrag
Ein AI Coding Agent arbeitet nicht automatisch mit demselben Projektverständnis wie seine Kollegen. Derselbe Auftrag kann zu unterschiedlichen Annahmen über Testbefehle, Namenskonventionen oder erlaubte Dateien führen. Deshalb braucht jeder Agent einen kurzen, versionierten Arbeitsvertrag.
Legen Sie ihn beispielsweise in einer Datei wie AGENTS.md, CONTRIBUTING.md oder einem projektspezifischen Dokument ab. Der Name ist weniger wichtig als die gemeinsame Verfügbarkeit im Ausgangsstand des Repositorys.
Jeder Auftrag sollte mindestens diese Punkte enthalten:
- Ziel: Welches Verhalten soll nach der Änderung funktionieren?
- Erlaubte Pfade: Welche Verzeichnisse oder Dateien dürfen geändert werden?
- Verbotene Pfade: Welche Konfigurationen, Migrationen oder Geheimnisdateien bleiben unangetastet?
- Eingangsschnittstelle: Welche Typen, Endpunkte oder Datenstrukturen gelten als gegeben?
- Testbefehl: Welcher konkrete Befehl muss erfolgreich laufen?
- Definition of Done: Welche überprüfbaren Bedingungen markieren den Abschluss?
- Übergabe: Wo werden Commit, Testbericht und bekannte Einschränkungen dokumentiert?
Die Definition of Done muss ausführbar sein. „Code ist sauber“ reicht nicht. Besser ist: „Der neue Endpunkt antwortet mit dem vereinbarten Schema, die zuständigen Integrationstests laufen erfolgreich, und keine Datei außerhalb von src/billing/ wurde geändert.“
Versionieren Sie diesen Vertrag im selben Branch oder Commit, von dem alle Arbeitsbereiche ausgehen. So verhindern Sie, dass ein Agent mit einer alten Prompt-Version und ein anderer mit einer späteren Regel arbeitet.
Welche gemeinsamen Informationen dürfen nicht nur im Chat stehen?
Chatverläufe sind kein belastbares Projektprotokoll. Dokumentieren Sie deshalb pro Agent:
- Status: geplant, läuft, wartet, fehlgeschlagen oder bereit zur Prüfung,
- Branch-Name und Arbeitsverzeichnis,
- verwendete Eingangsversion,
- ausgeführte Testbefehle,
- Fehlermeldungen,
- erzeugte Artefakte,
- offene Entscheidungen.
Das kann zunächst eine einfache Markdown-Datei oder ein Eintrag im bestehenden Ticketsystem sein. Entscheidend ist, dass ein neuer Entwickler den Zustand ohne Zugriff auf den ursprünglichen Agenten-Chat nachvollziehen kann.
Die erste Stunde: Richten Sie für jeden Agenten einen isolierten Arbeitsbereich ein
Ein gemeinsamer Ordner mit mehreren gleichzeitig schreibenden Prozessen ist keine Parallelarchitektur. Jeder Agent benötigt mindestens eine eigene Branch und ein eigenes Arbeitsverzeichnis. Für lokale Entwicklung ist git worktree dafür oft die leichteste Lösung.
Die offizielle Git-Dokumentation zu git worktree beschreibt mehrere Arbeitsbäume für dasselbe Repository. Jeder Arbeitsbaum besitzt einen eigenen Checkout, eigene Index-Informationen und einen eigenen Arbeitszustand, während Git-Daten gemeinsam genutzt werden können. So vermeiden Sie, dass Agent A uncommitted Änderungen von Agent B überschreibt.
Ein mögliches lokales Grundmuster sieht so aus:
git fetch origin
git switch main
git pull --ff-only
git worktree add ../project-api -b agent/api origin/main
git worktree add ../project-tests -b agent/tests origin/main
git worktree add ../project-review -b agent/review origin/main
git worktree list
Die Verzeichnisnamen sollten die Aufgabe beschreiben, nicht nur eine Nummer enthalten. agent/api ist später nachvollziehbarer als agent-1.
Danach richten Sie in jedem Arbeitsbaum dieselbe Umgebung ein:
- Abhängigkeiten anhand der Lockdatei installieren.
- Die erlaubte Laufzeitversion prüfen.
- Den vorgesehenen Testbefehl einmal ohne Änderung ausführen.
- Lokale Dienste oder Container mit eindeutigen Ports starten.
- Prüfen, ob der Agent nur die vorgesehenen Pfade beschreiben und ändern kann.
- Den Ausgangszustand und mögliche Baseline-Fehler dokumentieren.
Git isoliert Branches und Dateien, aber nicht automatisch alle Seiteneffekte. Gemeinsame Datenbanken, Docker-Volumes, temporäre Dateien, Cache-Verzeichnisse und lokale Ports können weiterhin Konflikte erzeugen. Verwenden Sie deshalb pro Arbeitsbereich eigene Datenbanknamen oder temporäre Schemata, wenn Tests schreibend auf eine Datenbank zugreifen.
Benötigt jeder Agent eine eigene Entwicklungsumgebung?
Nicht immer eine eigene physische Maschine, aber einen eigenen kontrollierten Ausführungskontext. Für drei lokale Agents können getrennte git worktrees und getrennte Prozesse ausreichen, wenn der Build reproduzierbar ist und die Ressourcen nicht überlastet werden.
Eine stärkere Isolation ist sinnvoll, wenn:
- ein Agent beliebige Shell-Befehle ausführt,
- Abhängigkeiten inkompatible Versionen benötigen,
- Tests globale Systemressourcen verändern,
- vertrauliche Quelltexte oder Zugangsdaten beteiligt sind,
- Agents aus verschiedenen Vertrauensstufen stammen.
Für cloudbasierte oder entfernte Agents beschreibt die Dokumentation zu Cursor Background Agents isolierte Ubuntu-basierte Umgebungen, eigene Branches und automatisch ausgeführte Terminalbefehle. OpenHands unterscheidet in seiner Sandbox-Dokumentation zwischen Docker-, Prozess- und Remote-Sandboxes. Diese Optionen sind nicht gleichwertig: Ein Prozess-Sandbox-Modell ist schneller einzurichten, bietet aber keine Container-Isolation vom Host.
Sicherheitsregel: Kopieren Sie keine produktiven Zugangsdaten in einen Agenten-Arbeitsbereich. Nutzen Sie kurzlebige Tokens, minimale Rechte, getrennte Testkonten und eine explizite Netzwerkrichtlinie. Prüfen Sie ergänzend die Datenschutzinformationen von Kvmzen, bevor Sie Quellcode oder Konfigurationsdaten in eine entfernte Umgebung übertragen.
Während der Ausführung: Steuern Sie Kommunikation und Abhängigkeiten
Parallele Agents müssen nicht ständig miteinander chatten. Sie benötigen vielmehr definierte Übergabepunkte. Ein Agent sollte nicht in den Arbeitsbaum eines anderen schreiben, um eine fehlende Information „schnell“ zu ergänzen.
Definieren Sie für jede Abhängigkeit ein Zwischenartefakt:
- ein versioniertes API-Schema,
- eine generierte Typdatei,
- ein Datenbankmigrationsentwurf,
- ein Testfall mit erwarteten Ergebnissen,
- eine technische Entscheidungsnotiz,
- ein Commit mit klarer Nachricht.
Beispiel: Agent A entwickelt einen Zahlungsadapter und liefert einen Commit mit einer dokumentierten Schnittstelle. Agent B implementiert die Benutzeroberfläche ausschließlich gegen diese Schnittstelle. Wenn Agent A später die Signatur ändert, wird Agent B nicht stillschweigend angepasst. Stattdessen wird die Änderung als neue Abhängigkeit markiert und der Arbeitsstand neu bewertet.
Das schützt vor einer typischen Schwäche von AI Coding Agents: Sie können lokal eine plausible Lösung erzeugen, ohne zu wissen, dass ein anderer Arbeitszweig gleichzeitig eine inkompatible Annahme verfolgt.
Wie vermeiden mehrere AI Agents Änderungen an derselben Datei?
Verteilen Sie für jeden Agenten ein Datei- und Verantwortungsbudget. Das sollte nicht nur in der Eingabeaufforderung stehen, sondern nach dem Lauf automatisch geprüft werden.
Eine einfache Prüfung kann so aussehen:
git diff --name-only origin/main...HEAD
Vergleichen Sie die Ausgabe mit der erlaubten Pfadliste. Wenn ein Agent außerhalb seines Bereichs geändert hat, stoppen Sie die Zusammenführung. Prüfen Sie zuerst, ob die zusätzliche Änderung wirklich notwendig ist. Häufig hat der Agent eine Formatierungsdatei, eine zentrale Registrierung oder eine Dokumentation ungefragt angepasst.
Für gemeinsam genutzte Dateien gibt es drei belastbare Strategien:
- Vorab-Aufteilung: Jeder Agent bearbeitet einen eigenen Abschnitt oder ein eigenes Modul.
- Serielle Aktualisierung: Die gemeinsame Datei wird erst nach den isolierten Änderungen aktualisiert.
- Vertragsänderung: Die Datei wird durch mehrere kleinere Dateien oder eine generierte Struktur ersetzt.
Verlassen Sie sich nicht auf den Umstand, dass Git einen Konflikt melden wird. Git erkennt Textüberschneidungen, aber nicht jede semantische Kollision. Zwei Agents können dieselbe Konfiguration in unterschiedlichen Zeilen ändern und trotzdem einen fehlerhaften gemeinsamen Zustand erzeugen.
Nach der ersten Runde: Führen Sie eine automatische Abnahme durch
Jeder Agent muss vor der Zusammenführung dieselbe Prüfstrecke durchlaufen. Die Reihenfolge sollte vom schnellen zum teuren Test führen:
- Formatierung und statische Analyse,
- Unit-Tests für das betroffene Modul,
- Integrations- oder API-Tests,
- Build beziehungsweise Typecheck,
- Sicherheitsprüfung und Geheimnisscan,
- Kontrolle der tatsächlich geänderten Dateien,
- Prüfung von Commit-Nachricht und Übergabedokumentation.
Die Claude-Code-Einrichtung nennt unter anderem eine aktuelle Laufzeitumgebung, eine Netzwerkverbindung und ein kompatibles Betriebssystem als Voraussetzungen. Solche Voraussetzungen müssen in Ihrer Baseline geprüft werden, bevor Sie einen Agenten als fehlgeschlagen bewerten. Ein fehlendes Werkzeug ist ein Umgebungsfehler, kein Beweis für schlechte Codequalität.
Wie werden von mehreren Agents erzeugte Änderungen einheitlich abgenommen?
Verwenden Sie für alle Branches denselben CI-Auftrag und dieselben Exit-Codes. Ein Agent darf nicht seine eigene Erfolgsmeldung als Abnahme definieren. Entscheidend ist das reproduzierbare Ergebnis der gemeinsamen Pipeline.
Eine mögliche Übergabevorlage lautet:
Branch: agent/api
Basis-Commit: abc1234
Geänderte Pfade: src/api/, tests/api/
Tests: npm run lint; npm test -- api
Ergebnis: erfolgreich
Bekannte Einschränkung: Test benötigt lokale PostgreSQL-Instanz
Nächster Prüfer: Team Backend
Ein Branch, der den Test nicht ausführen konnte, wird nicht als „fertig“ markiert. Er erhält den Status „wartet“ oder „fehlgeschlagen“ mit einer konkreten Ursache. Dadurch verhindern Sie, dass unklare Umgebungsprobleme am Ende mit funktionalen Fehlern vermischt werden.
Auch Sicherheitsprüfungen müssen zur Agentenrolle passen. Ein Agent mit automatischem Shell-Zugriff darf keine produktiven Tokens sehen und sollte keinen unbeschränkten Upload-Zugriff besitzen. Die offizielle Dokumentation zu Cursor Background Agents weist ausdrücklich darauf hin, dass automatisch ausgeführte Befehle und Internetzugriff Risiken durch Prompt Injection und Datenabfluss verursachen können. Das ist ein Betriebsrisiko, kein Detail der Benutzeroberfläche.
Beim Zusammenführen: Arbeiten Sie von unten nach oben
Die Reihenfolge der Zusammenführung entscheidet häufig darüber, ob Parallelität tatsächlich Zeit spart. Beginnen Sie mit den Branches, die Verträge oder gemeinsame Grundlagen liefern:
- Datenmodell, Schnittstelle oder Basismodul,
- abhängige Implementierungen,
- Tests und Integrationsadapter,
- Dokumentation und nicht funktionale Verbesserungen.
Nach jedem wichtigen Merge aktualisieren Sie die noch offenen Branches auf den neuen Stand und führen mindestens die betroffenen Tests erneut aus. Ein Branch kann auf seiner alten Basis erfolgreich sein und nach der Vertragsänderung trotzdem brechen.
Verwenden Sie bei konkurrierenden Lösungen eine Bewertungsmatrix statt der intuitiven Regel „mehr Code ist besser“. Prüfen Sie mindestens:
- Erfüllung der vereinbarten Funktion,
- Testabdeckung und reproduzierbare Testresultate,
- Änderungsumfang,
- Kompatibilität mit bestehenden Schnittstellen,
- Sicherheits- und Wartungsrisiken,
- Verständlichkeit für menschliche Prüfer.
Wenn zwei Agents dieselbe Funktion unterschiedlich implementieren, ist ein gezielter Vergleich oft wertvoller als ein weiterer Agent, der beide Änderungen blind kombiniert. Wählen Sie eine Lösung aus, verwerfen Sie die andere und dokumentieren Sie die Entscheidung.
Erste Woche: Messen Sie Wartezeit statt Agentenzahl
Nach einigen Durchläufen sollten Sie nicht zuerst die Zahl der Agents erhöhen. Messen Sie zunächst:
- Wartezeit auf Schnittstellen,
- Zeit für Konfliktauflösung,
- Anzahl abgelehnter Branches,
- Wiederholungen wegen fehlender Kontextinformationen,
- Dauer der Test- und Build-Warteschlangen,
- manuellen Aufwand für Review und Zusammenführung,
- Fehler, die erst nach dem Merge entdeckt wurden.
Wenn die Agents häufig aufeinander warten, ist die Aufgabenzerlegung der Engpass. Wenn sie sich oft in denselben Dateien begegnen, fehlt eine bessere Modulgrenze. Wenn die Builds die gesamte Umgebung blockieren, benötigen Sie möglicherweise getrennte Runner oder eine andere Teststufe.
Parallele Entwicklung ist außerdem nicht automatisch schneller. Kleine Tickets, stark gekoppelte Kernmodule, instabile Anforderungen und umfangreiche Datenbankmigrationen sind typische Fälle, in denen ein einzelner Agent mit menschlicher Führung weniger Koordinationskosten verursacht.
Das folgende Entscheidungswerkzeug können Sie vor jedem Lauf abhaken:
- [ ] Die Anforderungen sind für die erste Implementierungsrunde stabil.
- [ ] Die Aufgaben besitzen unterschiedliche Verantwortungs- und Dateigrenzen.
- [ ] Gemeinsame Schnittstellen sind dokumentiert oder zuerst als eigene Aufgabe eingeplant.
- [ ] Jeder Agent hat eine eigene Branch und einen eigenen Arbeitsbereich.
- [ ] Abhängigkeiten, Ports, Datenbanken und temporäre Dateien sind getrennt.
- [ ] Es werden keine produktiven Geheimnisse in Agenten-Umgebungen kopiert.
- [ ] Für alle Agents gelten derselbe Testbefehl und dieselbe Definition of Done.
- [ ] Ein Statusprotokoll ersetzt nicht nur den Chat, sondern dokumentiert auch Fehler und Übergaben.
- [ ] Die Merge-Reihenfolge ist vor dem Start festgelegt.
- [ ] Nach jedem Grundlagen-Merge ist ein erneuter Test vorgesehen.
Wenn zwei oder mehr Punkte nicht erfüllt sind, starten Sie nicht mit zusätzlicher Parallelität. Beheben Sie zuerst die fehlende Grundlage.
Lokale, temporäre oder dauerhafte Umgebung: Was passt zu Ihrem Projekt?
Für einen einzelnen Entwickler mit kurzen Experimenten reicht häufig der lokale Mac mit getrennten git worktrees. Das ist kostengünstig und direkt kontrollierbar, setzt aber voraus, dass Arbeitsspeicher, CPU, Speicherplatz und Netzwerk für mehrere Prozesse ausreichen.
Eine temporär gemietete Umgebung ist sinnvoll, wenn Sie nur für einen Sprint, einen Benchmark oder eine größere Refactoring-Runde mehrere Agenten benötigen. Sie vermeiden eine hohe Anschaffung, müssen aber Zugriffsschutz, Datenübertragung, Schlüsselverwaltung und Löschung der Arbeitsdaten prüfen.
Eine dauerhaft entfernte Umgebung passt eher zu Teams mit regelmäßigem Agentenbetrieb, zentraler Protokollierung und standardisierten Entwicklungsimages. Hier steigen allerdings die Anforderungen an Governance, Kostenkontrolle und DSGVO-konforme Datenflüsse.
Wenn Sie nach der Aufgaben- und Abhängigkeitsanalyse nur gelegentlich zwei bis drei isolierte Agents ausführen, ist ein dauerhaft bereitgestelltes Hochleistungsgerät wahrscheinlich überdimensioniert. Wenn dagegen täglich mehrere Builds, Remote-Sitzungen und längere Agentenläufe anstehen, kann eine stabile Umgebung wirtschaftlicher sein als wiederholte lokale Engpässe. Kvmzen beschreibt auf der deutschen Mac-Mini-Mietseite eine mögliche Option für zeitlich begrenzte Mac-Arbeitsumgebungen.
Der entscheidende Vergleich lautet daher nicht „Mac kaufen oder Mac mieten“, sondern: Wie oft läuft Ihr Parallelprojekt, wie vertraulich sind die Daten, welche Schnittstellen müssen lokal vorhanden sein und wie teuer ist die Wartezeit auf eine freie Entwicklungsumgebung?
Ein eigener Rechner bietet langfristig Kontrolle und kann sich bei dauerhaft hoher Auslastung rechnen. Er bindet jedoch Kapital, muss gewartet werden und kann bei kurzfristig wachsender Agentenzahl zum Engpass werden. Eine temporäre Kvmzen-Umgebung ist für Tests, Migrationen und begrenzte Entwicklungsphasen flexibler, ersetzt aber keine eigene Infrastruktur, wenn Sie dauerhaft schwere Builds oder spezielle physische Anschlüsse benötigen. Starten Sie deshalb nicht mit dem Kauf einer maximal ausgestatteten Maschine. Zeichnen Sie zuerst Ihre Aufgabenabhängigkeiten, ermitteln Sie die tatsächlich benötigte Parallelität und wählen Sie danach lokal, temporär gemietet oder dauerhaft entfernt.