Wir haben damit experimentiert, Agenten über Wochen hinweg autonom auszuführen.

Unser Ziel ist es, zu verstehen, wie weit wir die Grenzen des agentenbasierten Programmierens bei Projekten verschieben können, deren Abschluss für menschliche Teams normalerweise Monate dauert.

In diesem Beitrag beschreiben wir, was wir daraus gelernt haben, Hunderte gleichzeitig laufender Agenten in einem einzigen Projekt einzusetzen, ihre Arbeit zu koordinieren und dabei zu beobachten, wie sie über eine Million Zeilen Code und Billionen von Token schreiben.

#Die Grenzen eines einzelnen Agenten

Heutige Agenten eignen sich gut für klar umrissene Aufgaben, sind bei komplexen Projekten jedoch langsam. Der naheliegende nächste Schritt ist, mehrere Agenten parallel auszuführen, aber herauszufinden, wie sie sich koordinieren lassen, ist schwierig.

Unser erster Impuls war, dass Planung im Voraus zu starr wäre. Der Weg durch ein großes Projekt ist nicht eindeutig, und die richtige Arbeitsteilung ist zu Beginn nicht offensichtlich. Wir begannen daher mit dynamischer Koordination, bei der Agenten auf Basis dessen, woran andere gerade arbeiten, entscheiden, was sie als Nächstes tun.

#Koordination lernen

Unser ursprünglicher Ansatz behandelte alle Agenten als gleichgestellt und ließ sie sich über eine gemeinsame Datei selbst koordinieren. Jeder Agent prüfte, woran die anderen arbeiteten, übernahm eine Aufgabe und aktualisierte seinen Status. Um zu verhindern, dass zwei Agenten dieselbe Aufgabe übernahmen, nutzten wir einen Sperrmechanismus.

Das scheiterte auf interessante Weise:

1. Agenten hielten Sperren zu lange oder vergaßen ganz, sie freizugeben. Selbst wenn das Sperren korrekt funktionierte, wurde es zum Engpass. Zwanzig Agenten wurden auf den effektiven Durchsatz von zwei oder drei ausgebremst, wobei die meiste Zeit mit Warten verbracht wurde.

2. Das System war anfällig: Agenten konnten ausfallen, während sie Sperren hielten, versuchen, Sperren anzufordern, die sie bereits hielten, oder die Koordinationsdatei aktualisieren, ohne die Sperre überhaupt anzufordern.

Wir versuchten, Sperren durch optimistische Nebenläufigkeitskontrolle zu ersetzen. Agenten konnten den Zustand frei lesen, aber Schreibvorgänge schlugen fehl, wenn sich der Zustand seit dem letzten Lesen verändert hatte. Das war einfacher und robuster, aber es gab weiterhin tieferliegende Probleme.

Ohne Hierarchie wurden Agenten risikoscheu. Sie mieden schwierige Aufgaben und nahmen stattdessen kleine, sichere Änderungen vor. Kein Agent übernahm Verantwortung für schwierige Probleme oder eine End-to-End-Implementierung. Das führte dazu, dass sich die Arbeit über lange Zeiträume im Kreis drehte, ohne voranzukommen.

#Planer und Worker

Unser nächster Ansatz war, die Rollen zu trennen. Statt einer flachen Struktur, in der jeder Agent alles erledigt, haben wir eine Pipeline mit klar abgegrenzten Zuständigkeiten geschaffen.

• Planer erkunden kontinuierlich die Codebasis und erstellen Aufgaben. Sie können Unterplaner für bestimmte Bereiche erzeugen, wodurch die Planung selbst parallel und rekursiv abläuft.

• Worker übernehmen Aufgaben und konzentrieren sich vollständig darauf, sie zu erledigen. Sie koordinieren sich nicht mit anderen Workern und behalten auch nicht das große Ganze im Blick. Sie arbeiten einfach an ihrer zugewiesenen Aufgabe, bis sie fertig ist, und pushen dann ihre Änderungen.

Am Ende jedes Zyklus entschied ein Judge-Agent, ob es weitergehen sollte, und die nächste Iteration begann wieder von vorn. Das löste die meisten unserer Koordinationsprobleme und ermöglichte es uns, auf sehr große Projekte zu skalieren, ohne dass ein einzelner Agent den Gesamtüberblick verlor.

#Wochenlang im Einsatz

Um dieses System zu testen, haben wir ihm ein ambitioniertes Ziel gesetzt: einen Webbrowser von Grund auf neu zu erstellen. Die Agenten liefen fast eine Woche lang und schrieben über 1 Million Zeilen Code in 1.000 Dateien. Du kannst den Quellcode auf GitHub ansehen.

Trotz der Größe der Codebasis können neue Agenten sie weiterhin verstehen und sinnvolle Fortschritte machen. Hunderte von Workern laufen parallel und pushen mit minimalen Konflikten in denselben Branch.

Auch wenn es wie ein einfacher Screenshot wirken mag, ist es extrem schwierig, einen Browser von Grund auf neu zu erstellen.

Ein weiteres Experiment war eine direkte Migration von Solid zu React in der Cursor-Codebasis. Sie dauerte über drei Wochen und umfasste +266K/-193K Änderungen. Sie braucht noch eine sorgfältige Review, bestand aber bereits unsere CI und erste Checks.

Ein weiteres Experiment war die Verbesserung eines bevorstehenden Produkts. Ein langlaufender Agent machte das Video-Rendering mit einer effizienten Rust-Version 25-mal schneller. Außerdem fügte er Support für flüssiges Zoomen und Schwenken mit natürlicher Federdynamik und Bewegungsunschärfe hinzu, die dem Mauszeiger folgen. Dieser Code wurde gemergt und wird bald in Produktion sein.

Wir haben noch ein paar weitere interessante Beispiele, die noch laufen:

• Java LSP: 7.4K Commits, 550K LoC
• Windows 7 emulator: 14.6K Commits, 1.2M LoC
• Excel: 12K Commits, 1.6M LoC

#Was wir gelernt haben

Wir haben Billionen von Token über diese Agenten hinweg für ein einziges Ziel eingesetzt. Das System ist nicht perfekt effizient, aber deutlich effektiver, als wir erwartet hatten.

Die Wahl des Modells ist bei extrem lang laufenden Aufgaben entscheidend. Wir haben festgestellt, dass GPT-5.2-Modelle für längere autonome Arbeit deutlich besser geeignet sind: Sie befolgen Anweisungen, bleiben fokussiert, vermeiden Abweichungen und setzen Dinge präzise und vollständig um.

Opus 4.5 neigt dazu, früher aufzuhören und Abkürzungen zu nehmen, wenn es sich anbietet, und gibt die Kontrolle dadurch schnell zurück. Wir haben außerdem festgestellt, dass verschiedene Modelle sich für unterschiedliche Rollen eignen. GPT-5.2 ist ein besserer Planer als GPT-5.1-Codex, obwohl Letzteres speziell fürs Coding trainiert wurde. Wir nutzen jetzt für jede Rolle das am besten geeignete Modell statt eines universellen Modells.

Viele unserer Verbesserungen entstanden dadurch, dass wir Komplexität entfernt haben, statt sie hinzuzufügen. Anfangs haben wir eine Integrator-Rolle für Qualitätskontrolle und Konfliktlösung entwickelt, stellten aber fest, dass sie mehr Engpässe erzeugte, als sie auflöste. Worker konnten Konflikte bereits selbst handhaben.

Das beste System ist oft einfacher, als du erwarten würdest. Anfangs haben wir versucht, Systeme aus dem verteilten Rechnen und dem Organisationsdesign abzubilden. Allerdings funktionieren nicht alle davon für Agenten.

Das richtige Maß an Struktur liegt irgendwo in der Mitte. Bei zu wenig Struktur geraten Agenten in Konflikt, erledigen dieselbe Arbeit mehrfach und driften ab. Zu viel Struktur schafft Fragilität.

Ein überraschend großer Teil des Systemverhaltens hängt davon ab, wie wir die Agenten prompten. Damit sie gut kooperieren, pathologisches Verhalten vermeiden und über lange Zeiträume fokussiert bleiben, waren umfangreiche Experimente nötig. Das Harness und die Modelle sind wichtig, aber die Prompts sind wichtiger.

#Was kommt als Nächstes

Die Koordination mehrerer Agenten bleibt ein schwieriges Problem. Unser aktuelles System funktioniert, aber von optimal sind wir noch weit entfernt. Planer sollten aktiv werden, sobald ihre Aufgaben abgeschlossen sind, um den nächsten Schritt zu planen. Agenten laufen gelegentlich viel zu lange. Außerdem brauchen wir weiterhin regelmäßige Neustarts, um Drift und Tunnelblick entgegenzuwirken.

Aber die Kernfrage – ob wir autonomes Programmieren skalieren können, indem wir mehr Agenten auf ein Problem ansetzen – hat eine optimistischere Antwort, als wir erwartet hatten. Hunderte von Agenten können über Wochen hinweg gemeinsam an einer einzigen Codebasis arbeiten und dabei bei ambitionierten Projekten echte Fortschritte erzielen.

Die Techniken, die wir hier entwickeln, werden letztlich die Agent-Funktionen von Cursor prägen. Wenn du daran interessiert bist, an den schwierigsten Problemen der KI-gestützten Softwareentwicklung zu arbeiten, freuen wir uns, von dir zu hören: hiring@cursor.com.