Copilot Cowork: Microsoft meldet 1.211 Pull Requests an einem Tag

Am 21. Oktober übernahmen neun Microsoft-Ingenieure nach Unternehmensangaben 1.211 Pull Requests in den Hauptzweig des Copilot-Cowork-Backends. Microsoft führt das hohe Tempo auf klar umrissene Aufgaben für parallel arbeitende Agenten und menschliche Kontrollpunkte zurück. Die Zahl zählt zusammengeführte Änderungen, sie bewertet nicht deren Qualität. Microsofts technischer Bericht beschreibt auch, wie das Team den laufenden Dienst von Python auf Rust umstellte.

Was hinter den 1.211 Pull Requests steckt

Der Tageswert steht neben einer anderen, separat gemeldeten Zahl: In der Woche ab dem 12. Oktober wurden laut Microsoft 4.581 Pull Requests in den Hauptzweig übernommen, im Schnitt rund 650 pro Tag. Für den 21. Oktober nannte das Unternehmen 1.211 Änderungen, die neun Ingenieure in den Backend-Hauptzweig einbrachten.

Microsoft zufolge schrieben Agenten den größten Teil des Codes. Die Ingenieure legten fest, was gebaut werden sollte, bestimmten Architektur und Sicherheitsgrenzen und behielten die Entscheidung darüber, was in Produktion gelangte. Für das Team war daher entscheidend, Aufgaben so präzise zu formulieren, dass Agenten parallel daran arbeiten konnten und sich Änderungen anschließend prüfen ließen.

Wie Microsoft die Agentenarbeit begrenzte

Vor dem Programmieren sollte eine Markdown-Spezifikation stehen: Sie beschrieb das gewünschte Verhalten, woran der Erfolg zu erkennen wäre und was unverändert bleiben musste. Ein Agent konnte aus einer mündlichen Beschreibung einen Entwurf erstellen; ein Mensch überarbeitete ihn vor dem Start der Implementierung.

Die Agenten arbeiteten jeweils in einer eigenen Kopie des Repositorys und an einer einzelnen, an eine Spezifikation gebundenen Aufgabe. Das Team beschreibt den Ausbau von einem Agenten auf fünf und schließlich Dutzende. Für den Parallelbetrieb hielt Microsoft zugleich menschliche Entscheidungen bei Architektur, Sicherheit und kritischen Änderungen fest.

Für Copilot Cowork beschreibt Microsoft außerdem eine Grenze zwischen Agent und Diensten: Das Modell läuft in einem Container ohne Nutzer-Anmeldedaten. Ein vertrauenswürdiger Host außerhalb des Containers übernimmt Identität, Richtlinien, Freigaben und Werkzeugaufrufe. Jede Microsoft-365-Operation läuft laut Unternehmen über diesen Host. Damit kann das Modell Aktionen planen und anfragen, während der Host über ihre Ausführung entscheidet.

Agenten prüften Änderungen früh im Prozess, doch für kritische Eingriffe blieb eine menschliche Prüfung vorgesehen. Microsoft berichtet von einem sensiblen Fall, in dem die Prüfer-Agenten vier schwerwiegende Fehler übersahen, die anschließend Menschen vor dem Zusammenführen fanden. Das Team verlangte außerdem, dass jede Prüfung angibt, wie viele Dateien sie untersucht hat. Neue Prüfungen mussten einen Test enthalten, der absichtlich fehlschlägt. So sollte ein grüner Status nicht bloß bedeuten, dass ein Check nichts geprüft hatte.

Wie der Python-Rust-Port auf Verhalten geprüft wurde

Für den Wechsel ließ Microsoft Generatoren den echten Python-Code mit festgelegten Eingaben ausführen und die Ergebnisse als JSON-Dateien speichern. Solche Fixtures hielten etwa Antwortinhalte, Statuscodes, Protokollzeilen und Schreibvorgänge fest. Rust-Tests spielten die Fälle erneut ab und prüften, ob die Ergebnisse übereinstimmten. Microsoft berichtet von rund 430 Fixtures. Ein Beispieltest prüfte zunächst die erwartete Zahl von 48 Fällen, damit ein leerer Testlauf nicht fälschlich als bestanden galt.

Die erste Fixture-Sammlung erfasste allerdings nicht jedes Verhalten: Python hatte bestimmte Ereignisse in einer festen Reihenfolge geliefert, obwohl diese Reihenfolge nie ausdrücklich spezifiziert worden war. Der erste Rust-Port bewahrte sie nicht, und kein Fixture deckte das auf. Das Team ergänzte die Prüfung und berichtet, den Fehler behoben zu haben.

Microsoft verlegte den laufenden Dienst schrittweise. Der erste interne Umschaltversuch am 23. September wurde zurückgenommen; am 24. September lieferte Rust erstmals produktive Verarbeitung. Am 9. Oktober löschte das Team die Python-Laufzeit, laut Bericht etwa 8.000 Dateien mit insgesamt 4,9 Millionen Zeilen einschließlich Tests und generiertem Code. Am 10. Oktober wechselte der letzte Cluster zu Rust.

Was der Latenzvergleich misst

Für die erste Antwort eines neuen Durchlaufs verglich Microsoft einen Python- und einen Rust-Cluster über dasselbe Zeitfenster von zwölf Stunden Ende September. p50 bezeichnet den Median, p90 den Wert, unter dem 90 Prozent der Messungen lagen.

Microsoft sagt, dass auch der Umzug der Agentenschleife aus dem langsam startenden Container in den Rust-Dienst wesentlich zum niedrigeren Wert beitrug. Der Vergleich isoliert daher nicht den Effekt der Programmiersprache.

Das Unternehmen nennt als frühere interne Probleme Python-Ereignisschleifen, die sich unter Last um bis zu 11,9 Sekunden verzögerten, sowie Sitzungsstarts, bei denen in 16,7 Prozent der Fälle genau nach fünf Sekunden ein Timeout auslöste. Auf einem einzelnen Cluster seien innerhalb einer Woche zudem 539 Python-Prozesse beendet worden. Microsoft berichtet, dass die Verzögerungen und Timeout-Fälle nach dem Wechsel nicht mehr auftraten. Kosten pro Durchlauf hat das Unternehmen nach eigener Aussage noch nicht angemessen gemessen und macht deshalb keine Aussage zu möglichen Kosteneinsparungen.