Parallel arbeiten: mehr Agenten, nicht mehr Chaos.

7.1 Warum überhaupt parallel?

Ein einzelner Agent arbeitet sequenziell: lesen, planen, ändern, testen, nachbessern. Bei größeren Vorhaben dauert das, und vieles daran ist voneinander unabhängig. Das Backend-Modul für Rechnungen und das Frontend-Formular für Adressen berühren sich kaum. Warum sollten sie nacheinander entstehen?

Parallelität verspricht drei Dinge:

• Durchlaufzeit: Unabhängige Teile entstehen gleichzeitig.
• Fokus: Jeder Agent bekommt einen kleineren, klar umrissenen Auftrag und damit einen übersichtlicheren Kontext. Kleine Aufträge gelingen erfahrungsgemäß häufiger als große.
• Spezialisierung: Analyse, Implementierung und Prüfung können unterschiedliche Agenten, Modelle oder Werkzeuge übernehmen.

Der Haken: Software ist kein Stapel unabhängiger Blätter. Teile teilen Schnittstellen, Datenmodelle, Build-Konfiguration und Datenbankmigrationen. Sobald zwei Agenten dieselbe Stelle anfassen oder sich auf unterschiedliche Annahmen über eine gemeinsame Schnittstelle stützen, entsteht Integrationsarbeit. Im schlimmsten Fall ist sie größer als der Zeitgewinn. Die Parallel-Roadmap der Fabrik nennt genau das als Hauptrisiko: Integrationskosten können den Parallelitätsgewinn übersteigen.

7.2 Das Grundproblem: geteilter Zustand

Stell dir zwei Agenten vor, die im selben Arbeitsverzeichnis arbeiten. Agent A ändert eine Klasse und ist halb fertig. Agent B führt in diesem Moment die Tests aus, sieht einen Kompilierfehler in A's halbfertigem Code und „repariert“ ihn. Dann committet B mit git add -A und nimmt A's halbe Arbeit mit. Danach weiß niemand mehr, wer welche Zeile verursacht hat. Ein Review, ein Warum-Trace oder eine Attestierung würden Aussagen über einen Stand treffen, den kein einzelner Agent zu verantworten hat.

Das ist kein Randfall, sondern die zwangsläufige Folge von mehreren Schreibern auf einem gemeinsamen Zustand. Menschliche Teams lösen das, indem jede Person auf ihrer eigenen Arbeitskopie arbeitet und Änderungen über Branches und Merges zusammenführt. Für Agenten gilt dieselbe Lösung, nur konsequenter, weil Agenten sich nicht zwischendurch absprechen.

Single Writer per Workspace

Zu jedem Zeitpunkt schreibt in einem Arbeitsverzeichnis genau ein Agent. Parallelität entsteht durch mehr Arbeitsverzeichnisse, nicht durch mehr Schreiber pro Verzeichnis.

Diese Regel (in der Fabrik ADR-0015) klingt streng, vereinfacht aber alles Weitere: Jeder Stand ist einem Agenten zurechenbar, Konflikte entstehen erst zwischen abgeschlossenen Branches, und beide Seiten eines Konflikts sind in sich konsistent. Ein Merge-Konflikt zwischen zwei fertigen Branches lässt sich analysieren und als Arbeitsauftrag formulieren. Ein Konflikt mitten in einem gemeinsamen Verzeichnis nicht.

Lesende Agenten sind von der Regel nicht betroffen. Reviewer und Analyse-Agenten, die nichts schreiben, dürfen beliebig parallel auf denselben Stand schauen.

Git-Worktrees als Werkzeug

Technisch bietet Git mit Worktrees ein passendes Mittel: Mehrere Arbeitsverzeichnisse teilen sich ein Repository, jedes auf einem eigenen Branch. Das spart Platz gegenüber vollständigen Klonen, und alle Branches sind sofort im gemeinsamen Objektspeicher sichtbar, was die spätere Zusammenführung vereinfacht.

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

7.3 Zerlegen: der Abhängigkeitsgraph

Bevor irgendetwas parallel laufen kann, muss das Vorhaben zerlegt werden. Das Ergebnis ist ein gerichteter, azyklischer Graph (englisch DAG): Knoten sind Aufgaben, Kanten sagen „B kann erst beginnen, wenn A fertig ist“. Parallel laufen dürfen genau die Aufgaben, die in diesem Graphen nicht voneinander abhängen und deren Vorgänger fertig sind.

Arten von Abhängigkeiten

Nicht jede Abhängigkeit ist „erst A, dann B“. Die Parallel-Roadmap der Fabrik unterscheidet zum Beispiel:

• Fertigstellung: B braucht das Ergebnis von A.
• Vertrag: B braucht eine festgelegte Schnittstelle, nicht A's Implementierung.
• Artefakt: B braucht ein bestimmtes Erzeugnis, etwa eine generierte Datei.
• Freigabe: B darf erst nach einer menschlichen Entscheidung beginnen.
• Exklusive Ressource: A und B fassen dieselbe Datei an, die keine zwei gleichzeitigen Änderungen verträgt.

Die Unterscheidung lohnt sich: Eine Vertragsabhängigkeit lässt sich auflösen, indem man den Vertrag zuerst festlegt. Danach können Anbieter und Nutzer der Schnittstelle gleichzeitig entstehen. Eine Fertigstellungsabhängigkeit lässt sich nicht so einfach auflösen.

Gute Zerlegung

• Nach Schreibbereichen schneiden, nicht nach Fachbegriffen. Zwei Aufgaben, die dieselben Dateien ändern, sind nicht parallel, egal wie verschieden sie fachlich klingen.
• Gemeinsames zuerst: Datenmodell, Schnittstellen, Migrationen und Build-Änderungen in eine frühe, eigene Aufgabe legen.
• Klein, aber vollständig: Jede Aufgabe soll für sich bauen und testbar sein.
• Analyse vor Umsetzung: Lesende Analyse-Aufgaben sind ideal für Parallelität, weil sie nichts schreiben. Ihre Ergebnisse fließen in die Planung der schreibenden Aufgaben.

Wie du allgemein plant und Akzeptanzkriterien je Aufgabe festlegst, behandelt Kapitel 5.

7.4 Verträge vor paralleler Implementierung

Wenn Frontend und Backend gleichzeitig entstehen, müssen beide wissen, wie die Schnittstelle zwischen ihnen aussieht. Lässt man jeden Agenten seine eigene Annahme treffen, entstehen zwei Builds, die jeweils grün sind und zusammen nicht funktionieren. Kein Test einer einzelnen Änderung zeigt auf dieses Problem, denn der Bruch liegt zwischen den Komponenten.

Daher das Prinzip Contracts before Parallel Implementation: Voneinander abhängige Komponenten dürfen erst parallel implementiert werden, wenn der gemeinsame Vertrag versioniert vorliegt. Verträge können sein:

• API-Beschreibungen (OpenAPI für REST, AsyncAPI für Ereignisse),
• Datenschemas (JSON-Schema, DTO-Definitionen),
• Java- oder TypeScript-Interfaces,
• Domänenereignisse,
• Akzeptanzkriterien.

Drei Eigenschaften eines brauchbaren Vertrags

1. Unveränderliche Fassungen. Eine Änderung erzeugt eine neue Fassung, die alte bleibt bestehen. Sonst verweist der Nachweis „Agent B hat gegen Fassung 3 gebaut“ auf einen Inhalt, der sich inzwischen geändert haben könnte.
2. Inhaltsprüfsumme. Ein Hash über den Inhalt macht Fassungen eindeutig vergleichbar.
3. Bindung zum richtigen Zeitpunkt. Welche Fassung gilt, wird festgeschrieben, wenn die Arbeit beginnt, nicht schon bei der Planung. Zwischen Planung und Start kann sich der Vertrag noch ändern.

Wenn sich der Vertrag ändert

Ändert sich ein Vertrag, während Aufgaben gegen die alte Fassung arbeiten, sind diese Aufgaben veraltet. Ihr Ergebnis darf nicht ungeprüft übernommen werden, auch wenn ihr eigener Build grün ist. Die Aufgabe muss neu bewertet werden: erneut gegen die neue Fassung ausführen oder verwerfen.

7.5 Besitz und Leases

Single Writer pro Verzeichnis verhindert, dass zwei Agenten sich gegenseitig die Arbeitskopie zerschießen. Es verhindert nicht, dass zwei Agenten in ihren getrennten Worktrees dieselbe Datei ändern. Das merkt man erst beim Zusammenführen, und dann ist die Arbeit schon getan. Besser ist, Überschneidungen vor dem Start zu erkennen.

Erklärter Besitz

Dafür erklärt jede schreibende Aufgabe, welche Bereiche sie ändern will (Schreibbereiche), welche sie nur liest und welche sie nicht anfassen darf. Überschneiden sich die Schreibbereiche zweier aktiver Aufgaben, startet die zweite nicht. Bestimmte Dateien sind grundsätzlich exklusiv, weil zwei gleichzeitige Änderungen dort fast sicher kollidieren: zentrale Build-Konfiguration, Datenbankmigrationen, gemeinsame API-Spezifikationen.

Leases statt ewiger Sperren

Ein Besitzanspruch braucht ein Ablaufdatum. Stürzt ein Agentenprozess ab, darf seine Sperre den Rest des Vorhabens nicht dauerhaft blockieren. Daher vergibt man Besitz als Lease: einen Anspruch mit Laufzeit, der per Herzschlag verlängert wird. Bleibt der Herzschlag aus, gilt der Anspruch als verwaist und kann freigegeben werden.

Ein verwandtes Problem tritt bei mehreren ausführenden Prozessen auf: Zwei Worker könnten gleichzeitig dieselbe Aufgabe übernehmen. Die Lösung ist ein atomarer Anspruch, bevor irgendetwas geschieht: Nur einer kann ihn gewinnen. Und wenn ein Worker ausfällt, gilt: Eine Aufgabe, die noch nicht lief, darf zurück in die Warteschlange. Eine, die schon lief, hat einen Arbeitsstand unbekannter Qualität hinterlassen und darf nicht still wiederholt werden.

7.6 Zusammenführen: Reihenfolge, Konflikte, Integration

Wenn alle parallelen Aufgaben fertig sind, liegen mehrere Branches vor, die jeweils für sich gebaut und geprüft wurden. Jetzt kommt der schwierigste Teil: Sie zu einem Gesamtstand zusammenzuführen, der als Ganzes funktioniert.

Feste Reihenfolge

Man könnte Branches in der Reihenfolge zusammenführen, in der sie fertig werden. Dann hängt das Ergebnis aber an zufälligen Laufzeiten, und zwei Durchläufe desselben Plans ergeben unterschiedliche Stände. Reproduzierbar wird es erst mit einer festen Reihenfolge, etwa der Planreihenfolge, und einer sequenziellen Warteschlange (Merge Queue).

Konflikte sind nicht gleich Konflikte

Für Git sieht jeder Konflikt gleich aus: zwei Seiten, die sich an derselben Stelle widersprechen. In der Praxis verlangen sie sehr verschiedene Reaktionen:

• Zwei Migrationen mit derselben Nummer: umnummerieren, aber sorgfältig, weil Datenbankstände daran hängen.
• Zwei hinzugefügte Abhängigkeiten in der Build-Datei: meist mechanisch lösbar.
• Reine Formatierungsunterschiede: harmlos.
• Ein veralteter Branch: ein Rebase auf den aktuellen Stand kann genügen.
• Ein echter inhaltlicher Widerspruch: Hier muss jemand entscheiden, was gelten soll.

Ein Agent, dem man nur „löse den Konflikt“ sagt, rät. Wer Konflikte klassifiziert, kann gezielt reagieren: mechanische Fälle automatisieren, inhaltliche eskalieren. Und ein Rebase ist kein Allheilmittel: Er löst Konflikte, die nur daher rühren, dass ein Branch alt ist, aber keine inhaltlichen Widersprüche.

Integration prüfen

Jede Aufgabe wurde für sich geprüft. Das beantwortet nicht, ob die Änderungen zusammen funktionieren. Deshalb braucht es nach dem Zusammenführen eine eigene Prüfung des Gesamtstands: Gesamtbuild, Integrationstests, Architekturtests über den integrierten Stand, Vertragskompatibilität. Erst wenn diese Integrationsprüfung besteht, ist das Vorhaben fertig.

7.7 Umplanen mit Grund

Kein Plan überlebt die Ausführung unverändert. Eine Aufgabe erweist sich als zu groß, ein Vertrag ändert sich, ein Konflikt zeigt, dass zwei Aufgaben eigentlich eine sind. Umplanen ist also normal. Gefährlich wird es, wenn es spurlos passiert oder als Vorwand für blinde Wiederholungen dient.

Zwei Regeln helfen:

• Jede Planänderung ist versioniert und begründet. Nicht nur „Plan Version 4“, sondern: Was hat sich geändert, warum, wer hat es ausgelöst? Die Frage, die Wochen später kommt, lautet nicht „welche Version“, sondern „warum diese“.
• Ein Task wird nur mit neuer Eingabe neu gestartet. Das ist dieselbe Regel wie bei Korrekturschleifen in Kapitel 6. Ein anderer Zuschnitt oder eine neue Reihenfolge ordnen Arbeit um, geben dem Agenten aber nichts, was er beim letzten Versuch nicht hatte.

7.8 Wann du nicht parallelisieren solltest

Parallelität ist ein Werkzeug, kein Ziel. Verzichte darauf, wenn:

• die Aufgaben dieselben Dateien ändern, etwa einen zentralen Service oder ein gemeinsames Datenmodell. Die Besitzprüfung würde sie ohnehin nacheinander starten.
• noch kein Vertrag existiert und die Schnittstelle erst beim Bauen entsteht. Lege dann zuerst eine Aufgabe „Vertrag festlegen“ an.
• das Vorhaben klein ist. Planung, Freigabe, Integration und Prüfung kosten Zeit; für eine Änderung, die ein einzelner Run in einem Durchgang schafft, lohnt sich ein Workflow nicht.
• die Anforderungen unklar sind. Drei Agenten, die eine vage Anforderung unterschiedlich interpretieren, erzeugen drei inkonsistente Teile. Kläre erst die Spec.
• niemand die Integration verantwortet. Konflikte und veraltete Tasks brauchen menschliche Entscheidungen. Ohne jemanden, der sie trifft, bleibt der Workflow stehen.

Kapitelfragen

1. Was besagt das Prinzip „Single Writer per Workspace“, und welches Problem verhindert es?

   Musterantwort

   In einem Arbeitsverzeichnis schreibt zu jedem Zeitpunkt genau ein Agent; Parallelität entsteht durch mehr Arbeitsverzeichnisse. Es verhindert, dass ein Agent die halbfertige Arbeit eines anderen mitcommittet oder „repariert“, wodurch Stände niemandem mehr zurechenbar wären und Review, Warum-Trace und Attestierung ihre Aussagekraft verlören.

2. Warum dürfen Reviewer und Analyse-Agenten beliebig parallel laufen, schreibende Tasks aber nicht?

   Musterantwort

   Lesende Agenten verändern keinen Zustand, also können sie sich nicht gegenseitig stören oder Arbeit vermischen. Schreibende Agenten erzeugen Änderungen, die zurechenbar bleiben und kontrolliert zusammengeführt werden müssen; deshalb bekommen sie eigene Worktrees und erklärte Schreibbereiche.

3. Erkläre „Contracts before Parallel Implementation“ an einem Beispiel aus Frontend und Backend.

   Musterantwort

   Bevor Frontend-Formular und Backend-Endpunkt parallel entstehen, wird die Schnittstelle als versionierter Vertrag festgelegt, etwa als OpenAPI-Dokument. Beide Agenten arbeiten gegen dieselbe, beim Start gebundene Fassung. Ohne Vertrag träfe jeder eigene Annahmen; beide Builds wären grün, zusammen funktionierten sie nicht.

4. Was passiert in der Fabrik, wenn ein Vertrag eine neue Fassung bekommt, während ein daran gebundener Task noch läuft?

   Musterantwort

   Die Stale-Erkennung setzt den Task auf WAITING_FOR_REPLAN. Auch wenn sein Lauf danach erfolgreich endet, wird das Ergebnis nur festgehalten, der Task aber nicht auf PASSED gehoben. Die Merge-Blockade verhindert die Integration, und der Workflow geht nach WAITING_FOR_APPROVAL. Ein Mensch entscheidet: erneut gegen die neue Fassung ausführen oder verwerfen.

5. Warum führt die Merge Queue Branches in Planreihenfolge zusammen und nicht in der Reihenfolge, in der sie fertig werden?

   Musterantwort

   Sonst hinge das integrierte Ergebnis an zufälligen Laufzeiten, und zwei Durchläufe desselben Plans könnten unterschiedliche Stände und Konflikte erzeugen. Die feste Reihenfolge macht die Integration reproduzierbar und nachvollziehbar.

6. Ein Agent schlägt vor, jeden Merge-Konflikt per Rebase zu lösen. Was antwortest du?

   Musterantwort

   Ein Rebase löst nur Konflikte, die daher rühren, dass ein Branch veraltet ist. Er löst keine inhaltlichen Widersprüche und verschiebt Migrationsnummer-Kollisionen nur. Deshalb klassifiziert die Fabrik Konflikte zuerst und versucht den Rebase nur, wenn die Einordnung ihn als aussichtsreich einstuft; bei MIGRATIONSNUMMER und INHALTLICHER_WIDERSPRUCH bewusst nicht.

7. Wozu braucht man ein Integration Gate, wenn jeder Child Run bereits sein eigenes Gate bestanden hat?

   Musterantwort

   Das lokale Gate prüft eine Änderung für sich. Ob mehrere Änderungen zusammen funktionieren, zeigt erst die Prüfung des integrierten Gesamtstands. In der Fabrik erreicht ein Workflow COMPLETED nur über das Urteil des Integration Gates; ein verworfener Branch macht es FAILED, ein Vertragsbruch stuft auf WARNING herunter.

8. Jemand möchte einen gescheiterten Task einfach „noch mal laufen lassen“. Unter welcher Bedingung erlaubt die Fabrik das, und warum?

   Musterantwort

   Nur über ein Replanning, dessen Grund eine neue Eingabe trägt, etwa Build-Fehler, Reviewer-Befund, Merge-Konflikt, Vertragsänderung oder eine menschliche Anweisung. Die Änderung wird als PlanRevision mit Beschreibung festgehalten und als WORKFLOW_REPLANNED attestiert. Grund ist AP-6: Eine Wiederholung ohne neue Information kostet Tokens, ohne die Erfolgschance gezielt zu erhöhen.

9. Transfer: Drei Child Runs eines Workflows setzen Teile derselben Spec um. Während der zweite läuft, gibt eine Maintainerin eine neue Spec-Fassung frei. Gegen welche Fassung arbeiten die drei Runs, und warum ist das gewollt?

   Musterantwort

   Gegen die Fassung, die beim Start am Task gebunden wurde (WORKFLOW_TASK_SPEC_GEBUNDEN); alle Child Runs eines Workflows arbeiten nachweislich gegen dieselbe Fassung. Das verhindert, dass parallele Teile gegen unterschiedliche Anforderungen gebaut werden und erst bei der Integration auseinanderfallen. Die neue Fassung wird bewusst über eine neue Planung bzw. einen neuen Workflow übernommen; seit v0.38.0 setzt die Spec-Drift-Erkennung betroffene, nicht abgeschlossene Tasks auf WAITING_FOR_REPLAN.

10. Nenne drei Situationen, in denen du auf einen Workflow verzichtest und einen einzelnen Build-Run vorziehst.

    Musterantwort

    Wenn die Teilaufgaben dieselben Dateien ändern, wenn das Vorhaben so klein ist, dass Planung und Integration mehr kosten als die Parallelität bringt, und wenn Anforderungen oder Schnittstellen noch unklar sind. Auch ohne verantwortliche Person für Integrationsentscheidungen bleibt ein Workflow stehen.