GitHub rewrote the Copilot runtime in Rust with one developer and a fleet of agents

430,000 lines of TypeScript out. More than 800,000 lines of production Rust in. 128 incremental pull requests, 135 releases, May through August 2026, one primary human developer, and agents writing most of the code.

GitHub published the full writeup on its engineering blog, and it's the largest documented agent-carried migration anyone has put numbers on. The motivation was mundane: the old Node runtime forced every SDK consumer to spawn a separate CLI process, costing over 100 MB of memory per client plus out-of-process JSON-RPC overhead. That's a normal platform-team problem. The interesting part is how they paid for it.

They logged 12.76 million session events during the port and report a 96.22% prompt-cache hit rate. Hold on that number. A long autonomous session is mostly re-reading the same context over and over. At a 96% cache hit rate the marginal cost of turn 40 is close to the cost of turn 4. At a 40% hit rate it isn't, and your rewrite dies in the budget meeting rather than in code review. GitHub didn't get 96.22% by accident. That's the output of deliberately structuring prompts so the stable prefix stays byte-identical across turns.

I want to push back on the framing, though. "One developer" is doing a lot of work in that headline. One developer wrote 128 PRs' worth of review, ran 135 releases, and owned the production incident surface for a runtime serving Copilot. The agents produced the diff. The human absorbed the consequence of every one. That's not a story about a 10x engineer, it's a story about what happens when generation cost collapses and review cost doesn't. Anthropic's own internal standard, disclosed earlier this month, is that Claude-written production code gets reviewed harder than human-written code. GitHub's 14.5 weeks is what that discipline looks like when it's applied to 800k lines.

For anyone considering this at smaller scale: the incremental-PR structure matters more than the model choice. 128 PRs across 14.5 weeks is roughly nine a week, each small enough to review and revert. The failure mode I've hit personally on large agent-driven refactors is exactly the opposite shape, one enormous branch nobody can evaluate. Slice it until each slice is independently verifiable, then measure your cache hit rate before you scale the loop up. Both numbers are the story.