Microsoft: Nine engineers merged 1,211 pull requests in a day on Copilot Cowork

From empty repo to general availability

Copilot Cowork is described by Microsoft as an agentic execution layer that performs multi-step workflows on a user's behalf. The goal is to bring the AI-assisted tools that developers already use to everyday knowledge workers, with Work IQ, Microsoft 365 security and governance, cloud execution and Microsoft's multi-model architecture.

Bas Brekelmans, Partner Software Engineer at Microsoft, writes that the first commit was made on January 13. Copilot Cowork 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. The team later moved the runtime from Python to Rust while the product was live.

According to Microsoft, merged pull requests per month rose from 257 in January to 2,754 in May, and the busiest week before general availability had 783. Engineers stayed responsible for defining the work and judging results. They wrote clearer specs, set architecture and security boundaries, and focused review on higher-risk changes, production impact, and cases where checks or reviewers disagreed.

Specs first, narrow agents, strict boundaries

The first lesson is a rule that still stands: no code without a markdown spec written first. Each spec covers what the change does, how the team will know it works, and what it must not break. Brekelmans says the agent was rarely the bottleneck. The bottleneck was not knowing exactly what the team wanted. Many specs start out spoken, with an agent turning a talk-through into a first draft that a human then edits. He writes that this did more for speed than any single model upgrade.

The second lesson concerns running many agents at once. Each agent works in its own copy of the repo, on one task, from one spec. Microsoft says narrow tasks produce fewer mistakes, and that the team picked models per task as a quality-and-cost tradeoff rather than always choosing the cheapest.

Security rests on a separation. In Copilot Cowork, the model runs in a container without user credentials. A trusted host outside the container handles identity, policy, approvals and tools, and every Microsoft 365 operation goes through it. The model can plan and ask for anything, and the host decides what actually happens. Because the agent talks to the host only through a defined interface, the team could later replace the entire host without changing the agent, which it did in the Rust migration.

Reviewer bots and checks that must be able to fail

With nine people unable to read every change, human review became the slowest step. Several engineers each built a review bot modeled on their own review style, and the bots competed. When one caught what another missed, the one that missed it got a new rule. Microsoft says each has been through at least 10,000 generations of running reviews and learning from misses.

On a sample of recent merged PRs, the median time to a useful first review was about four and a half minutes, according to the post. Slower passes follow, including one that walks the call graph for unwired code and tests that would still pass if the change were reverted, and one that checks operational issues such as restart safety, metrics and stale docs.

The team stresses the limits of automated review. A group of reviewer agents, each told to try to break a change in a sensitive part of the product, found nothing. People then read the same diff and found four blocking issues, all fixed before merge. The team now keeps agentic review as the first check and adds at least one human check for critical changes. Findings are split into two tiers:

• Blocking: correctness, security, data loss, or a new mechanism with no test that would catch it breaking.
• Advisory: everything else, which the author fixes or answers without forcing another review round.

Another lesson came from a check that could not fail. A size limit on agent instruction files was exceeded while the enforcing check stayed green, because the script piped output through tail, whose exit code always succeeds. The team found similar problems elsewhere, including a formatting check given an empty list of files.

What it means for other teams

Microsoft says the six practices are not a recipe for matching its pull request count. It presents them as lessons other teams can adapt to move fast while keeping reliability, security and cost in view. They cover how to specify work, run agents within boundaries, test checks, preserve what the team learns, shape the codebase for parallel work, and set limits on automated loops. The source text provided here covers the first three in detail.

The post also promises a case study that puts the practices together: the move of the live runtime from Python to Rust, with the cutover marked between September 23 and October 10 in the company's chart.