Mit Agenten über mehrere getrennte Repositories arbeiten

Ein Backend-Repo und ein Client-Repo gehören zusammen, leben aber getrennt – ein Agent braucht dafür eine andere Strategie als in einem einzigen Monorepo.

Abgrenzung zum Monorepo

Das Kapitel „KI-Agenten in großen Monorepos einsetzen" behandelt EIN Repository mit vielen Teilprojekten unter einem Dach. Hier geht es um das Gegenteil: mehrere eigenständige, getrennt versionierte Repositories – etwa ein API-Backend und ein separates Frontend-Repo –, die zusammen ein System bilden, aber jedes seine eigene Git-Historie, eigene CLAUDE.md und eigene Deploy-Pipeline haben.

Kontext je Repo

Jedes Repository behält seine eigene CLAUDE.md mit seinen eigenen Konventionen. Ein Agent, der im Backend-Repo startet, kennt dessen Regeln automatisch – Regeln des Frontend-Repos lädt er nicht von selbst, weil beide Repos technisch nichts voneinander wissen.

Zugriff auf ein zweites Repo herstellen

Claude Code kann eine zusätzliche, separat ausgecheckte Repository-Kopie über einen zusätzlichen Verzeichniszugriff einbinden – dieselbe Technik, die auch Nachbar-Pakete in einem Monorepo zugänglich macht, funktioniert genauso für ein komplett getrenntes zweites Repository auf der Platte.

Abgestimmte Änderungen und Reihenfolge

Ändert sich ein API-Vertrag, muss die Backend-Änderung meist zuerst gemergt und deploybar sein, bevor der Client umgestellt wird – oder beide Seiten bleiben über eine Übergangsphase abwärtskompatibel. Ohne bewusste Reihenfolge und Versionierung riskierst du inkompatible Annahmen zwischen Client und Server.

BEISPIEL

Aufgabe: Ein neues Feld 'currency' zur Preisauskunft hinzufügen, Backend-Repo 'tm2-api' und Frontend-Repo 'tm2-web' sind getrennt. Schritt 1 (im Repo tm2-api): Feld additiv zum Response-Schema hinzufügen, alter Client bleibt kompatibel, da das Feld optional ist. Deployen. Schritt 2 (Zugriff auf tm2-web via --add-dir oder separate Sitzung): Client so anpassen, dass er das neue Feld nutzt, falls vorhanden, sonst den bisherigen Standardwert verwendet. Schritt 3: Erst nach bestätigtem Rollout beider Seiten das Feld im Backend als verpflichtend markieren.

🛠️ ÜBUNG — MACH DAS BEI DIR

Simuliere eine abgestimmte Änderung über zwei getrennte lokale Repositories.

Lege zwei kleine, getrennte Git-Repositories lokal an, eines als 'API', eines als 'Client', die per einfacher Textdatei einen 'Vertrag' teilen (z. B. ein JSON-Schema).
Ändere im API-Repo den Vertrag additiv (neues optionales Feld) und committe.
Gib einem Agenten Zugriff auf beide Verzeichnisse und lass ihn den Client so anpassen, dass er das neue Feld nutzt, falls vorhanden.
Prüfe, ob der Client auch ohne das neue Feld (alter Vertrag) noch funktioniert.

✅ SELBST-CHECK

☐ Blieb der Client mit der alten Vertragsversion weiterhin funktionsfähig, während die neue Version schon existierte?
☐ Musste der Agent explizit auf das zweite Repository-Verzeichnis zugreifen, oder tat er das automatisch?

KURZ-QUIZ

Was unterscheidet die Arbeit über mehrere getrennte Repositories grundlegend von einem Monorepo mit vielen Teilprojekten?