Microsoft’s Copilot Cowork team merged 1,211 PRs in a day, then swapped Python for Rust

Microsoft says nine engineers merged 1,211 pull requests into the Copilot Cowork backend on October 21, with agents writing most of the code. In an engineering post dated November 2, the company also describes moving the live runtime from Python to Rust.

From empty repo to general availability in months

Partner Software Engineer Bas Brekelmans, who wrote the post, says the first commit came on January 13. Copilot Cowork, an agentic layer that performs multi-step workflows for users, reached its first enterprise customers in the Frontier program on March 30 and worldwide general availability on June 16, with several models and 16 plugins.

Merged pull requests per month rose from 257 in January to 2,754 in May, according to the post. In the week of October 12, 4,581 pull requests merged, about 650 a day, and Microsoft says a growing share came from an automated harness it calls the factory. The post stresses that the count is not a target for other teams.

The team lists six practices. Every change starts with a written markdown spec covering what it does, how success is judged and what it must not break. Narrow agents work in parallel from one spec each. Review bots compete and learn from each other’s misses. Lessons live in the repo as roughly 30 rule files. The Rust workspace was restructured for parallel work. Automated loops get a target, a limit on attempts and a list of actions reserved for people.

Reviewer bots missed what people caught

The post is candid about limits. A group of reviewer agents, each told to try to break a change in a sensitive part of the product, found nothing; engineers then found four blocking issues. Microsoft now requires at least one human check for critical changes. A first agent review arrives in a median of about four and a half minutes on a sample of recent merged PRs.

One check could never fail because its output was piped through tail, which returns its own exit code. The team now requires every check to report how many files it examined and to ship with a test that makes it fail on purpose. As the post puts it, agents keep working until checks pass, so a check that can pass without testing anything will eventually be exploited.

In its security design, the model runs in a container without user credentials, while a trusted host handles identity, policy, approvals, tools and audit. Microsoft says this let it replace the whole host later without touching the agent.

Rust cut time to first token on one comparison

Python, the post says, got the product to GA but hit limits at scale: event-loop stalls of up to 11.9 seconds, session setups that hit a hidden 5.000-second timeout in 16.7% of cases, and 539 out-of-memory kills of the Python process in one week on a single cluster.

The Rust cutover began with a rolled-back attempt on September 23, served its first production turns on September 24, deleted the Python runtime on October 9 (about 8,000 files and 4.9 million lines) and moved the last cluster on October 10. To check correctness, the team generated about 430 fixtures by running the real Python code and recording outputs, which the Rust tests must reproduce exactly.

On the first turn of a session, Microsoft compared one Rust cluster with one Python cluster over the same 12 hours in late September. Median time to first token fell from 7.9 to 2.7 seconds, and the 90th percentile from 14.5 to 6.2 seconds. The company notes that part of the gain comes from moving the agent loop out of a slow-starting container, not from Rust alone, and says it has not yet measured cost per turn. Two regressions slipped through: event ordering that Python had delivered implicitly, and a front door roughly six times slower to acknowledge messages. Both were fixed.

What the numbers do and do not show

The sturdiest idea here is the verification method. Recording what a running system does, instead of reading old and new code side by side, gives a rewrite an executable specification, and it is only feasible because the old system was still live. Microsoft itself says the practices fit best when “done” can be defined and a replacement can be compared with the system it replaces. It also admits that no fixture caught the event-ordering bug, because nobody had thought to record ordering.

The post also shows why autonomy and guardrails travel together. Other recent Microsoft work points the same way: its open Mage-VL-Cowork model for computer use scores 66.0% on OSWorld-Verified, per Microsoft’s model card as summarized in our explainer, against 38.1% reported by OpenAI for its first Computer-Using Agent in January 2025. As agents grow more capable, the post’s emphasis on keeping credentials and authority outside the model is a notable design choice.

Caution is warranted on the evidence. Every figure comes from Microsoft’s own post; none is independently verified, and the post does not say how many of the 1,211 pull requests were small or automated. The post does not describe pricing or availability for Copilot Cowork beyond GA, and the work is a lessons-learned account, not a product launch. Quality questions remain for Microsoft’s assistants more broadly: the Washington Post found Copilot cited an error-prone AI-built voter site in 75% of its tests, according to secondary summaries we reported on, a reminder that development speed and answer accuracy are separate measures.

For readers building with agents, the practical advice is modest. Microsoft suggests starting with one check the team trusts, making it fail deliberately, then giving an agent one bounded task with written success criteria. In the post’s words, the aim is to move human attention to the decisions that matter more “when code arrives faster.”