Op 21 oktober 2026 voegden negen engineers volgens Microsoft 1.211 pull requests samen in de hoofdbranch van de Copilot Cowork-backend. In Microsofts engineeringverslag beschrijft het bedrijf een aanpak waarbij agents het meeste codewerk deden, terwijl engineers de specificaties, architectuur en beveiligingsgrenzen bepaalden en belangrijke wijzigingen beoordeelden.
Wat de pull-requestcijfers vertellen
De 1.211 pull requests horen bij één dag: 21 oktober. Microsoft meldde daarnaast 4.581 samengevoegde pull requests voor de week van 12 oktober, gemiddeld ongeveer 650 per dag. Dat zijn afzonderlijke tellingen van werk aan de backend; het aantal pull requests zegt op zichzelf niets over de kwaliteit van de code.
Hoe Microsoft agentwerk afbakende
Voor elke wijziging moest eerst een Markdown-specificatie worden opgesteld: wat de wijziging moest doen, hoe het team succes zou vaststellen en wat niet mocht veranderen. Agents konden een eerste versie maken op basis van een gesproken beschrijving, waarna een mens die bewerkte. Parallelle agents kregen elk een eigen kopie van de repository en één taak met één specificatie. Microsoft zegt dat het team zo opschaalde van één agent naar vijf en later tientallen.
Microsoft beschrijft ook een grens tussen de agent en Microsoft 365. Het model draaide in een container zonder gebruikersgegevens. Een vertrouwde host buiten die container regelde identiteit, beleid, goedkeuringen, uitvoering van hulpmiddelen en audit. Elke Microsoft 365-bewerking liep via die host; het model kon acties plannen en aanvragen, maar de host bepaalde wat er gebeurde.
Agentbeoordelaars hielpen bij de eerste controle, maar voor kritieke wijzigingen bleef menselijke beoordeling nodig. In één gevoelig geval vonden mensen vier blokkerende problemen die de beoordelaarsagents hadden gemist. Ook maakte het team checks controleerbaarder: elke check moest rapporteren hoeveel bestanden hij onderzocht, en nieuwe checks moesten een test bevatten die de check bewust liet falen. Zo kon het team zien of een groen resultaat werkelijk betekende dat er iets getest was.
Hoe de Python-naar-Rust-migratie werd getest
Microsoft zegt dat het team ongeveer 430 testfixtures maakte om het gedrag van de bestaande Python-implementatie vast te leggen. Generators voerden Python uit met vastgelegde invoer en bewaarden de uitvoer, zoals responsen en opslagbewerkingen, in JSON. Tests voor Rust speelden die resultaten vervolgens opnieuw af.
De eerste fixtureverzameling legde een impliciete volgorde van gebeurtenissen niet vast. Daardoor behield de eerste Rust-versie die volgorde niet. Microsoft zegt dat het team dit probleem heeft opgelost. Ook wachtte de eerste Rust-frontdoor volgens het bedrijf op de volledige verwerking voordat die een bericht bevestigde, waardoor dat ongeveer zes keer zo lang duurde; ook die kwestie werd verholpen.
Wat Microsofts latencycijfers laten zien
In een vergelijking over dezelfde periode van twaalf uur eind september rapporteerde Microsoft de volgende tijd tot de eerste token bij de eerste beurt. P50 is de mediaan; bij p90 ligt 90 procent van de gemeten waarden op of onder de genoemde tijd.
| Runtime | P50, seconden | P90, seconden |
| Python | 7,9 | 14,5 |
| Rust | 2,7 | 6,2 |
De vergelijking meet niet alleen het effect van de programmeertaal. Tijdens de migratie verplaatste Microsoft ook de agentloop uit de container naar de Rust-service; volgens het bedrijf droeg die wijziging substantieel bij aan de lagere tijden.
Microsoft meldde in de Python-omgeving onder belasting vertragingen in de eventloop tot 11,9 seconden. Verder duurde 16,7 procent van de sessie-initiatieven precies 5 seconden doordat een time-out afging, en werd een Python-proces in één cluster 539 keer in een week beëindigd. Na de migratie waren volgens Microsoft de eventloopvertragingen en time-outgevallen verdwenen.
De kosten per beurt heeft Microsoft naar eigen zeggen nog niet goed gemeten. Het bedrijf claimt daarom niet dat de migratie de kosten verlaagde.
De praktijkvraag rond programmeerwerk
Een individuele Reddit-gebruiker beschreef hoe een Copilot Studio-agent met projectvoorbeelden en instructies hielp bij de ontwikkeling van Logic Apps, maar meldde dat de uiteindelijke Logic App nog handmatig moest worden overgezet. In een andere gebruikersdiscussie verschilden de meningen over wanneer meerstapsorkestratie iets toevoegt boven een gewone Copilot-opdracht. Dat zijn persoonlijke ervaringen en opvattingen, geen algemene productvergelijking.
