Zweitausend Agenten schreiben sich selbst neu: Wie Prime Agent TypeScript nach Rust brachte

Eine Armee von zweitausend, und keiner davon ist ein Mensch

Prime Agent, der Coding-Agent, der erst im August 2026 offiziell erschienen ist, sammelte in zwei Monaten über 300.000 Downloads und verarbeitete mehr als 8 Billionen Token. Am 9. Oktober meldete sein Entwickler Prime Intellect etwas noch Auffälligeres: Das Werkzeug hat sich selbst neu geschrieben. Der Weg von TypeScript nach Rust war in zwei Wochen erledigt, und die Arbeit machten mehr als zweitausend autonome Agenten.

Das ist nicht der Werbespruch "KI schreibt dir den Code". Während der gesamten Portierung tat das menschliche Team im Wesentlichen eines: die Abnahmekriterien so aufsetzen, dass die Agenten selbst messen konnten, ob sie es richtig gemacht hatten. Der Rest, Orchestrierung, Programmieren, Review und Verifikation, ging an die Maschinen.

Kosten und Größe: 200 Milliarden Token auf einen Schlag bewegt

Laut dem offiziellen Blog koordinierte diese Neufassung mehr als 2.000 Agenten, die parallel über mehr als 10.000 Prime-Sandboxen arbeiteten, und verbrauchte über 200 Milliarden Token vom GLM-5.3-Endpunkt von Prime Inference. Die Phase, in der tatsächlich Rust geschrieben wurde, bewältigten 1.981 Agenten mit rund 192,99 Milliarden Token; die anschließende dreitägige Leistungssteigerung brachte weitere 228 Agenten und etwa 35,7 Milliarden Token ins Spiel.

Diese Zahlen sind selbst ein Signal. Dass das offene Modell GLM-5.3 zur Haupt-Inferenz-Engine eines produktionsreifen Agentenschwarms wird, ist nicht dasselbe wie "ein Modell hat im Benchmark wieder einen Punkt zugelegt". Es zeigt, dass in Engineering-Situationen, die lang laufen, große Mengen bewältigen und verlässliche Tool-Aufrufe brauchen, offene Gewichte inzwischen kosteneffizient genug für echte Projekte sind.

Orchestrierung: Der Wurzel-Agent schreibt keinen Produktcode

Am meisten lohnt es sich nicht, "es hat zweitausend Agenten benutzt" zu kopieren, sondern ihre Art der Arbeitsteilung. Die gesamte Neufassung wurde von einem einzigen Wurzel-Agenten gesteuert, der selbst keine einzige Zeile Produktcode schrieb. Er tat nur drei Dinge: Aufgaben in einen Graphen mit topologischer Ordnung zerlegen, den Fortschritt jeder Aufgabe verfolgen und erledigte Arbeit zusammenführen.

Jede Aufgabe durchläuft der Reihe nach vier Rollen:

• Planer: schreibt die Spezifikation, das Funktionsdesign und die "Musterlösung", die direkt dem bestehenden Verhalten der TypeScript-Version entnommen wird.
• Implementierer: schreibt Rust-Code in einem separaten worktree, damit verschiedene Funktionen parallel vorankommen können.
• Reviewer: wechselt Modell und Kontext und sucht adversarial nach Schwachstellen in dieser Änderung.
• Verifizierer: kompiliert den Code in einer frischen Sandbox und führt Konsistenztests aus.

Scheitert Review oder Verifikation, geht die Aufgabe samt Ergebnis an den Implementierer zurück. Erst wenn beides besteht, darf die Änderung zusammengeführt werden. Prime Intellect trennte "Generierung" und "Bewertung" bewusst, aus einem simplen Grund: Lässt man den Agenten, der den Code geschrieben hat, sein eigenes Ergebnis beurteilen, neigt er von Natur aus zu sich selbst.

Die eigentlichen Leitplanken: vier Arten von Konsistenzprüfungen

Ein Prozess allein reicht nicht, es braucht auch objektive Maßstäbe für richtig und falsch. Das Team baute vier Arten von Paritätsprüfungen, die verschiedene Seiten derselben Funktion abdecken:

• TUI-Differenztests: die beiden Binaries TypeScript und Rust unter demselben gescripteten Modell laufen lassen und den Terminal-Bildschirm Frame für Frame vergleichen, einschließlich Start, Menüs, Tool-Aufrufe, Wiederaufnahme von Sitzungen, Subagenten und Absturzwiederherstellung.
• Harness-Konsistenz: die von beiden Seiten erzeugten Sitzungsprotokolle vergleichen sowie die Anfragen, die jede an den Modellanbieter sendet.
• Protokoll-Konsistenz: jeden Nachrichtentyp des Daemon-Protokolls gegen die TypeScript-Implementierung prüfen.
• Funktionsaudit: wo Skripte nicht hinkommen, prüfen die Agenten Komponente für Komponente und markieren sie als "konsistent", "teilweise konsistent" oder "fehlend".

Mit diesen objektiven Maßstäben können Agenten ihren Fortschritt selbst beurteilen und Regressionen vor dem Merge stoppen, wodurch menschliche Reviews weniger nötig werden. Das Team ist auch ehrlich: Die Bugs, die durchrutschten, waren jene, die kein Test abdeckte, und sie kamen erst durch tägliche interne Nutzung zum Vorschein.

Ergebnisse: 14-facher Kaltstart, 80 Prozent weniger Speicher

In den offiziellen Vergleichsdaten sinkt die Verzögerung vom Kaltstart bis zur Eingabemöglichkeit von 737,8 Millisekunden in der TypeScript-Version auf 55,8 Millisekunden, eine 14,18-fache Beschleunigung; der Warmstart wird 13,34-mal schneller; der Speicherbedarf des gesamten Prozessbaums fällt von 607,4 MB auf 106 MB, rund 80 Prozent gespart; die Installationsgröße schrumpft von 172,1 MB auf 59,6 MB. Die erste sichtbare Ausgabe liegt bei 23,6 Millisekunden. In der Hochfahrphase wurden insgesamt 144 Experimente protokolliert und 69 gültige Änderungen zusammengeführt. Eine Einschränkung: Dieser direkte Vergleich nutzt die eigene Laufzeit-Suite des Teams, und das Team weist selbst auf das Fehlen eines einheitlichen Benchmarks hin, die Zahlen sind also mit Vorsicht zu lesen.

Die strukturelle Änderung könnte länger halten als die Geschwindigkeit. Der Code wurde in neun Crates aufgeteilt, mit einseitigen Abhängigkeiten, die Cargo erzwingt; die größte Quelldatei schrumpfte von etwa 15.000 Zeilen auf etwa 2.500, und keine Datei überschreitet mehr 5.000 Zeilen. Jede Sitzung läuft in ihrem eigenen Worker-Prozess, ein Absturz beeinflusst die übrigen nicht. Windows-Unterstützung kam als Nebeneffekt der saubereren Plattformabstraktion, und der Modellkatalog wird nun zur Laufzeit geladen, sodass neue Modelle nicht mehr von einem Release abhängen.

Warum Rust

Die vom Team genannten Schmerzpunkte von TypeScript sind konkret: Typen sind optional und verschwinden zur Laufzeit; Fehler breiten sich als ungeprüfte Ausnahmen aus; CPU-lastige Arbeit wie Rendering und das Parsen großer Sitzungen konkurriert mit der Tastatureingabe um dieselbe Ereignisschleife; jeder Prozess muss eine JavaScript-Laufzeit und Garbage Collection mitschleppen. Für einen Daemon, der dauerhaft läuft und pro Sitzung einen Worker-Prozess startet, ist nativer Code ohne GC die Hauptquelle für besseren Speicherbedarf und kürzere Startzeit.

Und wenn der Code überwiegend von Agenten geschrieben wird, steigt der Wert von "Garantien zur Kompilierzeit". Erschöpfende Enums, Ownership und Lebensdauern, dazu Clippys strikte Lints, können eine ganze Klasse von Bugs ausschließen, bevor der Code überhaupt läuft. Anders gesagt: Der Compiler übernimmt einen Teil des Urteils, das sonst einem menschlichen Reviewer zufiele.

Was das für verschiedene Menschen bedeutet

Wenn Sie ein Engineering-Team führen, ist das Wiederverwendbare nicht die Zahl "zweitausend Agenten", sondern die Methode: erst Abnahmekriterien in objektive, automatisch ausführbare Prüfungen verwandeln, dann Generierung und Bewertung auf verschiedene Modelle und Kontexte verteilen, und schließlich die Agenten innerhalb der Leitplanken selbst voranschreiten lassen. Primer Intellect produktisiert dieses Vier-Rollen-Muster bereits zu einem wiederverwendbaren Workflow, mit der Begründung, dass eine "wohldefinierte Schwarmfabrik" verlässlicher ist als ein für jedes Projekt ad hoc zusammengebautes Konstrukt.

Wenn Sie nur einfacher Nutzer sind, erklärt es eines: Die Update-Geschwindigkeit von Werkzeugen wie Prime Agent wird künftig immer weniger wie die klassischer Software wirken. Wenn ein Produkt sich selbst neu schreiben kann, ändert sich die Bedeutung einer Versionsnummer. Es erinnert auch daran, bei Schlüssen wie "Refactoring brachte 14-fache Beschleunigung" zuerst in die Fußnote zu schauen: Wer hat gemessen, und womit wurde verglichen. Agenten können brauchbaren Code schreiben, aber sie können ebenso selbstbewusstes Selbstlob schreiben.