Mehrere Repositories, mehrere Agenten: Regeln gehören ins Repo, Zustände in Worktrees

Ein Coding-Agent soll gleichzeitig einen Fehler untersuchen, einen Patch vorbereiten und Tests ergänzen. Teilen diese Aufträge einen Arbeitsbaum, reichen ein Branch-Wechsel, uncommittete Dateien oder erzeugte Artefakte, damit sie sich gegenseitig verfälschen. Die entscheidende Architekturfrage lautet deshalb nicht, wie viele Agenten parallel laufen dürfen. Sie lautet: Wo endet der Kontext eines Repositories – und wo beginnt der eines Arbeitsauftrags?

Das Testautomatisierungsunternehmen mabl beschreibt für mehr als 75 Repositories ein schlichtes Muster: Jedes Repository enthält eine eigene CLAUDE.md mit lokalen Regeln und Ausnahmen; parallele Arbeit läuft in getrennten Git Worktrees. Diese Trennung verhindert, dass Zustand aus einem Auftrag versehentlich in den nächsten wandert.

Das Repository trägt die lokalen Regeln

Zentrale Vorgaben für Architektur oder Sicherheit bleiben sinnvoll. Sie ersetzen aber keine Regeln, die nur für ein bestimmtes Projekt gelten. Projektspezifische Ausnahmen und Vorgaben gehören ins jeweilige Repository. Dort begegnen sie dem Agenten genau in dem Kontext, in dem er Code verändert.

Das schützt vor falschen Übertragungen. Annahmen eines Frontends über Tests oder Releases gehören nicht automatisch in ein Backend. Eine gemeinsame Regelbasis kann festlegen, wie Änderungen geprüft oder Zugriffe freigegeben werden. Das Repository präzisiert dagegen, welche Tests nötig sind, welche Dateien tabu bleiben und welche Ausnahme tatsächlich gilt.

Regeln nur im Gesprächsverlauf mitzuschleppen, macht sie flüchtig. Sie ausschließlich zentral zu sammeln, schafft leicht eine zweite Wahrheit neben dem Code. Versionierte lokale Regeln sind überprüfbar, reisen mit dem Projekt und stehen auch in einem neu angelegten Arbeitsbereich bereit.

Parallele Aufträge brauchen getrennte Arbeitsbäume

Git Worktrees geben mehreren Arbeitsständen desselben Repositories eigene Verzeichnisse. Für parallele Ausführung ist das der praktische Gewinn: Ein Auftrag verändert seinen eigenen Arbeitsbaum, statt stillen Zustand mit anderen Aufträgen zu teilen.

Das ist mehr als eine aufgeräumte Ordnerstruktur. Arbeitet ein Agent an der Fehlerreproduktion, ein zweiter am Patch und ein dritter an Tests, können sich Änderungen im gemeinsamen Checkout unbemerkt beeinflussen. Getrennte Worktrees verschieben diese Berührung an einen kontrollierten Punkt: das bewusste Zusammenführen.

Die Mindestkontrolle ist banal, aber wirksam: Jeder Auftrag braucht ein eigenes Verzeichnis und einen eigenen Branch. Build-Artefakte, lokale Konfigurationen und Zugangsdaten dürfen nicht unkontrolliert zwischen diesen Bereichen geteilt werden. Vor dem Merge sollten Maintainer die aktiven Worktrees und ihre Branches prüfen, dann Test- und Artefaktstatus im jeweiligen Arbeitsverzeichnis kontrollieren. Erst danach ist nachvollziehbar, welcher Auftrag welche Änderung erzeugt hat.

Gesprächsverlauf ist nicht der Arbeitsbereich

Neben Dateien und Branches gibt es einen zweiten Zustand: die Geschichte eines Auftrags. Sie sollte vom Workspace getrennt bleiben. Ein Arbeitsbereich ist ersetzbar; der Verlauf eines Auftrags muss trotzdem nachvollziehbar bleiben, damit Entscheidungen, Tests und Nebenwirkungen später geprüft werden können.

Ich würde beides nie als denselben Betriebszustand behandeln: Der Arbeitsbereich hat Nebenwirkungen, der Verlauf erklärt, warum sie entstanden sind. Auch die Wahl einer Arbeitsumgebung ist eine Berechtigungsentscheidung. Ein Agent sollte keine weitergehende Umgebung erhalten, nur weil sie gerade bequem verfügbar ist.

Fazit: Jede Änderung braucht eine klare Grenze

Für den Betrieb ergibt sich eine belastbare Mindestregel: Projektspezifische Regeln gehören versioniert ins jeweilige Repository. Jeder parallele Auftrag erhält einen eigenen Worktree oder einen vergleichbar isolierten Arbeitsbereich. Auftragshistorie und Arbeitsverzeichnis werden getrennt behandelt. Und die Umgebung folgt den Berechtigungen der Person oder des Dienstes, in deren Kontext der Auftrag läuft.

Sobald Agenten Code ausführen und Dateien verändern, ist Parallelität keine reine Durchsatzfrage mehr. Vor dem nächsten Ausbau lohnt ein kurzer Gegencheck: Kann jeder laufende Auftrag eindeutig sein Repository, seinen Arbeitsbaum, seine Regeln und seine Berechtigung benennen? Wenn eine dieser Grenzen verschwimmt, ist der Fehler meist nicht weit entfernt.