Microsoft: Neun Entwickler mergen an einem Tag 1.211 Pull Requests in Copilot Cowork

Vom leeren Repository zur allgemeinen Verfügbarkeit

Copilot Cowork beschreibt Microsoft als agentische Ausführungsschicht, die mehrstufige Workflows im Auftrag der Nutzer erledigt. Ziel ist es, die KI-gestützten Werkzeuge, die Entwickler bereits nutzen, auch normalen Wissensarbeitern zugänglich zu machen, und zwar mit Work IQ, der Sicherheit und Governance von Microsoft 365, Cloud-Ausführung und Microsofts Multimodell-Architektur.

Bas Brekelmans, Partner Software Engineer bei Microsoft, schreibt, der erste Commit sei am 13. Januar erfolgt. Am 30. März erreichte Copilot Cowork im Frontier-Programm die ersten Unternehmenskunden, am 16. Juni folgte die weltweite allgemeine Verfügbarkeit, mit mehreren Modellen und 16 Plug-ins. Später stellte das Team die Laufzeitumgebung bei laufendem Betrieb von Python auf Rust um.

Laut Microsoft stieg die Zahl der gemergten Pull Requests pro Monat von 257 im Januar auf 2.754 im Mai, die stärkste Woche vor der allgemeinen Verfügbarkeit kam auf 783. Die Entwickler blieben dafür verantwortlich, die Arbeit zu definieren und Ergebnisse zu beurteilen. Sie schrieben klarere Spezifikationen, legten Architektur- und Sicherheitsgrenzen fest und konzentrierten die Prüfung auf riskantere Änderungen, Auswirkungen auf die Produktion und Fälle, in denen Checks oder Reviewer uneins waren.

Erst die Spezifikation, enge Agenten, strikte Grenzen

Die erste Lehre ist eine bis heute geltende Regel: kein Code ohne zuvor geschriebene Markdown-Spezifikation. Jede Spezifikation beschreibt, was die Änderung bewirkt, woran das Team erkennt, dass sie funktioniert, und was sie nicht kaputt machen darf. Brekelmans zufolge war der Agent selten der Engpass. Der Engpass sei gewesen, nicht genau zu wissen, was das Team eigentlich wollte. Viele Spezifikationen entstehen zunächst mündlich: Ein Agent macht aus dem besprochenen Konzept einen ersten Entwurf, den ein Mensch anschließend überarbeitet. Das habe mehr fürs Tempo gebracht als jedes einzelne Modell-Upgrade, schreibt er.

Die zweite Lehre betrifft den parallelen Einsatz vieler Agenten. Jeder Agent arbeitet in einer eigenen Kopie des Repositorys an genau einer Aufgabe auf Basis einer Spezifikation. Enge Aufgaben führen laut Microsoft zu weniger Fehlern, und das Team wählte die Modelle je Aufgabe als Abwägung zwischen Qualität und Kosten, statt immer das günstigste zu nehmen.

Die Sicherheit beruht auf einer Trennung. In Copilot Cowork läuft das Modell in einem Container ohne Nutzer-Zugangsdaten. Ein vertrauenswürdiger Host außerhalb des Containers übernimmt Identität, Richtlinien, Freigaben und Werkzeuge, und jede Microsoft-365-Operation läuft über ihn. Das Modell kann planen und alles anfordern, der Host entscheidet, was tatsächlich geschieht. Weil der Agent nur über eine definierte Schnittstelle mit dem Host spricht, konnte das Team später den gesamten Host austauschen, ohne den Agenten zu ändern. Genau das geschah bei der Migration auf Rust.

Reviewer-Bots und Checks, die scheitern können müssen

Da neun Personen nicht jede Änderung lesen können, wurde die menschliche Prüfung zum langsamsten Schritt. Mehrere Entwickler bauten jeweils einen Review-Bot nach ihrem eigenen Prüfstil, und die Bots traten gegeneinander an. Wenn einer fand, was ein anderer übersehen hatte, bekam der Letztere eine neue Regel. Laut Microsoft hat jeder von ihnen mindestens 10.000 Generationen durchlaufen, in denen er Reviews ausführte und aus übersehenen Fehlern lernte.

Bei einer Stichprobe aktueller gemergter PRs lag die mittlere Zeit bis zu einem brauchbaren ersten Review laut Beitrag bei etwa viereinhalb Minuten. Es folgen langsamere Durchläufe, darunter einer, der den Aufrufgraphen nach nicht angebundenem Code und nach Tests durchsucht, die auch nach einem Rückgängigmachen der Änderung noch bestehen würden, sowie einer, der betriebliche Aspekte wie Neustartsicherheit, Metriken und veraltete Dokumentation prüft.

Das Team betont die Grenzen automatisierter Reviews. Eine Gruppe von Reviewer-Agenten, die jeweils versuchen sollten, eine Änderung in einem sensiblen Produktbereich zu knacken, fand nichts. Menschen lasen anschließend denselben Diff und entdeckten vier blockierende Probleme, die alle vor dem Merge behoben wurden. Das Team setzt agentische Reviews deshalb als erste Prüfung ein und ergänzt bei kritischen Änderungen mindestens eine menschliche Kontrolle. Die Befunde werden in zwei Stufen unterteilt:

• Blockierend: Korrektheit, Sicherheit, Datenverlust oder ein neuer Mechanismus ohne Test, der sein Versagen bemerken würde.
• Hinweis: alles Übrige, das der Autor behebt oder beantwortet, ohne eine weitere Review-Runde zu erzwingen.

Eine weitere Lehre stammt von einem Check, der gar nicht scheitern konnte. Eine Größenbegrenzung für Anweisungsdateien von Agenten wurde überschritten, während der prüfende Check grün blieb, weil das Skript die Ausgabe durch tail leitete, dessen Exit-Code immer erfolgreich ist. Ähnliche Probleme fand das Team auch anderswo, etwa bei einem Formatierungs-Check, dem eine leere Dateiliste übergeben wurde.

Was das für andere Teams bedeutet

Microsoft betont, die sechs Praktiken seien kein Rezept, um die eigene Zahl an Pull Requests zu erreichen. Sie seien Lehren, die andere Teams anpassen können, um schnell voranzukommen und dabei Zuverlässigkeit, Sicherheit und Kosten im Blick zu behalten. Sie betreffen die Spezifikation von Arbeit, den Einsatz von Agenten innerhalb klarer Grenzen, das Testen von Checks, die Bewahrung des im Team Gelernten, die Gestaltung der Codebasis für parallele Arbeit und das Setzen von Grenzen für automatisierte Schleifen. Der hier vorliegende Quelltext behandelt die ersten drei ausführlich.

Der Beitrag kündigt zudem eine Fallstudie an, die die Praktiken zusammenführt: die Umstellung der laufenden Laufzeitumgebung von Python auf Rust, deren Cutover in der Grafik des Unternehmens zwischen dem 23. September und dem 10. Oktober markiert ist.