GitHub Rewrote Its Copilot Runtime in 832,000 Lines of Rust

GitHub engineer Stephen Toub published a retrospective on September 16 detailing a large-scale rewrite led by a Copilot agent: the runtime behind the Copilot agent was rebuilt entirely from TypeScript/Node.js into Rust. Around 430,000 lines of production TypeScript ended up as 832,378 lines of production Rust, plus 468,000 lines of Rust unit tests and 174,000 lines of end-to-end tests.

The work ran from May 12 to August 21 — about 14.5 weeks. Over that stretch, 128 pull requests were merged incrementally into main, with continuous releases along the way: 135 versions in total (100 pre-releases and 35 stable releases), averaging roughly 1.3 releases a day.

Most of the code was machine-written — so what did the human do?

Toub's verdict on the exercise is blunt:

"A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months."

A project that would have needed a whole team of developers a year or two before agents existed was now completed mainly by a single developer, in just a few months.

The primary models were Claude Opus 4.8, GPT-5.6 Sol, and the Claude Haiku family; subagents handling throughput optimization leaned toward Opus 4.8 and GPT-5.6 Sol. That's a telling detail: for a production-grade rewrite of one of its own core components, GitHub — owned by Microsoft — relied mainly on models from Anthropic, a competitor, rather than exclusively on OpenAI's.

What the human did is clearly delineated. In the lead engineer's own account of his interactions, 31% of his time went to "reviewing, testing, and CI," 17.4% to "challenging technical decisions," and 15% to "pushing for completeness." Architecture, design trade-offs, and the final call on merges stayed with the human throughout — the models produced volume, the human held direction and acceptance.

Validation leaned on existing tests; about fifty things broke

The rewrite didn't introduce a separate acceptance bar — it ran the existing end-to-end test suite continuously against the new Rust code, shipping incrementally so regressions would surface early, in small batches. A few other engineering figures stand out: a prompt cache hit rate of 96.22%, and context compaction that fired 5,116 times across sessions.

The failures were also logged honestly. Roughly 50-plus known issues surfaced across the project, falling into five categories: incomplete migration, state and lifecycle problems, inconsistent behavioral contracts, host-boundary issues, and cases where the test's own expectations were simply wrong. Most were fixed before reaching a stable release. That last category is worth flagging for anyone doing a similar migration: when you're using old tests to gate a new implementation, sometimes it's the test that's wrong, not the new code.

What this means for engineering teams elsewhere

Cases like this — using AI to overhaul a company's own core component — say more about the real limits of today's coding agents than any benchmark leaderboard. Three things are directly transferable: first, don't expect a one-shot rewrite — 128 incremental pull requests and several releases a day are how continuous integration spreads out the risk; second, fix your acceptance anchor ahead of time — this whole effort used the existing E2E suite as its ruler, and without one there's no way to judge whether the model got it right; third, human effort shifted from writing code to reviewing, deciding, and catching gaps, which is what let a single person oversee a rewrite an order of magnitude larger than before.

One caveat worth keeping: the architectural payoffs — in-process embedding, lower memory overhead, faster startup — are described only qualitatively in the original writeup, with no before-and-after numbers for memory, latency, or throughput. How much real performance the rewrite bought is something this recap doesn't let us verify. The TypeScript-to-Rust path also isn't a default playbook for most teams — it works here because there was a test suite solid enough to lean on and a team willing to ship daily.

Sources: CocoLoop, GitHub Blog (Stephen Toub); figures such as 832,000 lines, 128 pull requests, 14.5 weeks, a 96.22% cache hit rate, and about 50 known issues were checked against the official retrospective.