„Projects lets you take on larger bodies of work, such as a feature, a migration, or a full app.“ Mit diesem Satz stellt Cursor sein neues Produkt vor. Dahinter steckt eine neue Ebene: Der Entwickler steuert nicht mehr einzelne Agenten, sondern ein ganzes Vorhaben. Cursor nennt das die dritte Ära der Softwareentwicklung – Agenten übernehmen komplette Arbeitspakete statt einzelner Funktionen. Ob das trägt, muss man prüfen.
Wer mit KI-Agenten arbeitet, kennt das Muster: Du formulierst einen Auftrag, der Agent arbeitet, du prüfst das Ergebnis, dann kommt der nächste Auftrag. Bei größeren Vorhaben wird das mühsam. Jede neue Sitzung muss den Zusammenhang neu lernen. Jedes Teammitglied erklärt dieselben Eigenheiten des Systems noch einmal. Cursor Projects setzt hier an und zieht die Steuerung eine Ebene nach oben. Statt Agenten zu verwalten, steuerst du die Arbeit selbst.
Ein Bild von der Baustelle hilft. Auf einer großen Baustelle steht ein Bauleiter, der selbst kaum Hand anlegt. Er kennt den Plan, verteilt die Gewerke, achtet auf die Reihenfolge und greift ein, wenn etwas hakt. Diese Rolle übernimmt in Cursor Projects ein Koordinator-Agent. An diesem Bild lässt sich fast alles erklären, was das Produkt ausmacht.
Ein Koordinator, der delegiert statt zu programmieren
Der Koordinator schreibt laut Anbieter keinen Code. Er verteilt die Arbeit an andere Agenten, die das übernehmen. Das ist der Kern des Entwurfs: Weil er nicht selbst ausführt, ist er nie blockiert und bleibt ansprechbar. Ein Agent, der gerade eine Testsuite repariert, kann keine neuen Anweisungen entgegennehmen. Ein Bauleiter mit der Kelle in der Grube übrigens auch nicht. Die Trennung von Steuerung und Ausführung ist keine Formalie, sondern die Voraussetzung dafür, dass ein Vorhaben mit vielen gleichzeitigen Aufgaben führbar bleibt. Du redest mit einer Stelle, und die sorgt dafür, dass an vielen Stellen gleichzeitig gearbeitet wird.
Für die Praxis ändert sich die Rolle. Du gibst nicht mehr jeden Handgriff vor, sondern beschreibst Ziel, Rahmen und Grenzen. Der Rest ist Delegation. Wer die Umstellung nicht mitgeht, erlebt ein System, das ihm zu viel abnimmt. Wer sie mitgeht, merkt, dass die eigentliche Arbeit im Formulieren von Kriterien liegt – daran, was gut genug ist und was nicht.
Cloud als Standard, lokal bei Bedarf
Damit das funktioniert, muss das Projekt unabhängig vom eigenen Rechner laufen. Cursor nennt es „Cloud by default, local when needed“: Ein Project läuft auf einem eigenen Computer, und das Zuklappen des Laptops beendet die Arbeit nicht. Darin unterscheiden sich solche Systeme von klassischen Assistenten. Wenn der Bauherr abends nach Hause fährt, steht die Baustelle nicht still. Erst dadurch lassen sich mehr Subagenten parallel beschäftigen, als ein Laptop verkraften würde.
Ganz ohne die lokale Maschine geht es trotzdem nicht. Wenn etwas zwingend dort getestet werden muss – etwa weil eine lokale Datenbank läuft oder eine Umgebung nur dort erreichbar ist – startet der Koordinator einen lokalen Agenten und lässt ihn die Prüfung vor Ort erledigen. Die Cloud ist der Regelfall, das Lokale die Ausnahme. Diese Aufteilung entscheidet darüber, ob parallele Arbeit praktikabel ist oder an der Hardware des Einzelnen scheitert.
Gemeinsamer Kontext als Gedächtnis des Projekts
Der zweite Baustein ist der gemeinsame Kontext. Jedes Project pflegt eine Sammlung von Dateien, die über alle Maschinen synchronisiert werden, egal ob in der Cloud oder lokal. Agenten schreiben dort Recherchen und Zwischenergebnisse hinein, aber auch, was sie über die Codebasis gelernt haben und wie gearbeitet werden soll. Findet ein Agent heraus, wie ein Dienst zu testen ist, profitieren alle künftigen Agenten davon. Das ist der Unterschied zwischen einer Baustelle mit Bautagebuch und einer, auf der jeden Morgen alle neu anfangen.
Das Gedächtnis sammelt nicht nur technisches Wissen, sondern auch Vorlieben: welche Architektur bevorzugt wird, wie ein Test aussehen soll, welche Konventionen gelten. Damit wird der Kontext zu einer Betriebsanleitung, die sich selbst schreibt. Der Koordinator wird mit der Zeit besser, weil er auf Erfahrungen zugreifen kann, die er nicht selbst gemacht hat. Für Teams ist das interessant, denn genau dieses Wissen geht heute bei jedem Personalwechsel und jedem neuen Chatfenster verloren.
Abonnements: Wenn das Projekt von selbst anfängt
Der dritte Baustein heißt Subscriptions. Der Koordinator kann einen Slack-Kanal beobachten, nach Zeitplan laufen oder alle Pull Requests im Blick behalten und bei Bedarf eingreifen – etwa wenn die CI fehlschlägt oder ein PR geöffnet oder gemergt wurde. Der Unterschied zur üblichen Arbeitsweise: Du musst nichts anstoßen. Das System reagiert auf Signale, die es selbst erkennt.
Das ist ein leiser, aber folgenreicher Wechsel. Bisher war ein KI-Agent ein Werkzeug, das auf einen Impuls wartet – so wie eine Bohrmaschine auf den Daumen am Schalter. Ein Abonnement dreht das um: Die Arbeit meldet sich, wenn sie da ist. Zusammen mit dem gemeinsamen Kontext entsteht daraus ein Vorgang, der über Wochen weiterläuft, ohne dass jemand ihn täglich neu startet.
Feature, Migration, Gardening: die drei Arbeitsmuster
Cursor beschreibt drei Muster, die laut eigener Aussage den Großteil der Nutzung abdecken. Das erste ist Feature-Arbeit. Ein größeres Vorhaben beginnt damit, dass Agenten das System untersuchen und ihre Erkenntnisse als geteilten Kontext festhalten. Der Koordinator erstellt daraus einen Plan und schickt Agenten los, die verschiedene Teile parallel umsetzen und testen. Mit jeder Rückmeldung lernt das Projekt Architektur und Vorlieben kennen. Soll das Feature ausprobiert werden, startet der Koordinator einen Agenten auf deinem Rechner. Nach dem Release kann dasselbe Projekt Logs überwachen und Bug-Reports bearbeiten, mit dem vollen Kontext der ursprünglichen Entscheidungen.
Das zweite Muster sind Migrationen – Arbeit, die leicht zu beginnen und schwer zu beenden ist. Cursor berichtet von Framework-Wechseln und dem Austausch von Styling-Systemen über hunderte Pull Requests hinweg. Der Ablauf: Du erarbeitest mit dem Koordinator ein sicheres Vorgehen, dann wendet er es schrittweise auf die Codebasis an. Am Anfang liest du jeden PR genau. Wenn die Korrekturen halten, prüfst du weniger, und der Koordinator arbeitet die Migration selbstständig weiter ab. Nicht ein großer Umstellungsschub, sondern viele kleine, überprüfbare Schritte.
Das dritte Muster nennt der Anbieter Gardening – Pflege, die nie endet, etwa Codequalität sichern oder Regressionen früh erkennen. Ein Ingenieur im Team von Cursor betreibt so ein Design-System-Projekt: Anfangs prüfte er jede Korrektur und besserte nach. Heute scannt der Koordinator jeden neuen PR, zieht Komponenten heraus, die ins Design-System gehören, und legt eine Lint-Regel an, sobald er denselben Fehler zweimal sieht. Das Projekt soll zwischen 20 und 100 Pull Requests pro Tag berühren. Der Ingenieur prüft nur noch, wo Aufmerksamkeit nötig ist.
Was das für den Alltag bedeutet
Cursor nennt Zahlen aus der eigenen Nutzung: Neue Nutzer mergen 30 Prozent mehr PRs, wer überwiegend mit Projects arbeitet, sogar sechsmal so viele. Solche Angaben kommen vom Anbieter selbst und sind vorsichtig zu lesen. Sie beschreiben einen Anspruch, nicht den Durchschnittsfall, und lassen offen, wie viel davon auf das Produkt und wie viel auf besonders motivierte Nutzer zurückgeht.
Wichtiger ist die strukturelle Verschiebung. Nicht die Geschwindigkeit einzelner Antworten entscheidet, sondern ob ein Zusammenhang über Wochen erhalten bleibt. Das verspricht der gemeinsame Kontext, und daran wird sich zeigen, ob das Konzept trägt. Denn Kontext, der falsch oder veraltet ist, richtet mehr Schaden an als gar keiner.
Projects ist ab sofort in einer Beta für alle Nutzer verfügbar. Du startest ein Projekt in der linken Navigation, beschreibst, was entstehen soll, und der Koordinator übernimmt von dort. Am besten funktioniert das für Arbeit, die eine einzelne Unterhaltung überlebt: ein Feature mit mehreren PRs, eine Migration, ein Job, der läuft, während du weg bist. Wer heute vor allem kurze Fragen an einen Agenten stellt, wird davon wenig merken. Wer aber regelmäßig dieselben Erklärungen wiederholt, dieselben Tests neu beschreibt und dieselben Migrationsschritte abarbeitet, für den verschiebt sich die Rolle. Knapp wird dann nicht das Schreiben von Code, sondern die Aufmerksamkeit, mit der man viele laufende Vorgänge verfolgen kann.
Quelle: cursor.com
