Agentic AI
Mai 23, 2026
Felix Braun 
Ich wollte einmal kurz einen API-Endpunkt in einem Microservice umbenennen. Drei Stunden später hatte ich fünf Repositories auf, sieben Terminal-Fenster offen und einen Kaffeefleck auf meiner Tastatur – der Rename war noch nicht fertig. Cursor Multi-Repo Agents versprechen, genau diesen Alptraum zu beenden. Ob das Versprechen hält, was die Technik wirklich kann und wo Sie aufpassen müssen: hier kommt der ehrliche Blick.
Microservice-Architekturen sind schön auf dem Whiteboard. In der Praxis bedeuten sie schnell: zwölf Repositories, vier Teams, zwei CI-Systeme und eine API-Versionierungsstrategie, die irgendjemand vor drei Jahren „mal kurz“ in ein Confluence-Wiki geschrieben hat. Nerd-Alarm: Wer kennt das nicht – man will eine Datenstruktur anpassen und findet heraus, dass sie in sieben verschiedenen Services über Copy-Paste geklont wurde.
Genau hier setzt die Idee der Multi-Repo Agents an. Statt nur das aktuelle Repo zu „kennen“, soll die KI mehrere Repositories gleichzeitig im Blick haben, Abhängigkeiten verstehen und Änderungen koordiniert vorschlagen. Das klingt nach dem Ende der stundenlangen Suche nach dem letzten grep -r-Ergebnis in einem fremden Service.
Cursor IDE geht diesen Weg über Workspace-basierte Multi-Root-Konfigurationen. Technisch kann die IDE mehrere Ordner und Repositories gleichzeitig öffnen, indexieren und dem Agenten als gemeinsamen Kontext bereitstellen. Die Basis ist also da. Was daraus wird, hängt aber stark von Setup und Produktstand ab.
Die technische Grundlage von Cursor IDE für projektübergreifende Arbeit ist der Workspace-Ansatz: Man legt eine .code-workspace-Datei an, die mehrere Repository-Pfade zusammenfasst. Cursor indexiert dann alle enthaltenen Verzeichnisse und macht sie dem Agenten als einheitlichen Kontext zugänglich. Das ist der Ausgangspunkt für jede Art von Monorepo-Entwicklung oder Multi-Repo-Workflow.
Spoiler: Dieser Mechanismus funktioniert erstaunlich gut für lesende Operationen. Der Agent kann Symbole, Typen und Funktionen über Repo-Grenzen hinweg nachschlagen, Abhängigkeitsketten verfolgen und Refactoring-Vorschläge machen, die mehrere Services betreffen. Für viele Enterprise-Teams ist das bereits ein deutlicher Schritt vorwärts.
Für schreibende Operationen – also tatsächliche Code-Änderungen in mehreren Repos gleichzeitig – wird es komplizierter. Laut Diskussionen im offiziellen Cursor-Forum zu Cloud Agents und Multi-Repo-Setups war der vollständige Multi-Repo-Support für Cloud Agents zum Zeitpunkt der Diskussion noch nicht allgemein verfügbar und auf der Roadmap gelistet. Das ist ehrlich – und wichtig zu wissen, bevor man das nächste Architektur-Meeting mit diesem Feature als Kernargument betritt.
Mehr Repositories im Kontext bedeutet nicht automatisch bessere Ergebnisse. Das ist der Punkt, den viele Enthusiasten gerne übersehen. Im Ernst: Ein Agent, dem Sie zehn Microservices plus drei Bibliotheks-Repos plus zwei Legacy-Systeme in den Kontext werfen, wird nicht zwingend klüger. Er wird erst mal verwirrt.
Das Stichwort hier ist selektives Indexing. Praktische Workflows empfehlen, .cursorignore-Dateien zu nutzen, um irrelevante Verzeichnisse, Build-Artefakte und generierte Dateien aus dem Agenten-Kontext herauszuhalten. Klare projektbezogene Regeln – also cursor rules pro Repository – helfen dabei, dem Agenten zu signalisieren, welche Konventionen wo gelten. Workspace-Segmentierung bedeutet: nicht einfach alles in einen riesigen Workspace packen, sondern funktional zusammengehörige Services gruppieren.
Das klingt nach Mehraufwand. Ist es auch. Aber dieser initiale Konfigurationsaufwand ist der Unterschied zwischen einem Agenten, der sinnvolle Vorschläge macht, und einem, der Ihnen erklärt, wie man einen Python-Flask-Endpunkt umbenennt – in einem Go-Service.
Die klassische Debatte zwischen Monorepo und Multi-Repo ist so alt wie die ersten Microservice-Hypes. Monorepos machen atomare Änderungen über viele Pakete einfacher, ermöglichen einheitliche CI/CD-Pipelines und klare Code-Ownership. Multi-Repo gibt Teams Autonomie, reduziert Abhängigkeits-Chaos und skaliert besser in großen Organisationen mit unterschiedlichen Release-Zyklen.
Was verschiebt sich durch KI-Agenten? Einige Analysen – etwa eine viel diskutierte Analyse auf Dev.to – argumentieren, dass Agenten die Reibung der Multi-Repo-Arbeit spürbar senken, weil sie Kontext aus mehreren Repos zusammenführen können, ohne dass der Entwickler selbst zwischen Fenstern jonglieren muss. Das ist eine plausible These, kein belegter Messwert.
Meine persönliche Einschätzung: Monorepos werden nicht verschwinden. Für Teams, die wirklich konsistente Änderungen über viele Pakete durchziehen müssen – denken Sie an ein Design-System oder ein gemeinsames Auth-Framework – ist der Monorepo-Ansatz weiterhin einfacher zu orchestrieren. Aber für Enterprise-Organisationen, die bereits jahrelang in Multi-Repo-Strukturen investiert haben, macht ein gut konfigurierter Multi-Repo-Agent den Unterschied zwischen „wir müssen alles neu bauen“ und „wir können dort weiterarbeiten, wo wir sind“.
Ein konkretes Szenario: Ein Team möchte einen gemeinsamen Datentyp – zum Beispiel eine Nutzer-ID, die bisher als String durch alle Services gegeben wird – auf einen streng typisierten Wrapper umstellen. In einem Monorepo wäre das ein globales Refactoring mit einer sauberen Diff-Ansicht. Im Multi-Repo-Setup bedeutete das bisher: Service für Service, Repo für Repo, Pull Request für Pull Request.
Cursor IDE mit Workspace-Konfiguration kann hier lesend bereits viel: den Agent fragen, wo genau der String-Typ verwendet wird, welche Services ihn exportieren, welche importieren, und wo Typen-Inkompatibilitäten entstehen würden. Das ist die Dependency-Analyse-Funktion, die Enterprise-Teams am stärksten interessiert. Der Context-Graph, den Cursor über mehrere Repos aufbaut, macht genau das möglich.
Wo der Agent klar an Grenzen stößt: bei API- und Contract-Grenzen zwischen Services. Wenn Service A eine REST-API hat, die Service B konsumiert, und diese API sich durch das Refactoring ändert, braucht es mehr als nur Code-Analyse. Es braucht Contract-Tests, Schema-Validierung, versionierte API-Dokumentation und menschliches Review. Kein Agent der Welt ersetzt diesen Schritt zuverlässig – und das sollte niemand behaupten.
Im Ernst: Wer hofft, den Agenten einfach loszuschicken und nach dem Kaffee eine fertig refaktorierte Microservice-Landschaft vorzufinden, wird enttäuscht. Das ist kein Bastelprojekt mehr, das ist Produktions-Engineering mit echten Konsequenzen.
GitHub Copilot ist tief in VS Code und das GitHub-Ökosystem integriert, hat aber beim Multi-Repo-Kontext traditionell engere Grenzen: Der Fokus liegt auf dem aktuell geöffneten Repo und dem direkten Editor-Kontext. Für Repository-übergreifende Analyse muss man aktuell auf Workspace-Erweiterungen und externe Tooling-Integrationen setzen.
Windsurf – ein weiterer spannender Cursor-Konkurrent im Agentic-Coding-Segment – bringt seinen eigenen Multi-File-Editing-Ansatz mit, den das Cascade-System koordiniert. Der Fokus liegt dabei auf Session-basiertem Arbeiten, nicht unbedingt auf dauerhaftem Multi-Repo-Kontext. Beide Tools entwickeln sich schnell, aber Cursor IDE hat durch den Workspace-Ansatz und die explizite Diskussion von Multi-Repo-Workflows im Community-Bereich aktuell eine deutlichere Positionierung in diesem Bereich.
Erwähnenswert ist auch, dass spezialisierte Enterprise-Tools wie Moderne mit ihrem KI-Agenten auf eine andere Strategie setzen: statt IDE-Integration nutzen sie strukturierte Code-Repräsentationen (sogenannte Lossless Semantic Trees), um großflächige Multi-Repo-Transformationen über hunderte von Repositories durchzuführen. Das ist eine völlig andere Gewichtsklasse als IDE-basierte Assistenz und richtet sich an Organisationen mit wirklich massiven Legacy-Modernisierungsprojekten.
Für alle, die das jetzt direkt ausprobieren wollen – hier kommt der pragmatische Teil. Nerd-Alarm: Ja, das ist tatsächlich ein Bastelprojekt, aber eines mit Enterprise-Potenzial.
Schritt eins: Erstellen Sie eine .code-workspace-Datei, die die relevanten Repository-Pfade als Ordner-Array zusammenfasst. Schritt zwei: Definieren Sie in jedem Repository eine .cursorrules-Datei mit den spezifischen Konventionen dieses Services – Coding-Standards, Framework-Versionen, Architekturentscheidungen. So versteht der Agent, dass Service A TypeScript mit strikten Null-Checks verwendet und Service B Python mit Pydantic-Modellen.
Schritt drei – der entscheidende: .cursorignore konsequent einsetzen. Node-Module, Build-Verzeichnisse, generierte Proto-Dateien, Cache-Ordner – alles raus. Ihr Kontext-Budget ist endlich, und jedes irrelevante Byte verdrängt relevanten Code.
Schritt vier: Arbeiten Sie mit präzisen Agent-Prompts. Statt „Bitte refaktoriere den User-Service“ formulieren Sie: „Analysiere alle Stellen im Workspace, an denen der Typ UserID als String verwendet wird, und liste die betroffenen Dateien und Services mit ihren jeweiligen Import-Pfaden auf.“ Lesen vor Schreiben. Review vor Commit. Das ist keine Einschränkung – das ist professionelles Engineering.
Technische Konfiguration ist die eine Seite. Die andere – und im Unternehmensalltag oft die schwerere – ist die menschliche. Multi-Repo-Setups existieren in den meisten Organisationen nicht zufällig. Sie sind das Ergebnis bewusster Entscheidungen über Team-Autonomie, Deployment-Rhythmen und Service-Ownership. Wenn ein KI-Agent plötzlich Änderungsvorschläge über Repo-Grenzen hinweg macht, berührt das unweigerlich diese Ownership-Strukturen.
Ein realistisches Szenario: Team A betreibt den Authentifizierungsservice, Team B den Nutzer-Profil-Service. Beide verwenden denselben Datentyp. Cursor erkennt im Workspace, dass eine Typänderung beide Services betrifft, und schlägt koordinierte Anpassungen vor. Soweit gut. Aber wer reviewed den Pull Request in Team Bs Repository? Wer trägt die Verantwortung, wenn die Änderung in Team Bs nächstem Deployment-Fenster landet, bevor Team A fertig ist? Diese Fragen beantwortet kein Workspace-Konfigurationsfile.
Die Einführung von Multi-Repo-Agent-Workflows braucht deshalb mehr als technisches Setup. Sie braucht klare Absprachen darüber, wer Agent-generierte Cross-Repo-Vorschläge autorisiert, wie mit Änderungen umgegangen wird, die mehrere Teams gleichzeitig betreffen, und welche Service-Grenzen grundsätzlich als „hands-off“ für automatisierte Vorschläge gelten. Das ist Governance-Arbeit, keine Entwicklungsarbeit – und sie gehört vor den ersten Pilot-Commit.
Praktisch bewährt hat sich ein einfaches Prinzip: KI-Agent-Vorschläge, die über ein einzelnes Repository hinausgehen, werden wie externe Pull Requests behandelt – also nicht direkt gemergt, sondern immer mit mindestens einem menschlichen Review aus jedem betroffenen Team. Das klingt bürokratisch, verhindert aber, dass die Produktivitätsgewinne des Tools durch vermeidbare Regressionen aufgefressen werden.
Wer Multi-Repo-Agents produktiv einsetzen will, sollte typische Fallstricke kennen – nicht um abgeschreckt zu werden, sondern um sie gezielt zu vermeiden.
Ein häufiges Problem ist der sogenannte Stale-Context-Fehler: Der Agent hat beim Indexieren einen Stand der Repositories erfasst, der inzwischen veraltet ist. Wenn Team A in der Zwischenzeit einen Branch gemergt hat, der einen Typ umbenannt, eine Datei verschoben oder eine Abhängigkeit aktualisiert hat, arbeitet der Agent möglicherweise auf Basis falscher Annahmen. Regelmäßiges Re-Indexing und explizites Workspace-Reload vor größeren Analyse-Sessions sind daher keine Kür, sondern Pflicht.
Ein weiteres Risiko sind Silent Mismatches bei ähnlichen, aber nicht identischen Typen über Repos hinweg. Wenn Service A eine Klasse UserId hat und Service B eine nahezu identische Klasse UserIdentifier, erkennt der Agent möglicherweise eine konzeptuelle Verwandtschaft und schlägt eine Vereinheitlichung vor – obwohl beide Klassen absichtlich getrennt existieren, weil sie unterschiedliche Validierungslogiken implementieren. Gutes Prompt-Engineering und präzise .cursorrules-Definitionen helfen hier, aber das vollständig zu verhindern erfordert menschliches Kontextwissen, das kein Werkzeug ersetzen kann.
Schließlich: Dependency-Halluzinationen. In komplexen Workspaces mit vielen Repositories kann der Agent gelegentlich Abhängigkeiten zwischen Services „sehen“, die in der Realität nicht existieren – weil Dateinamen, Funktionsnamen oder Muster ähnlich aussehen, aber unterschiedliche Konzepte repräsentieren. Auch hier gilt: Analyse-Ergebnisse kritisch gegenprüfen, bevor darauf aufgebaut wird.
Cursor Multi-Repo Agents sind kein Selbstläufer, aber sie sind auch kein Hype ohne Substanz. Die Workspace-basierte Multi-Repo-Entwicklung in der Cursor IDE funktioniert heute für lesende Analyse, Dependency-Mapping und koordinierte Refactoring-Vorschläge über Service-Grenzen hinweg. Das ist für viele Enterprise-Teams bereits ein echter Produktivitätsgewinn gegenüber dem ewigen Fenster-Jonglieren.
Was noch fehlt: robuste, allgemein verfügbare Cloud-Agent-Unterstützung für schreibende Multi-Repo-Operationen – hier lohnt es sich, den Cursor-Changelog aktiv zu verfolgen, denn der Produktstand entwickelt sich schnell. Belastbare Benchmarks zur tatsächlichen Fehlerquote bei Cross-Repo-Refactorings existieren noch nicht öffentlich – wer Enterprise-Entscheidungen trifft, sollte das im Hinterkopf behalten.
Die ehrliche Empfehlung: Fangen Sie mit einem kontrollierten Pilot an. Nehmen Sie zwei bis drei eng verwandte Microservices, konfigurieren Sie einen sauberen Workspace mit klaren Regeln und Ignore-Dateien, und lassen Sie den Agenten erst lesen, dann vorschlagen. Committen Sie nichts ohne Review. Und – meine persönliche Lieblingsregel beim Arbeiten mit KI-Code-Tools – trauen Sie dem Agenten bei der Analyse, aber vertrauen Sie Ihrem Team beim Merge.
Die eigentliche Frage ist doch: Wenn KI-Agenten die Reibung zwischen Microservices-Repositories wirklich spürbar senken können, verändert das dann mittelfristig, wie wir Architekturentscheidungen zwischen Monorepo und Multi-Repo treffen – oder wird gute Schnittstellengestaltung immer der menschliche Part bleiben, den keine IDE der Welt ersetzt?
