Die Skalierung langlaufenden autonomen Codings

 (cursor.com)
18 Punkte von GN⁺ 2026-01-16 | 1 Kommentare | Auf WhatsApp teilen
  • Cursor hat experimentiert, ob es autonome Coding-Agenten über mehrere Wochen parallel ausführen und damit große Projekte fertigstellen kann
  • Anfangs wurde eine dynamische Kollaborationsstruktur verwendet, doch Lock-Konflikte und doppelte Arbeit führten zu Engpässen
  • Anschließend wurden die Rollen in Planner und Worker aufgeteilt, was Parallelität und Effizienz deutlich verbesserte
  • Mit dieser Struktur wurde ein Webbrowser von Grund auf implementiert, wobei Hunderte von Agenten über 1 Million Zeilen Code schrieben
  • Die Experimente zeigen, dass eine einfache Struktur und geeignetes Prompt-Design der Schlüssel zur Skalierung langfristigen autonomen Codings sind

Grenzen eines einzelnen Agenten

  • Der heutige einzelne Coding-Agent ist bei einfachen Aufgaben effizient, wird bei komplexen Projekten jedoch langsam
    • Mehrere Agenten parallel laufen zu lassen ist die naheliegende Skalierungsrichtung, aber die Koordination der Arbeit ist schwierig
  • Anfangs wurde ohne Vorabplanung eine dynamische Kollaborationsmethode ausprobiert
    • Eine Struktur, in der jeder Agent den Status anderer Agenten sieht und selbst entscheidet, welche Aufgabe als Nächstes bearbeitet wird

Lernprozess der Zusammenarbeit

  • Es wurde eine Struktur eingeführt, in der alle Agenten die gleichen Rechte haben und ihre Arbeit über gemeinsame Dateien koordinieren
    • Jeder Agent prüft den Status der anderen Agenten, bekommt Aufgaben zugewiesen und aktualisiert seinen Status
    • Zur Vermeidung von Duplikaten wurde ein Lock-Mechanismus verwendet
  • Probleme
    1. Agenten hielten Locks zu lange oder gaben sie nicht frei, wodurch die Gesamtgeschwindigkeit von 20 Agenten effektiv auf das Niveau von 2 bis 3 sank
    2. Es kam zu Systeminstabilität, etwa wenn ein Agent mit gehaltenem Lock scheiterte oder Dateien ohne Lock änderte
  • Umstellung auf optimistic concurrency control
    • Lesen war frei möglich, Schreiben wurde so konfiguriert, dass es bei Zustandsänderungen fehlschlägt
    • Das war einfach und stabil, doch in einer hierarchielosen Struktur zeigten die Agenten risikoaverses Verhalten
    • Sie mieden schwierige Probleme, wiederholten nur kleine Änderungen und gerieten in Arbeitszyklen ohne Fortschritt

Struktur aus Plannern und Workern

  • Wechsel zu einer hierarchischen Pipeline mit getrennten Rollen
    • Planner: Erkunden die Codebasis, erzeugen Aufgaben und erstellen bei Bedarf untergeordnete Planner
    • Worker: Führen nur die zugewiesenen Aufgaben aus und pushen danach ihre Änderungen
  • In jedem Zyklus entscheidet ein Judge-Agent, ob zum nächsten Schritt übergegangen wird
    • Mit dieser Struktur wurden die meisten Kollaborationsprobleme gelöst und die Skalierbarkeit großer Projekte gesichert

Langlaufende Experimente

  • Ziel des Experiments: einen Webbrowser von Grund auf implementieren
    • Laufzeit von etwa einer Woche, in 1.000 Dateien wurden über 1 Million Zeilen Code geschrieben
    • Hunderte Worker pushten gleichzeitig auf denselben Branch, Konflikte blieben jedoch minimal
    • Der resultierende Code wurde auf GitHub veröffentlicht
  • Weitere Experimente
    • Solid → React-Migration: Über 3 Wochen +266K/-193K Änderungen, Machbarkeit des Mergings bestätigt
    • Verbesserung des Video-Renderings: Mit einer Rust-Version 25-fache Beschleunigung sowie Funktionen für Zoom, Pan und Motion Blur hinzugefügt
    • Dieser Code soll bald in die Produktion übernommen werden

Zentrale Erkenntnisse

  • Nach dem Einsatz von Milliarden Tokens zeigte sich: nicht vollständig effizient, aber leistungsfähiger als erwartet
  • Die Modellauswahl ist entscheidend für langfristige autonome Arbeit
    • GPT-5.2 war stark bei Fokus, Befolgung von Anweisungen und präziser Implementierung
    • Opus 4.5 neigte dazu, Aufgaben früh zu beenden
    • GPT-5.2 eignet sich besser für die Planner-Rolle als GPT-5.1-codex
    • Je nach Rolle wurden die jeweils optimalen Modelle ausgewählt
  • Das Entfernen von Komplexität trug zur Leistungssteigerung bei
    • Die Rolle eines Qualitäts-Integrators erzeugte im Gegenteil einen Engpass
    • Worker konnten Konflikte selbstständig lösen
  • Eine einfache Struktur war am wirksamsten
    • Theorien zu verteilten Systemen oder Modelle des Organisationsdesigns waren nur teilweise nützlich
    • Zu wenig Struktur erzeugt Konflikte und Duplikate, zu viel erhöht die Anfälligkeit
  • Prompt-Design beeinflusst das Systemverhalten entscheidend
    • Es spielt eine Schlüsselrolle für langfristigen Fokus, die Vermeidung pathologischen Verhaltens und die Förderung von Zusammenarbeit

Kommende Aufgaben

  • Koordination mehrerer Agenten bleibt weiterhin ein schwieriges Problem
    • Planner sollten nach Abschluss einer Aufgabe automatisch die nächsten Schritte planen können
    • Einige Agenten liefen übermäßig lange und benötigen daher periodische Neustarts
  • Bei der Kernfrage, ob sich autonomes Coding durch mehr Agenten skalieren lässt, wurde jedoch gezeigt, dass
    • Hunderte von Agenten über mehrere Wochen zusammenarbeiten und reale Fortschritte erzielen können
  • Diese Technik soll künftig in Cursors Agentenfunktionen einfließen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-16
Hacker-News-Kommentare

  • Ich fand das interessant, weil ich an etwas arbeite, das mit Steve Yegges Artikel Welcome to Gas Town zu tun hat

  • In meinem kürzlich veröffentlichten LLM-Prognosebeitrag schrieb ich, dass es um 2029 nicht mehr überraschend sein wird, wenn ein Browser mit AI-unterstütztem Coding gebaut wird. Dieses Projekt von Cursor ist nun der zweite Versuch
    Ein weiteres Beispiel findet sich in diesem Reddit-Post

    • Bei einer klugen Umsetzung würde man vermutlich einfach den Chromium-Quellcode von GitHub nehmen, unnötige Funktionen entfernen und nur das Erscheinungsbild ändern
    • Um 2029 sollte die Messlatte so hoch liegen, dass Witze darüber gemacht werden, dass AI einen Browser für Pelikane baut
    • Ich habe mir den Beispielcode auf Reddit etwa fünf Minuten angesehen, und die Berechnung des Textlayouts und bidi (bidirektionaler Text) war katastrophal. Einen „Browser“, der Standards nicht berücksichtigt, kann man kaum einen echten Browser nennen
    • Eindrucksvoll ist es schon, aber ich frage mich, ob Open-Source-Browser-Code nicht in den Trainingsdaten des Modells enthalten war
    • Er sagte doch, seine Prognose sei danebengelegen — warum war er dann eine Woche später wieder im selben Podcast und hat eine neue Prognose abgegeben?

  • Ich habe die Tests des Repositories selbst ausgeführt, und sie waren voller Fehler und Warnungen; auch die CI schlägt schon seit Langem fehl. Ich weiß nicht, ob man das unter diesen Umständen ein „erfolgreiches Beispiel“ nennen kann. Statt vollständig autonomem Coding halte ich einen menschenzentrierten, assistiven Ansatz für realistischer

    • Die Codebasis war in Hunderte oder Tausende kleiner Dateien zersplittert, sodass die Struktur praktisch nicht zu erfassen war. Das README war schlampig, und es gab keine Erklärung der Abhängigkeiten. Von AI erzeugter Code, aber wartungstechnisch ein Albtraum
    • Auch der Autor scheint vollständig autonomes Coding eher als Experiment zu den Grenzen von LLMs zu sehen als als ernsthafte Produktisierung. Derzeit ist man offenbar erst an dem Punkt, an dem bei kleinen Projekten „allein noch halbwegs brauchbarer Code“ herauskommt
    • Dass ein PR trotz fehlschlagender CI einfach gemergt wurde, lädt geradezu zu dem Witz ein, damit sei nun menschliches Qualitätsniveau erreicht
    • Was mit „langsam“ konkret gemeint ist, bleibt unklar. GPU-Geschwindigkeit? Langsamer als ein Mensch? Am Ende wirkte es auf mich wie ein Beitrag, der die AI-Blase weiter aufpumpt

  • Ich frage mich, warum dieser PR noch nicht gemergt wurde. Die Zukunft, in der Schwärme von AI-Agenten langfristig komplexe Software fertigstellen, ist faszinierend, aber das aktuelle Beispiel ist viel zu dünn. Wichtiger ist, wo die Zusammenarbeit mit Menschen ansetzt

    • Meiner Erfahrung nach konvergieren Agenten nicht, sondern erzeugen immer chaotischere Code-Monster
    • Dass nicht einmal ein einziges funktionierendes kleines Projekt veröffentlicht wurde, wirkt wie ein Köder zur Investorengewinnung. Der AI-Boom ähnelt der Dotcom-Blase, aber diesmal scheint er noch stärker auf Geldverdienen ausgerichtet zu sein
    • Beispiele wie Browser, Excel oder Windows 7 waren wohl teilweise in den Trainingsdaten enthalten, aber eine vollständige Kopie lässt sich daraus trotzdem nicht erzeugen
    • Der Code ist so umfangreich und voller Probleme, dass ein Review praktisch unmöglich ist. Am Ende bleibt nur ein YOLO-Merge
    • Mich interessieren die Konvergenzbedingungen. Ob der Code wächst oder schrumpft, wichtig ist, dass er sich in einem optimalen Zustand stabilisiert

  • Schade, dass nicht experimentell Schritt für Schritt der Schwierigkeitsgrad erhöht wurde. Wenn man React CRUD → Paint-Klon → Dateimanager → Browser schrittweise skaliert hätte, hätte man die Entwicklungsstufen klarer sehen können

  • Ich habe auf ähnliche Weise auch tjs gebaut. Es ist der schnellste und präziseste JSON Schema Validator der Welt, und ein Planner/Delegate-Muster mit git subtree war dabei effektiv. Software mit klar definierten Standards und Tests kann von AI-Agenten schnell neu geschrieben und optimiert werden
    Die zugehörigen Befehle finden sich in spawn-perf-agents.md

  • Einen Browser von Grund auf zu bauen ist extrem schwierig, aber dem Beitrag fehlte es an detaillierter Analyse. Wenn es nur darum geht, dass etwas „kompiliert“, ist die Aussagekraft gering. Der eigentliche Test ist, ob sich die nächste Änderung stabil mergen lässt

    • Die Mindestanforderung an Agenten-Coding lautet: „kompiliert erfolgreich“ → „läuft korrekt“ → „behandelt Edge Cases“. Erst wenn ein System über mehr als ein Jahr stabil läuft und weniger Bugs als Menschen produziert, ist es vertrauenswürdig
    • Tatsächlich schlägt sogar die CI fehl, daher ist selbst die Behauptung „es kompiliert“ fraglich

  • Laut dem Blog wurden Billionen von Tokens verbraucht; zum Preis der OpenAI-API gerechnet wären das zig Millionen Dollar. Bei dieser Größenordnung wäre es vielleicht besser gewesen, einfach an ein Browser-Team zu spenden

  • Ich habe es selbst gebaut, und es gab mehr als 100 Compilerfehler. Bei den meisten Commits war die CI im Fehlerzustand, und in Wirklichkeit war das Ganze eine Kombination aus mehreren Open-Source-Bibliotheken.
    quickjs, wgpu, winit, egui, html parser und andere bestehende Komponenten wurden praktisch unverändert übernommen, doch der CEO bezeichnete es als „custom JS VM“, was zu Missverständnissen führt
    Trotzdem ist es beeindruckend, dass AI diese Integration autonom hinbekommen hat

    • Die verwendeten Komponenten ähneln dem Rust-basierten Browser blitz stark, daher ist es möglich, dass er in den Trainingsdaten enthalten war
    • Es gab auch einen Startup-Witz nach dem Muster: „Ob es funktioniert, ist egal — mach einen Screenshot und zeig ihn den Investoren“
    • Es gibt eine Statistik, wonach von über 60.000 Workflows nur gut 1.000 erfolgreich waren. Das wirkt faktisch wie ein unverifizierter Haufen Code
    • Zum Schluss wurde mit dem Witz geendet: „Lasst uns alle unser eigenes custom Cursor bauen“

  • Der Code wirkte sehr fragil und instabil. Zum Beispiel sieht die render_placeholder-Funktion einfach nach provisorischem Code aus, der nur den Framebuffer füllt.
    Ich frage mich, welche Rolle solcher Code tatsächlich spielt und wie hoch die Token-/Zeitkosten pro Test sind

    • Auch die Art, wie Tag-Attribute extrahiert werden, wirkte an dieser Stelle etwas seltsam
    • Wenn Cursor das aber automatisch reparieren kann, könnte diese Fragilität langfristig auch eine Strategie sein, um die Abhängigkeit davon zu erhöhen