AIREITERCursors Architektur aus Koordinator und Subagents ist für große Codebase-Migrationen tatsächlich hilfreich – allerdings nicht als unbeaufsichtigter Rewrite-Knopf. Besonders stark ist der Ansatz, wenn sich die Arbeit in klar abgegrenzte und testbare Teilaufgaben zerlegen lässt. Riskant wird es, sobald mehrere Agents gemeinsame Verträge, Dateien oder nicht dokumentierte Geschäftsregeln berühren. Auch die Bezeichnung „Projects“ sollte man mit etwas Vorsicht verwenden: Die aktuelle offizielle Dokumentation konzentriert sich auf Subagents, asynchrone Ausführung, Cloud Agents und lang laufende Coding-Aufgaben – nicht auf eine einzige, durchgehend dokumentierte Projects-Produktseite.
Was Cursor Projects Beta Migrationsteams tatsächlich bietet
In der aktuellen Dokumentation zu Subagents beschreibt Cursor einen übergeordneten Agent, der spezialisierte Aufgaben an separate Kontextfenster delegiert. Ein Subagent liefert sein Ergebnis an den übergeordneten Agent zurück, kann im Vordergrund oder Hintergrund laufen und mit eigenen Tools, Modellen und Schreibrechten konfiguriert werden.
Für eine Migration ist das die entscheidende architektonische Einheit: Ein Koordinator behält Umfang und Entscheidungen im Blick, während Spezialisten das Repository analysieren, klar begrenzte Änderungen implementieren, Tests ausführen oder Ergebnisse prüfen. Cursor dokumentiert außerdem Cloud Subagents mit eigener virtueller Maschine, eigenem Branch und eigenem Repository-Klon. Das ist deutlich sicherer, als mehrere Agents am selben Checkout arbeiten zu lassen.
Der Beta-Hinweis ist wichtig. In einer Cursor-Veröffentlichungsdiskussion vom Februar 2026 wurden asynchrone und verschachtelte Subagents angekündigt. Nutzer berichteten jedoch von unzuverlässiger Ausführung im Hintergrund; laut einer Antwort eines Cursor-Mitarbeiters sollte ein Problem mit is_background: true in Cursor 2.6 behoben werden. Verfügbarkeit und Verhalten sollten daher als versionsabhängig gelten – nicht als garantiert zuverlässige Steuerungsebene.
Der Migrations-Workflow, bei dem Koordination wirklich hilft
Ein Koordinator ist dann wertvoll, wenn er die Reihenfolge und Abhängigkeiten steuert – nicht, wenn er jede einzelne Zeile selbst schreiben soll. Für eine Migration von Framework oder Programmiersprache bietet sich folgende Aufgabenverteilung an:
| Rolle | Sinnvolles Ergebnis | Warum ein eigener Kontext sinnvoll ist |
|---|---|---|
| Repository-Explorer | Abhängigkeitskarte, Einstiegspunkte, Grenzen generierten Codes | Suchergebnisse können den Haupt-Thread überladen |
| Migrationsplaner | Geordnete Arbeitspakete und Invarianten | Planung braucht den Blick auf das gesamte Repository |
| Implementierer | Änderungen in einem Modul, Service oder Worktree | Ein enger Scope reduziert unerwünschte Nebenänderungen |
| Test-Agent | Neue und bestehende Prüfungen für einen Teilbereich | Testprotokolle sind umfangreich und unabhängig verwertbar |
| Reviewer | Hinweise zu Regressionen, Sicherheit und Konventionen | Ein frischer Kontext ist weniger in die Implementierung investiert |
| Koordinator | Vertragsprüfungen, Konfliktentscheidungen, nächste Welle | Eine Stelle muss widersprüchliche Ergebnisse zusammenführen |
Cursors Bericht über lang laufende Coding-Aufgaben beschreibt eine ähnliche Struktur aus Planern, Arbeitern und Prüfer. Im Solid-to-React-Experiment berichtet Cursor von mehr als drei Wochen Arbeit sowie ungefähr 266.000 Hinzufügungen und 193.000 Löschungen – weist aber zugleich darauf hin, dass eine sorgfältige Prüfung weiterhin notwendig war. Das zeigt, dass die Architektur ein umfangreiches Vorhaben tragen kann. Es zeigt nicht, dass eine Migration dadurch automatisch produktionssicher wird.
Wo die Architektur in großen Codebasen ihre Stärken ausspielt
1. Bestandsaufnahme und Abhängigkeitsanalyse
Große Migrationen scheitern oft schon am Anfang, weil ein Callsite, ein Build-Skript, eine generierte Datei oder eine Annahme im Deployment übersehen wird. Ein eigener Explorer kann diese Bereiche durchsuchen, während der Koordinator die Ergebnisse in ein Migrationsprotokoll überführt.
Das ist belastbarer, als einen einzelnen Agent mit der Aufgabe „Migriere das Repository“ loszuschicken, denn die Ergebnisse bleiben nachvollziehbar: betroffene Pakete, Abhängigkeiten, öffentliche Schnittstellen, Testabdeckung und offene Annahmen. Cursors Leitfaden zur Modernisierung empfiehlt den Plan Mode, .cursor/plans/ und Migrationsregeln wie .cursor/rules/migration.mdc.
2. Wiederholbare, klar begrenzte Transformationen
Subagents eignen sich gut für Aufgaben wie das Ersetzen veralteter API-Aufrufe, die Umstellung abgegrenzter Module oder die Migration von Services mit stabilen Schnittstellen. Die sichere Grenze ist dabei nicht einfach ein Ordnername. Ein sinnvoller Teilbereich braucht:
- Einen klar benannten Verantwortlichen und einen definierten Dateibereich.
- Einen schriftlich festgehaltenen Input-/Output-Vertrag.
- Einen Build- und Test-Befehl.
- Einen Branch oder isolierten Worktree.
- Eine eindeutige Definition of Done.
Cursors Dokumentation warnt davor, mehrere Subagents im Standard-Checkout arbeiten zu lassen, da sie sich gegenseitig überschreiben können. Isolierte Worktrees oder Cloud-Branches halten die Änderungen getrennt, bis der Koordinator oder ein Mensch sie zusammenführt.
3. Warteschlangen für Wartung und Prüfungen im Hintergrund
Wartungsaufgaben bieten oft natürliche Parallelität: Flaky Tests untersuchen, Warnungen zu Abhängigkeiten prüfen, Dokumentation aktualisieren und einen Pull Request reviewen können unabhängig voneinander laufen. Die Ausführung im Hintergrund hält den übergeordneten Prozess reaktionsfähig, während Cloud Agents ihre Arbeit auf eigenen virtuellen Maschinen fortsetzen können.
Für Reviews bietet Cursors Dokumentation zu Agent Review die Modi Quick und Deep. Deep Review ist langsamer und teurer; Cursor empfiehlt ihn für komplexe Logik, sicherheitskritischen Code und umfangreiche Refactorings. Im Source-Control-Workflow wird der vollständige lokale Änderungsumfang mit dem Main-Branch verglichen – nicht nur die zuletzt vorgenommene Änderung.
Genau deshalb ist die Architektur auch für Wartungsaufgaben interessant. Das Review muss aber ein echtes Gate bleiben. Ein positiver Bericht eines Child-Agents ist nicht dasselbe wie ein erfolgreiches Integrationstestergebnis oder ein freigegebener Pull Request.
Wo Workflows mit Koordinator und Subagents an ihre Grenzen stoßen
Übergreifende Verträge begrenzen die sichere Parallelisierung
Änderungen an Frontend, Backend, Datenbank und Services lassen sich nicht automatisch parallelisieren, nur weil sie in unterschiedlichen Verzeichnissen liegen. Eine Schemaänderung kann eine API ungültig machen, eine API-Änderung generierte Clients brechen und eine gemeinsam verwendete Utility dafür sorgen, dass zwei vermeintlich unabhängige Änderungen kollidieren.
Ein Feature Request im Cursor-Forum für einen „Monorepo Execution Plan“ beschreibt die fehlende Disziplin ziemlich treffend: Abgegrenzte Worker sollen globale Anforderungen, API-Verträge und Schemaänderungen erhalten; anschließend soll ein Koordinator vor der Integration Routen, Typen und Schemas prüfen. Dieser Beitrag ist allerdings ein Wunsch nach einer Funktion – kein Beleg dafür, dass der gesamte Ablauf heute bereits schlüsselfertig funktioniert.
Bei Migrationen sollten Verträge feststehen, bevor Implementierungs-Agents gestartet werden. Muss sich ein Vertrag ändern, braucht es entweder eine Kompatibilitätsphase oder eine neue, vom Koordinator sequenziell getroffene Entscheidung.
Kontext-Isolation bedeutet auch Kontextverlust
Subagents starten mit einem sauberen Kontext und übernehmen nicht automatisch die Unterhaltung des übergeordneten Agents. Der Koordinator muss die relevanten Regeln, Zielmuster, Einschränkungen und Artefakte ausdrücklich weitergeben. In einer kurzen Zusammenfassung kann genau die Randbedingung verloren gehen, die einige Stunden später entscheidend ist.
Verlasse dich deshalb nicht auf Gesprächserinnerungen, sondern auf dauerhafte Artefakte:
migration-plan.mdfür Umfang und Reihenfolge.migration-ledger.csvfür Paketstatus und Ausnahmen.contracts/für API- und Schema-Snapshots.decisions.mdfür verworfene Alternativen.- Einen Testbericht zu jedem Implementierungs-Branch.
Damit lassen sich auch veraltete Entscheidungen besser erkennen. Ein persistenter Koordinator kann die Historie bewahren, aber Historie ist nicht automatisch Wahrheit. Nach Updates von Abhängigkeiten, Schemaänderungen oder neu entdecktem Legacy-Verhalten müssen Annahmen erneut geprüft werden.
Mehr Agents können höhere Kosten und mehr Störungen bedeuten
Cursors Dokumentation schätzt, dass fünf parallel laufende Subagents ungefähr fünfmal so viele Tokens verbrauchen wie eine vergleichbare Arbeit mit nur einem Agent. Außerdem weist die Dokumentation darauf hin, dass bei blockierten Modellen, nicht unterstützten Modellen im Tarif oder einem Legacy-Tarif mit erforderlichem Max Mode ein Fallback greifen kann. Plane daher nicht nur mit dem Modell des übergeordneten Agents.
Rückmeldungen aus der Praxis zeigen, warum dafür ein expliziter Regelkreis nötig ist:
„Zu wenige, und Nachrichten bleiben ewig in der Warteschlange; zu viele, und sie fangen an, sich gegenseitig zu behindern“ – @siggelabor, X
In einer Reddit-Diskussion berichten Nutzer, dass Subagents unerwartet viel Modellnutzung verbrauchten. Einige setzten auf .cursorrules, um Delegation einzuschränken, räumten aber ein, dass diese Regel nicht garantiert eingehalten wurde. Begrenze die Parallelität, setze günstigere Modelle für die Exploration ein, reserviere leistungsfähigere Modelle für Planung und Review und prüfe die Nutzung, bevor du die nächste Welle startest.
Grüne Tests beweisen noch keine erfolgreiche Migration
Das SWE-Refactor-Bench-Preprint ist eine wichtige Warnung für jeden Test der Cursor Projects Beta. In 520 Durchläufen mit 20 Migrationstasks auf vollständigen Repositories bestanden nur 28 Durchläufe – 5,4 % – gleichzeitig das Migrationsaudit, die Verhaltenstests und die adversariale Verifikation. Außerdem stellte die Studie fest, dass Sprachmigrationen im Schnitt 5,6/100 erreichten, während Rewrite-Aufgaben an Build-Toolchains auf 31,4/100 kamen.
Die methodische Schlussfolgerung ist klar: Eine Migration braucht getrennte Gates für Ersetzung und Bewahrung. Prüfe zunächst, ob der alte Stack aus Quellcode und Build-Abschluss verschwunden ist. Vergleiche danach das Verhalten und nutze anschließend eine unabhängige Verifikation, um versteckte Abweichungen aufzuspüren. „CI ist grün“ ist ein Signal – aber nicht das Urteil.
So lässt sich Cursor sicherer für eine Migration einsetzen
- Das alte System als Ausgangsbasis erfassen. Dokumentiere Build-Befehle, öffentliche Schnittstellen, repräsentative Ausgaben, performancekritische Pfade und bekannte Ausnahmen, bevor du den Code änderst.
- Einen Explorer mit Leserechten das Repository kartieren lassen. Beziehe Pakete, generierte Artefakte, Konfiguration, Deployment-Skripte und Lücken in der Testabdeckung ein.
- Migrationsplan und Protokoll anlegen. Teile die Arbeit nach Verhalten und Verantwortlichkeit auf – nicht nur nach Verzeichnissen.
- Mit einem abgegrenzten Teilbereich starten. Eine migrierte Referenzimplementierung legt Namensgebung, Fehlerbehandlung, Kompatibilität und Testkonventionen fest.
- Begrenzte Implementierer in isolierten Branches starten. Gib jedem Prompt den exakten Vertrag und die Pfade vor, die nicht verändert werden dürfen.
- Jeden Teilbereich lokal validieren. Type-Checks, Unit-Tests, Integrationstests, Build-Ausgabe und eine Zusammenfassung des Diffs müssen vor einer Erfolgsmeldung vorliegen.
- Ein unabhängiges Review durchführen. Setze einen frischen Reviewer ein und wähle Deep Agent Review für risikoreiche oder bereichsübergreifende Änderungen.
- In Wellen integrieren. Der Koordinator führt Verträge zusammen; ein Mensch gibt Merges frei, die Daten, Authentifizierung, Infrastruktur oder öffentliche APIs betreffen.
- Differenzielle Prüfungen wiederholen. Vergleiche das migrierte System anhand repräsentativer Eingaben und Fehlerpfade mit der Ausgangsbasis.
- Stoppen, sobald die Evidenz schlechter wird. Mehr Parallelität ist kein Fortschritt, wenn Warteschlangen, Konflikte, Wiederholungen oder Review-Funde zunehmen.
Cursor Projects Beta: Eignung nach Aufgabenbereich
| Aufgabe | Eignung | Empfehlung |
|---|---|---|
| Wiederholte Änderungen in unabhängigen Modulen | Hoch | Parallele Implementierer mit isolierten Branches und gemeinsamen Regeln einsetzen |
| Upgrade von Abhängigkeiten oder Frameworks | Mittel bis hoch | Zuerst planen, ein Modul als Pilot migrieren und anschließend in Wellen erweitern |
| Großer Sprach-Rewrite mit schwacher Testabdeckung | Mittel bis niedrig | Agents für Bestandsaufnahme und Teilbereiche einsetzen; die Verhaltensvalidierung in menschlicher Hand behalten |
| Schema- und API-Migration über mehrere Services | Mittel | Vertragsentscheidungen sequenziell treffen und die Implementierung erst nach Stabilisierung des Vertrags parallelisieren |
| Laufende Pflege von Tests, PRs und Abhängigkeiten | Hoch | Hintergrund- oder Cloud Agents mit Limits für Parallelität und Kosten einsetzen |
| Einmalige Formatierungs- oder Changelog-Arbeit | Niedrig | Ein Kommando oder eine Skill verwenden; ein Subagent erzeugt unnötigen Overhead |
| Deterministisches Massen-Umbenennen mit guter Testabdeckung | Mittel | Skripte und CI bevorzugen, wenn die Transformation mechanisch und einfach rückgängig zu machen ist |
Mein Urteil: Cursors Architektur aus Koordinator und Subagents ist für große Migrationen einen Pilotversuch wert, wenn das Repository testbare Grenzen besitzt und das Team die Isolation der Branches konsequent durchsetzen kann. Bei einem schlecht dokumentierten System mit schwacher Verhaltensabdeckung sollte der Koordinator als Manager für Bestandsaufnahme und Verifikation dienen – nicht als autonomer Implementierer.
FAQ zur Cursor Projects Beta
Ist die Cursor Projects Beta dasselbe wie Cursor Subagents?
Cursors offizielle Dokumentation ist um Subagents, asynchrone Ausführung, Cloud Agents und Multi-Agent-Coding herum organisiert. „Projects“ ist eine Beta-Bezeichnung, deren Umfang je nach Version und Account variieren kann.
Können Cursor Subagents parallel laufen?
Ja. Unabhängige Aufgaben brauchen aber weiterhin klar definierte Scopes, Verträge und isolierte Worktrees, damit es nicht zu Konflikten kommt.
Kann ein Subagent einen weiteren Subagent starten?
Cursor dokumentiert verschachtelte Subagents. Setze sie sparsam ein, denn tiefere Agent-Bäume erhöhen den Aufwand für Koordination, Tokens und Verifikation.
Arbeiten die Agents weiter, wenn ich den Laptop zuklappe?
Cloud Subagents können auf eigenen virtuellen Maschinen weiterarbeiten. Cursor weist darauf hin, dass die lokale MCP-Konfiguration in der Cloud nicht automatisch wiederverwendet wird.
Kann ich für jeden Subagent ein bestimmtes Modell erzwingen?
Cursor unterstützt vererbte oder spezifische Modelle. Regeln für Administratoren, Tarife und Legacy-Tarife können jedoch einen Fallback auslösen. Prüfe deshalb, welches Modell tatsächlich verwendet wurde.
Wie verhindere ich, dass Subagents weitere Agents starten?
Nutze Aufgabenanweisungen und Repository-Regeln und prüfe anschließend das Verhalten für deinen Tarif und deine Version. Nutzerberichte legen nahe, dass diese Steuerungsmöglichkeiten nicht immer garantiert funktionieren.
Diese Entscheidung solltest du vor dem Agent-Swarm treffen
Führe einen einwöchigen Pilotversuch mit einem einzelnen Migrationsabschnitt durch. Übernimm den Ansatz nur dann, wenn die Zahl der in die Produktion gelangenden Regressionen nicht steigt und die Zeitersparnis den zusätzlichen Aufwand für Koordination, Reviews und Modellnutzung übersteigt. Andernfalls sind für diese Art von Änderung Skripte, CI oder ein einzelner Agent die bessere Wahl.