Skip to content
Neural Daily

ToolsNews

Copilot Cowork: 9 engineers, 1,211 PRs in a single day

🇭🇺 Olvasd el magyarul →

The Microsoft Copilot Cowork team explains how nine engineers merged 1,211 pull requests in a day with agents, and how they moved the live runtime from Python to Rust.

By: Mikola Máté Patrik · · 3 min read

Microsoft Copilot Cowork cover image with dotted lettering over white horizontal lines on a dark background
Image: Microsoft · Press kit · Official cover image of the Microsoft engineering post · Source

What happened?

The Microsoft Copilot Cowork team published a detailed write-up of how it builds with agents (Microsoft). Copilot Cowork is an agentic execution layer that carries out multi-step workflows on a user's behalf in Microsoft 365.

The project started from an empty repo on January 13 and reached worldwide general availability on June 16. On October 21, nine engineers merged 1,211 pull requests into the main branch of the backend. Agents wrote most of the code, while engineers owned the specs, the boundaries and the review of higher-risk changes.

What are the six lessons?

  • No code without a markdown spec first: what the change does, how we will know it works and what it must not break.
  • Narrow agents run in parallel, each in its own copy of the repo. The model runs in a container without user credentials, and a trusted host handles identity, policy and approvals.
  • Checks must prove they checked something: every check reports how many files it covered, and every new check comes with a test that makes it fail on purpose.
  • Team knowledge lives in the repo: agents read about 30 rule files at the start of each task.
  • The codebase is shaped for parallel work: Rust crates were sorted into four roles, and implementation to implementation dependencies on the exception list fell from 216 to zero.
  • Automated loops get a measurable target, an attempt limit and a list of actions that still need a person, such as deploying to production.

Review starts with agents, and the median first useful review arrives in about four and a half minutes. On one sensitive change, however, reviewer agents found nothing while engineers found four blocking issues in the same diff. That is why critical changes still require at least one human check.

How did the Python to Rust move go?

Under load the Python runtime showed event loop stalls of up to 11.9 seconds, 16.7% of session setups took exactly 5 seconds because of a hidden timeout, and in one week on a single cluster it was killed 539 times for running out of memory.

To verify ports, the team ran the real Python code over a set of inputs, saved the output as JSON fixtures and required the Rust tests to match them exactly. There are about 430 fixtures. Traffic moved one cluster at a time behind reversible flags: the Python runtime (about 8,000 files and 4.9 million lines) was deleted on October 9, and the last cluster moved on October 10.

Time to first token on the first turn dropped from 7.9 to 2.7 seconds at p50 and from 14.5 to 6.2 seconds at p90. The author attributes a large part of that to moving the agent loop out of a slow-starting container. The team makes no claim about cost yet, since it has not measured it properly.

What is the takeaway?

The point is not the PR count but where human attention goes when code arrives faster than people can read it. The cheapest place to start, as the author suggests: take one check your team trusts and confirm that it can actually fail.

    Produced with the help of AI, reviewed by an editor. How we make our articles

    Reviewed and edited by the Neural Daily desk. About

    Related articles