Am 10. September hat Cursor die Funktion Projects veröffentlicht, derzeit als Beta für alle Nutzer geöffnet. Sie zielt auf Arbeiten ab, die sich über mehrere PRs erstrecken und Wochen oder sogar Monate dauern: neue Feature-Entwicklung, Framework-Migrationen oder der Aufbau einer kompletten Anwendung von Grund auf.
Die Struktur ist zweistufig. Die obere Ebene bildet ein koordinierender Agent, der selbst keinen Code schreibt, sondern nur Aufgaben an die Agenten darunter verteilt. Laut Cursor delegiert der Koordinator nur, führt aber nichts selbst aus – deshalb bleibt er nie an einer einzelnen Aufgabe hängen und kann jederzeit neue Anweisungen von Menschen entgegennehmen. Die untere Ebene besteht aus code-schreibenden Unteragenten; offiziellen Angaben zufolge kann ein Projekt Tausende davon steuern.
"It doesn't write code itself but directs other agents that do."
(Er schreibt selbst keinen Code, sondern dirigiert nur die anderen Agenten, die das tun.)
Drei zugrunde liegende Fähigkeiten
Projects stützt sich auf drei Dinge:
- Cloud-first: Projekte laufen auf dedizierten Servern und werden nicht unterbrochen, selbst wenn der Laptop zugeklappt wird;
- Geteilter Kontext: Dateien werden zwischen Cloud und lokalem Rechner synchronisiert, sodass spätere Agenten direkt auf das zurückgreifen können, was frühere Agenten bereits erschlossen haben;
- Abonnements: Ein Projekt kann einen Slack-Kanal im Blick behalten, nach Zeitplan laufen oder automatisch auf den Status von PRs reagieren.
Cursor nennt drei typische Anwendungsfälle. Bei neuen Features recherchieren mehrere Agenten zunächst parallel das bestehende System und implementieren dann getrennt einzelne Komponenten; bei Migrationen nutzen Teams das Tool, um Framework und Style-System schrittweise über Hunderte von PRs auszutauschen; bei der Wartung überwacht der Koordinator kontinuierlich Codequalität und Regressionen.
Das Beispiel mit dem Design-System
Am konkretesten beschreibt der Blogbeitrag die Wartung eines Design-Systems: Der Koordinator scannt jeden neuen PR, zieht Komponenten heraus, die ins Design-System aufgenommen werden sollten, und fügt eine Lint-Regel hinzu, sobald derselbe Fehler ein zweites Mal auftaucht. Nach Cursors Schätzung fallen bei solchen Projekten täglich 20 bis 100 PRs an.
Rechnet man grob durch, was dieses Volumen für Menschen bedeuten würde: Angenommen, ein sorgfältiges Review eines mittelgroßen PR dauert 15 bis 30 Minuten, dann sind 20 PRs pro Tag 5 bis 10 Stunden – gerade noch von einer Person zu schaffen; 100 PRs pro Tag wären 25 bis 50 Stunden, was bei 8 Arbeitsstunden pro Person und Tag drei bis sechs Vollzeit-Reviewer erfordern würde. Sobald die maschinelle Ausstoßgeschwindigkeit steigt, verlagert sich der Engpass auf das Review – es sei denn, das Team akzeptiert, dass ein Teil der PRs nur die automatisierten Checks durchläuft und dann gemergt wird. Cursor macht keine Angaben dazu, wie viele der von Projects erzeugten PRs vor dem Merge tatsächlich von Menschen geprüft wurden.
Woher die Sechsfach-Zahl kommt
Cursor nennt zwei Effektzahlen: Intern im Unternehmen mergen neue Nutzer 30 % mehr PRs; bei Nutzern, die überwiegend über Projects arbeiten, ist das Merge-Volumen sechsmal so hoch wie zuvor. Beide Zahlen stammen von Cursors eigenen Mitarbeitern, messen lediglich die Anzahl gemergter PRs und sagen nichts über PR-Größe, Nacharbeit oder Rollbacks aus; auch die Vergleichsbasis für die 30 % bleibt unklar. Daten von externen Teams liegen bislang nicht vor.
Zur Preisgestaltung äußert sich der Blogbeitrag nicht: weder ob Projects separat abgerechnet wird, noch nach welchem Maßstab Tausende gleichzeitig laufende Unteragenten verrechnet werden. Hunderte oder Tausende dauerhaft in der Cloud laufende Agenten dürften erhebliche Kosten verursachen – hier muss Cursor noch nachlegen.
Zwei Schritte, die sich zu einer Linie fügen
Betrachtet man Cursors Bewegungen im letzten halben Jahr, ist Projects der nächste Baustein in dieser Kette. Mit Version 3.0 im April positionierte Cursor die IDE als Oberfläche zur Steuerung von Agenten neu; Anfang September ermöglichte man es Cloud-Agenten dann, auf unternehmenseigenen Servern zu laufen. Projects verbindet beide Schritte: Menschen steuern den Koordinator, der Koordinator steuert die ausführenden Agenten, und diese können entweder in der Cloud oder auf den eigenen Servern des Unternehmens laufen.
Am selben Tag hat auch OpenAI seine Agents API veröffentlicht, die ebenfalls erlaubt, dass ein Hauptagent Aufgaben an Unteragenten aufteilt – doch die beiden Unternehmen setzen an unterschiedlichen Stellen an: OpenAI verkauft Entwicklern die Grundlage zum Bau eigener Agenten, Cursor verkauft Teams ein fertiges Produkt, das die Arbeit direkt übernimmt. Der Einstiegspunkt für Projects liegt in der linken Navigationsleiste; offiziell empfiehlt Cursor die Nutzung nur für Arbeiten, die sich über mehrere PRs erstrecken oder längere Zeit andauern.
Quellen: offizieller Cursor-Blog, CocoLoop, MarkTechPost; Angaben zur Größe der Unteragenten, zur Höhe des PR-Merge-Zuwachses und zu den Fallbeispielen wurden anhand des Cursor-Blogs geprüft.