Cursor AI im Team: Mit Projects wird Review zum Engpass

Cursor Projects ordnet die Arbeit mit Cursor AI neu: Nicht mehr der einzelne Prompt ist die Arbeitseinheit, sondern eine Review-Warteschlange. Am 10. September 2026 brachte Cursor in einer Beta einen Koordinator, gemeinsamen Projektkontext und wiederkehrende Trigger zusammen. Teams können Aufgaben damit delegieren, ohne jeden Lauf von Hand anzustoßen – und der Engpass wandert zu Zuschnitt, Prüfung und Merge-Entscheidung.

Dieser Artikel betrachtet das System aus Betriebssicht – für Engineering-Leads, technische Gründer und Agenturinhaber. Entscheidend ist nicht, wie viele Agenten Cursor starten kann. Entscheidend ist, ob ein Team die zurückgelieferte Arbeit bewältigt, ohne die Kontrolle über Kosten oder Qualität zu verlieren.

Was Cursor AI mit Projects tatsächlich leistet

Ein Cursor Project ist ein dauerhaft angelegter Arbeitsraum für ein größeres Vorhaben, etwa ein Feature, eine Migration oder eine vollständige App. Dazu gehört ein Koordinator-Agent, der in diesem Modell die Leitung übernimmt. Er plant und delegiert die Umsetzung, schreibt den Code aber nicht selbst.

Die eigentliche Programmierarbeit erledigen Implementierungsagenten auf Cloud-Rechnern. Der Koordinator kann mehrere davon anlegen, Aufgaben parallel ausführen lassen und die Ergebnisse zur Prüfung zurückbringen. Muss ein Test auf dem eigenen Rechner laufen, kann er dort einen lokalen Agenten starten.

Hinzu kommt der gemeinsame Kontext. Jedes Project verwaltet Dateien, die zwischen den Cloud- und lokalen Rechnern der eingesetzten Agenten synchronisiert werden. Darin lassen sich Recherche, Artefakte, Wissen über die Codebasis, Testanweisungen und teaminterne Arbeitsregeln sammeln.

Damit verändert sich die Übergabe: Ein neuer Agent muss Testbefehl oder Servicegrenze nicht bei jedem Lauf erneut herausfinden – vorausgesetzt, der gespeicherte Project-Kontext ist korrekt und aktuell.

Als drittes Element kommen Abonnements hinzu. Ein Project kann einen Slack-Kanal beobachten, nach Zeitplan laufen oder Pull Requests verfolgen. Ein passendes Signal stößt dann neue delegierte Arbeit an, ohne dass jemand einen weiteren Prompt schreiben muss.

Wiederkehrende Agenten sind bei Cursor an sich nicht neu. Schon das Release vom 19. August erlaubte Cloud Agents, Pull Requests, Slack-Threads und Zeitpläne zu überwachen. Projects bündelt diese wiederkehrende Arbeit unter einem Koordinator und ergänzt gemeinsamen Kontext, der über einen längeren Aufgabenstrom erhalten bleibt.

Genau darin liegt die eigentliche Neuerung. Cursor liefert nicht bloß einen weiteren Coding-Chat, sondern gibt delegierter Arbeit ein dauerhaftes Zuhause.

Warum die Review-Warteschlange wirtschaftlich entscheidend ist

Gemeinsamer Kontext kann wiederholte Einrichtungsschritte reduzieren. Cursor hat jedoch keinen Wert für den Zeitgewinn veröffentlicht, und für belastbare Aussagen ist diese Beta noch zu neu. Eingesparte Stunden gehören deshalb noch in kein Budget.

Messbar verändert sich zunächst, wofür das Team seine Zeit aufwendet. Ein Koordinator kann Implementierungsaufgaben auf mehrere parallele Spuren verteilen, während ein einzelner Reviewer die Änderungen weiterhin nacheinander liest. Aus diesem Missverhältnis kann statt eines leeren Backlogs eine volle Pull-Request-Warteschlange entstehen.

Nützlich ist diese Warteschlange, wenn Aufgaben eng zugeschnitten, Tests zuverlässig und Entscheidungen schnell möglich sind. Teuer wird sie, wenn Agenten umfangreiche Diffs, doppelte Arbeit oder Änderungen mit unklarem Zweck liefern. Parallel erzeugte Ergebnisse bleiben unbearbeiteter Bestand, bis jemand sie akzeptiert.

Nicht alle Cursor-Nutzer betrifft das gleichermaßen. Wer allein jeweils eine klar begrenzte Aufgabe bearbeitet, gewinnt durch einen Koordinator womöglich wenig. Ein Team mit schwachen Tests oder ohne benannten Reviewer kann mehr Unsicherheit als Durchsatz erzeugen. Für Teams mit bestehenden, wiederkehrenden Cloud-Agent-Automatisierungen liegt der größte Gewinn im gemeinsamen Project-Kontext – nicht im Trigger selbst.

Wer profitiert – und was sich konkret ändert

Engineering-Lead eines SaaS-Teams bei einer Migration

Ein Project erhält eine klar begrenzte Migration samt ausdrücklichen Nicht-Zielen, Testbefehlen, Rollout-Regeln und Zuständigkeitsgrenzen. Der Koordinator kann mechanische Änderungen auf Implementierungsagenten verteilen, während der Lead die Reihenfolge und die riskanten Randbereiche prüft.

Der Nutzen liegt in der Kontinuität über mehrere Branches hinweg. Gemessen werden sollten akzeptierte Änderungen und Review-Zeit – nicht die Aktivität der Agenten.

Technische Leitung einer Agentur im Kundengeschäft

Einrichtungshinweise, Coding-Konventionen, Testpfade und Auslieferungsregeln eines Kunden gehören in dessen eigenen gemeinsamen Project-Kontext. Wiederkehrende Wartungsaufgaben starten dadurch mit denselben Betriebsanweisungen statt mit einem neuen Onboarding-Prompt.

Das spart wiederholte Einweisungen. Die harte Grenze bleibt die Trennung der Kunden: Kontext und Zugangsdaten eines Accounts dürfen nie im gemeinsamen Bestand eines anderen landen.

Support-Engineering-Manager mit Blick auf neue Fehlerberichte

Ein öffentlicher Slack-Kanal für Fehlerberichte wird mit einer eng gefassten Qualifizierungsregel verbunden. Meldungen mit reproduzierbaren Schritten können in das Project gelangen; Fragen, Duplikate und accountspezifische Vorfälle bleiben bei einem Menschen.

Das Ergebnis soll ein vorbereiteter Branch samt Belegen für das Review sein – kein automatischer Merge. Die aktuellen Automations-Dokumente von Cursor beschränken Slack-Trigger auf öffentliche Kanäle; für Projects wurde keine eigene Übersicht der unterstützten Kanäle veröffentlicht.

Plattformteam mit wiederkehrender Wartung

Ein Project kann Testanweisungen und die Serviceübersicht für einen laufenden Wartungsstrom aufnehmen. Der Koordinator verfolgt Pull Requests oder einen Zeitplan und liefert die Umsetzung anschließend an eine namentlich zuständige Person zurück.

Der Vorteil ist ein stabiler Betriebsablauf. Regulierte Teams sollten warten, bis ihre Sicherheitsprüfung die Cloud-Laufzeit, den synchronisierten Kontext, Secrets und die Beta-Kontrollen abdeckt.

So gelingt ein begrenzter Teampilottest

Cursor hat weder eine Projects API noch eine ausführliche Einrichtungsanleitung für Projects veröffentlicht. Ein seriöser Pilotversuch nutzt daher die sichtbare Beta-Oberfläche und die zugehörigen, heute dokumentierten Cloud-Agent-Kontrollen.

1. 1

   Zugang und Abrechnung prüfen

   In der linken Navigation von Cursor nach Projects suchen. Laut Ankündigung wird die Beta für alle Nutzer ausgerollt, Cloud Agents setzen jedoch weiterhin einen kostenpflichtigen Tarif voraus. Vor einem Teampilottest müssen die Freischaltung im tatsächlichen Account und der Sitztyp geprüft sowie ein teamweites Ausgabenlimit festgelegt werden – noch bevor ein wiederkehrender Trigger hinzukommt.

2. 2

   Eine wiederholbare Aufgabe auswählen

   Geeignet sind ein Repository und eine Klasse risikoarmer Aufgaben mit eindeutigem Endpunkt. Gute Kandidaten besitzen einen bekannten Testbefehl, eine kleine Diff-Grenze und eine verantwortliche Person, die das Ergebnis beurteilen kann. Migrationen mit ungeklärten Produktentscheidungen, Änderungen an Berechtigungen und Produktionsvorfälle gehören nicht in den ersten Durchlauf.

3. 3

   Den gemeinsamen Betriebskontext festhalten

   In das Project gehören Repository-Übersicht, Einrichtungsschritte, Testbefehle, Definition of Done, gesperrte Bereiche und Eskalationsregel. Diese Dateien sind laufend gepflegte Betriebsdokumente. Falscher gemeinsamer Kontext wiederholt einen Fehler lediglich effizienter.

4. 4

   Einen Eingangskanal hinzufügen

   Zur Wahl stehen ein Zeitplan, ein Pull-Request-Abonnement oder ein Slack-Kanal. Festzulegen ist, welche Signale zählen, was der Koordinator delegieren darf, welche Belege zurückkommen müssen und wann er ohne Codeänderung stoppen soll.

5. 5

   Die Review-Warteschlange klar verantworten

   Ein erfahrener Reviewer übernimmt die Verantwortung. Bevor eine Änderung weitergehen darf, müssen Diff, Testergebnis und relevante Artefakte vorliegen. Die Merge-Berechtigung bleibt während der Beta außerhalb des Projects.

6. 6

   Nur Arbeit messen, die das Review besteht

   Erfasst werden gestartete Arbeitspakete, akzeptierte Änderungen, Review-Minuten, Nacharbeit, Fehler nach Auslieferung und Modellnutzung. Diese Werte werden mit derselben Aufgabenklasse vor dem Pilotversuch verglichen. Die Zahl der Agenten ist kein Produktivitätsmaß.

Pilotkosten mit Review-Zeit kalkulieren

Der Basistarif ist leicht zu beziffern. Teams Standard kostet $40 pro Nutzer und Monat; vier neue Sitze kosten für einen Abrechnungszeitraum also $160. Teams Premium kostet $120 pro Nutzer und Monat und umfasst das Fünffache der Standard-Nutzung. Premium zu buchen, bevor der Pilotversuch eigene Nutzungsdaten liefert, würde allerdings den wertvollsten Teil des Tests überspringen.

Schwieriger ist der variable Anteil. Cloud Agents werden nach den API-Preisen des ausgewählten Modells abgerechnet. Bei Teams und Enterprise kommt für berechtigte Ein-, Ausgabe- und Cache-Token von Drittanbietern eine Cursor Token Rate von $0.25 je eine Million Token hinzu. On-Demand-Nutzung ist bei Teams standardmäßig aktiviert; Teamadministratoren können eine monatliche Obergrenze für das gesamte Team setzen.

Das folgende Modell ist bewusst begrenzt; jede Angabe zur Arbeitslast ist als Annahme gekennzeichnet:

• Umfangsannahme: ein Repository, ein Trigger und höchstens 20 Arbeitspakete, die das Review erreichen.
• Nutzungsannahme: Jedes vollständige Arbeitspaket verbraucht einschließlich der Tätigkeit von Koordinator und Implementierungsagenten 100,000 nicht zwischengespeicherte Eingabe-Token, 400,000 aus dem Cache gelesene Token und 20,000 Ausgabe-Token mit Claude Sonnet 5; Cache-Write-Token fallen nicht an.
• Review-Annahme: Ein erfahrener Reviewer reserviert pro zurückgeliefertem Arbeitspaket 20 Minuten zu Vollkosten von $100 pro Stunde.

Mit den aktuellen Tarifen für Claude Sonnet 5 von Cursor kostet das modellierte Arbeitspaket $0.20 für die Eingabe, $0.08 für Cache-Zugriffe und $0.20 für die Ausgabe. Für 520,000 berechtigte Token kommen $0.13 als Team-Tokenrate hinzu. Die modellierte Nutzung liegt damit bei $0.61 je Arbeitspaket beziehungsweise $12.20 für 20 Arbeitspakete.

Der größere Posten ist das Review. Zwanzig Arbeitspakete zu je 20 Minuten ergeben 400 Minuten, also 6 Stunden 40 Minuten. Beim angenommenen Stundensatz von $100 sind dafür $666.67 an Reviewer-Zeit anzusetzen.

Zusammen mit $160 für vier neue Standard-Sitze und der modellierten Nutzung – unabhängig davon, ob sie tatsächlich als Mehrverbrauch abgerechnet wird – ergibt sich eine Brutto-Planungssumme von $838.87 für den Monat. Das ist keine Rechnungsprognose. Vorhandene Sitze machen den Kauf von $160 überflüssig, enthaltene Nutzung kann die $12.20 abdecken, und echte Projects-Aufgaben können mehr Token verbrauchen, weil der Koordinator an mehrere Agenten delegieren kann.

Das Modell soll nicht behaupten, dass Reviews immer $666.67 kosten. Es macht sichtbar, dass Review-Arbeit eine eigene Budgetposition braucht. Aufgabenmenge, Minuten und Vollkostensatz müssen zum jeweiligen Team passen, bevor der Pilotversuch als günstig gilt.

Für die übergreifende Produkt- und Tarifentscheidung behandelt der ausführliche Cursor-Test den Editor, Cloud Agents, Preise und bestehende Review-Schranken.

Die nüchterne Einordnung

Erstens handelt es sich um einen Beta-Rollout, nicht um einen etablierten Betriebsstandard. Die Ankündigung nennt die linke Navigation, liefert aber weder eine Projects-spezifische Zugangsmatrix noch eine Nutzungsaufschlüsselung, Parallelitätssteuerung oder Leistungszusage. Die Funktion kann verfügbar sein, bevor die für eine Beschaffung nötige Dokumentation vorliegt.

Zweitens kann gemeinsamer Kontext veraltete Anweisungen genauso gut verbreiten wie hilfreiche. Ein Testhinweis, der im vergangenen Monat noch stimmte, kann nach einer Änderung am Repository jeden künftigen Agenten fehlleiten. Kontextdateien brauchen Verantwortliche, Prüftermine und Löschregeln.

Drittens liefert der Koordinator Arbeit zur Prüfung zurück. Genau das ist der Produktvertrag. Menschliches Review, ausführbare Tests, Sicherheitsprüfungen und Merge-Verantwortung entfallen dadurch nicht.

Viertens entscheidet weiterhin die Umgebung, ob ein Agent seine Arbeit belegen kann. Cloud Agents benötigen die für eine Aufgabe erforderlichen Repositories, Abhängigkeiten, Secrets, Startbefehle und Netzwerkzugriffe. Scheitert ein Environment Build, bleibt der letzte erfolgreiche Build aktiv; eine unvollständige Umgebung kann dennoch plausibel wirkenden Code ohne gültigen Nachweis produzieren.

Schließlich läuft jedes Project auf einem Cloud-Rechner; lokale Agenten kommen zum Einsatz, wenn maschinenspezifische Tests nötig sind. Teams mit Anforderungen an private Netzwerke müssen diese Grenze in die Prüfung aufnehmen. Cursor Self-Hosted Machines kann die Werkzeugausführung auf kundeneigene Worker verlagern, die Agentenschleife von Cursor und die Modellverarbeitung bleiben jedoch in der Cursor-Cloud.

Was jetzt sinnvoll ist

Ein Start noch in dieser Woche ist sinnvoll, wenn ein Team wiederholbare, testbare Arbeit hat, die Beta in einem kostenpflichtigen Cursor-Account sichtbar ist und ein erfahrener Reviewer freie Kapazität in der Warteschlange besitzt. Für den Anfang genügen Standard-Sitze, ein Repository, ein Trigger und ein hartes Ausgabenlimit.

Abwarten sollte, wer Projects noch nicht sieht, dessen Repository seine Prüfungen nicht in einer Cloud-Agent-Umgebung ausführen kann oder bei dem niemand das Review verantwortet. Dasselbe gilt, wenn die Beschaffung ein Projects-spezifisches Zugangs- oder Abrechnungsdokument verlangt, das Cursor noch nicht veröffentlicht hat.

Weitgehend unverändert bleibt die Lage bei einmaligen Aufgaben, Agentensitzungen mit bereits ausreichendem Kontext oder zwingend lokaler Ausführung. Der Koordinator lohnt sich nur, wenn die Kontinuität über mehrere delegierte Aufgaben hinweg der Engpass ist.

Der konkrete Schritt am Montag: eine wiederkehrende Aufgabenklasse wählen, den Pilotversuch auf 20 prüfbare Arbeitspakete begrenzen, einen Reviewer benennen, das teamweite Ausgabenlimit setzen und über einen Abrechnungszeitraum hinweg akzeptierte Änderungen, Review-Minuten, Nacharbeit, Fehler und tatsächliche Nutzung erfassen. Projects bleibt nur dann, wenn die geprüften Ergebnisse den Workflow verbessern – nach Einrechnung sowohl der Modellkosten als auch der menschlichen Warteschlange.

Den nächsten praxisnahen Überblick zu KI-Workflows im Newsletter erhalten.