Wir haben damit experimentiert, Coding-Agents über Wochen hinweg autonom laufen zu lassen.

Unser Ziel ist herauszufinden, wie weit wir die Grenzen Agent-basierten Codens für Projekte verschieben können, für die menschliche Teams normalerweise Monate brauchen.

Dieser Beitrag beschreibt, was wir dabei gelernt haben: Hunderte gleichzeitig laufende Agents auf ein einziges Projekt anzusetzen, ihre Arbeit zu koordinieren und dabei zuzusehen, wie sie über eine Million Zeilen Code und Billionen von Token schreiben.

#Die Grenzen eines einzelnen Agents

Heutige Agents funktionieren gut für klar umrissene Aufgaben, sind aber langsam bei komplexen Projekten. Der naheliegende nächste Schritt ist, mehrere Agents parallel auszuführen, aber herauszufinden, wie man sie koordiniert, ist eine Herausforderung.

Unser erster Instinkt war, dass Planung im Voraus zu starr wäre. Der Weg durch ein großes Projekt ist nicht eindeutig, und die richtige Aufteilung der Arbeit ist anfangs nicht klar. Wir haben mit dynamischer Koordination begonnen, bei der Agents auf Basis dessen entscheiden, was andere gerade tun.

#Koordination lernen

Unser erster Ansatz behandelte alle Agents gleichberechtigt und ließ sie sich über eine gemeinsame Datei selbst koordinieren. Jeder Agent prüfte, was die anderen taten, übernahm eine Aufgabe und aktualisierte seinen Status. Um zu verhindern, dass zwei Agents dieselbe Aufgabe übernahmen, verwendeten wir einen Sperrmechanismus.

Das scheiterte auf interessante Weise:

1. Agents hielten Sperren zu lange oder vergaßen, sie überhaupt freizugeben. Selbst wenn das Sperren korrekt funktionierte, wurde es zum Engpass. Zwanzig Agents kamen effektiv nur noch auf den Durchsatz von zwei oder drei, wobei die meiste Zeit mit Warten verbracht wurde.

2. Das System war anfällig: Agents konnten ausfallen, während sie Sperren hielten, versuchten, Sperren zu erwerben, die sie bereits hielten, oder aktualisierten die Koordinationsdatei, ohne die Sperre überhaupt zu erwerben.

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

Ohne Hierarchie wurden Agents risikoscheu. Sie mieden schwierige Aufgaben und nahmen stattdessen kleine, sichere Änderungen vor. Kein Agent übernahm Verantwortung für schwierige Probleme oder End-to-End-Implementierungen. Dadurch wurde über lange Zeit gearbeitet, ohne dass es echte Fortschritte gab.

#Planer und Worker

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

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

• Worker greifen Aufgaben auf und konzentrieren sich vollständig auf deren Abschluss. Sie koordinieren sich nicht mit anderen Workern und kümmern sich nicht um das große Ganze. Sie arbeiten einfach an ihrer zugewiesenen Aufgabe, bis sie erledigt ist, und pushen dann ihre Änderungen.

Am Ende jedes Zyklus bestimmte ein prüfender Agent, ob es weitergehen sollte, danach startete die nächste Iteration neu. Das löste die meisten unserer Koordinationsprobleme und ermöglichte es uns, auf sehr große Projekte zu skalieren, ohne dass ein einzelner Agent Tunnelblick bekam.

#Wochenlang laufende Agents

Um dieses System zu testen, haben wir ihm ein ambitioniertes Ziel gesetzt: einen Webbrowser von Grund auf neu zu bauen. Die Agents liefen fast eine Woche lang und schrieben über 1 Million Zeilen Code in 1.000 Dateien. Sie können den Quellcode auf GitHub erkunden.

Trotz der Größe der Codebasis können neue Agents sie weiterhin verstehen und sinnvolle Fortschritte machen. Hunderte Worker laufen gleichzeitig und pushen mit minimalen Konflikten in denselben Branch.

Auch wenn es wie ein einfacher Screenshot aussieht, ist es extrem schwierig, einen Browser von Grund auf neu zu bauen.

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

Ein weiteres Experiment diente der Verbesserung eines kommenden Produkts. Ein langlaufender Agent machte das Rendern von Videos mit einer effizienten Rust-Implementierung 25-mal schneller. Außerdem wurde Unterstützung für flüssiges Zoomen und Schwenken mit natürlichen Feder-Übergängen und Bewegungsunschärfen ergänzt, die dem Mauszeiger folgen. Dieser Code wurde gemergt und wird bald in Produktion gehen.

Wir haben noch einige weitere interessante Beispiele, die weiterhin 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 Tokens in diesen Agents auf ein einziges Ziel hingearbeitet. Das System ist nicht perfekt effizient, aber deutlich wirkungsvoller, als wir erwartet hatten.

Die Modellauswahl ist entscheidend für extrem lang laufende Aufgaben. Wir haben festgestellt, dass GPT-5.2-Modelle bei ausgedehnter autonomer Arbeit deutlich besser sind: Anweisungen zu befolgen, fokussiert zu bleiben, Abschweifungen zu vermeiden und Dinge präzise und vollständig umzusetzen.

Opus 4.5 neigt dazu, früher zu stoppen und, wenn es sich anbietet, Abkürzungen zu nehmen, sodass die Kontrolle schnell zurückgegeben wird. Wir haben außerdem festgestellt, dass unterschiedliche Modelle in unterschiedlichen Rollen besonders gut abschneiden. GPT-5.2 ist ein besserer Planer als GPT-5.1-Codex, obwohl Letzteres speziell fürs Programmieren trainiert ist. Wir verwenden jetzt das jeweils am besten geeignete Modell pro Rolle, anstatt ein universelles Modell einzusetzen.

Viele unserer Verbesserungen kamen zustande, indem wir Komplexität entfernt statt hinzugefügt haben. Anfangs haben wir eine Integrator-Rolle für Qualitätssicherung und Konfliktlösung gebaut, aber festgestellt, dass sie mehr Engpässe erzeugte, als sie löste. Die Worker waren bereits in der Lage, Konflikte selbst zu handhaben.

Das beste System ist oft einfacher, als man denkt. Zunächst haben wir versucht, Systeme aus der verteilten Datenverarbeitung und dem Organisationsdesign zu übertragen. Allerdings funktionieren nicht alle davon für Agents.

Das richtige Maß an Struktur liegt irgendwo in der Mitte. Zu wenig Struktur führt dazu, dass Agents in Konflikt geraten, Arbeit doppelt machen und abschweifen. Zu viel Struktur erzeugt Fragilität.

Ein überraschend großer Teil des Systemverhaltens hängt davon ab, wie wir die Agents mit Prompts steuern. Sie dazu zu bringen, gut zu koordinieren, pathologische Verhaltensweisen zu vermeiden und über lange Zeiträume fokussiert zu bleiben, erforderte umfangreiche Experimente. Harness und Modelle sind wichtig, aber die Prompts sind noch wichtiger.

#Wie geht es weiter

Die Koordination mehrerer Agents bleibt ein schwieriges Problem. Unser aktuelles System funktioniert, aber wir sind noch lange nicht optimal. Planner sollten aufwachen, sobald ihre Tasks abgeschlossen sind, um den nächsten Schritt zu planen. Agents laufen gelegentlich viel zu lange weiter. Wir brauchen weiterhin regelmäßige Neustarts, um Drift und Tunnelblick entgegenzuwirken.

Aber die Kernfrage, ob wir autonomes Programmieren skalieren können, indem wir mehr Agents auf ein Problem ansetzen, hat eine optimistischere Antwort als erwartet. Hunderte von Agents können wochenlang gemeinsam an einer einzigen Codebasis arbeiten und dabei spürbare Fortschritte bei ambitionierten Projekten machen.

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