GitHub Rewrote 832,378 Lines of Rust With AI Agents: What the Numbers Actually Show (2026)

What GitHub Did

Between May 12 and August 21, 2026 — about 14.5 weeks — GitHub ported its shared Copilot agent runtime from TypeScript on Node.js to Rust. The final result:

Metric	Value
Production Rust	832,378 lines
Rust unit tests	468,689 lines
End-to-end TypeScript tests	174,675 lines
Porting pull requests	128
Porting window	~14.5 weeks
Production TypeScript remaining	0 lines
Memory usage	down 91%

The runtime is not a side component. It backs the Copilot CLI, the Copilot app, and the Copilot SDK, plus VS Code, Visual Studio, the Copilot cloud agent, Copilot Code Review, Copilot Cowork, and Copilot Studio.

The headline that travelled is "832,378 lines in 14.5 weeks by one engineer." The parts worth studying are how.

Why Rust Was Worth the Churn

The TypeScript runtime's problem was architectural, not aesthetic. Embedding it through SDKs was expensive: creating a CopilotClient launched the CLI as a separate process, dragging Node.js and the V8 engine along with it. Every SDK user — C#, Python, Go, Java, Rust — carried an additional language runtime per client, with a minimum working set on the order of 100MB, and messages and file operations had to cross a process boundary.

Rust allowed in-process embedding through a C ABI, reduced startup and steady-state overhead, improved resource predictability, and interoperated with all six SDK language versions. The 91% memory reduction follows from that structural change rather than from micro-optimization.

The Method Is the Story

GitHub rejected the two obvious approaches — a long-lived "big bang" branch, and running parallel TypeScript and Rust implementations of the same components. Instead it used incremental, component-by-component replacement:

1. Each porting PR replaced one TypeScript implementation with a thin shim into Rust
2. The old implementation was deleted atomically in the same PR
3. Existing end-to-end tests for the CLI and SDK ran against the new code at every stage
4. A change could not land if it broke a required test

Because every merge left the system working, the main branch kept shipping throughout: 135 releases during the porting window — 100 pre-release and 35 stable versions, averaging about 1.3 releases per day. A trailing seven-day npm sample showed pre-release versions accounted for 10.5% of downloads, which limited exposure while GitHub watched for regressions and fixed them quickly.

That is the difference between a rewrite you can ship and a rewrite that blocks the roadmap for a quarter.

The Detail Worth Copying: 10x More Reading Than Writing

GitHub published the tool-call distribution, and it is the most transferable number in the whole writeup.

Tool	Calls	Category
view	590,988	read
rg (ripgrep)	281,783	search
grep	126,483	search
apply_patch	53,715	mutate
edit	40,591	mutate

Roughly 10x more exploration than mutation. The agents spent the overwhelming majority of their effort understanding existing code, then made comparatively few, comparatively targeted changes.

Read that as a specification for how to configure coding agents on a migration: constrain the write surface, invest the budget in comprehension, and require the agent to prove it understands the target before touching it. An agent that starts patching before it has read the surrounding code is not doing this.

One honest caveat on the ratio: it may reflect how good the repository's evidence was. The old implementation, 468,689 lines of unit tests, and full type signatures were all sitting in the repo — an unusually well-lit environment for an agent to reason in. A codebase without that scaffolding will produce a different distribution, and probably a worse outcome.

The Numbers Behind the Numbers

One engineer. Toub estimates the equivalent effort would previously have taken a full development team one to two years. His own framing is more careful than most retellings, and worth quoting in full:

"The agents changed the amount of code one engineer could supervise. They did not remove the need for an engineer who understood the system and could vouch for the direction, the guardrails, and the release."

The first sentence is about throughput. The second is about accountability, and it is the part that survives contact with a regulated codebase.

Scope growth. About 430,000 lines of production TypeScript ultimately passed through the port — far above the early-May estimate of roughly 130,000 lines, as runtime scope expanded and concurrent development continued. Migration estimates based on "current LOC" are systematically optimistic.

A caveat GitHub stated. Toub was explicit that this is not a claim that every large TypeScript program should be moved to Rust. The method transfers; the language decision does not.

This Is No Longer a Single Case

GitHub is the largest example, but the pattern is now familiar:

Project	Migration	Approach	Reported outcome
GitHub Copilot runtime	TypeScript → Rust	Incremental, 128 PRs, 14.5 weeks	832K lines, 91% less memory
Bun (Anthropic)	535,496 lines of Zig → Rust	Parallel Claude Code agents, all-at-once	Passing tests on all six platforms 11 days in
React Compiler (Meta)	TypeScript → Rust	AI-majority code, human architecture oversight	—
OpenAI Habitat	Python → Rust	Codex and GPT-5.5	6x less CPU, 15x less memory for 95% of production requests

The Bun and GitHub playbooks are opposite: eleven days of parallel agents versus fourteen weeks of incremental shims. That gap is not a Claude-versus-Copilot benchmark — the codebases, risk tolerances, and release constraints differ completely. It is evidence that there is no single correct agentic migration playbook, only a choice between speed and blast radius.

What to Take From It

For engineering leaders: the affordability calculation for large migrations has genuinely changed, but the constraint moved rather than disappeared. You still need one engineer who can vouch for the whole system. What you no longer need is a team of ten for two years.

For teams planning a migration: copy the mechanics — atomic per-component replacement, thin shims, existing tests gating every merge, no parallel implementations, no long-lived branch. Those choices are what kept 135 releases shipping during a language rewrite.

For anyone quoting the numbers: the impressive figure is not the line count. It is that 128 incremental PRs landed on an active main branch without freezing the product, on a codebase where a required test could veto any change.

For skeptics: the honest limitation is the test coverage. The 468,689 lines of existing Rust unit tests did not exist at the start — they accumulated during the port alongside production code, on top of a codebase that was already well-tested in TypeScript. Migrations of untested systems will not look like this.

Summary

GitHub's Copilot runtime migration is the clearest evidence yet that large-scale rewrites have moved from "strategically unaffordable" to "one engineer plus agents, if the codebase can support it." The 832,378 lines make the headline; the 14.5 weeks, 128 incremental PRs, and 10:1 exploration-to-mutation ratio are what another team can actually reuse.

The strategic reading is narrower than "AI writes code now." Agents changed how much code one engineer can supervise. They did not change who is accountable when it ships — and GitHub's own engineer says so in the post.

For how these agents are wired up underneath, see the OpenAI Agents API guide and Cursor Projects; for model costs in review pipelines, see cheap vs frontier code review.

Related Articles

• Cursor Projects Review
• OpenAI Agents API Guide
• Cheap vs Frontier Code Review
• Best AI Coding Agents 2026