GitHub’s Rust rewrite is a large coding-agent case study, but its strongest lesson is not that one person prompted 800,000 lines into existence. It is that tests and release engineering turned generated code into an incremental migration.
The GitHub Copilot Rust migration moved the Copilot agent runtime from TypeScript, Node.js and V8 to a native Rust implementation. GitHub says the finished system contained 832,378 lines of production Rust, 468,689 lines of Rust unit tests and 174,675 lines of end-to-end TypeScript tests. The work landed through 128 pull requests and shipped in stages.
The scale of the published case
| Measure | GitHub-reported result | Why it matters |
|---|---|---|
| Production Rust | 832,378 lines | The target was a complete runtime, not a demo module. |
| Rust unit tests | 468,689 lines | Generated implementation was paired with a large native test surface. |
| End-to-end TypeScript tests | 174,675 lines | The old external behavior remained an oracle during the language change. |
| Pull requests | 128 | Review and rollout occurred in bounded increments. |
| Attributed token cost | About $120,000 | This is a company-reported project cost, not a universal migration estimate. |
| Developer time | Three weeks for one developer | The case still depended on team knowledge, review and existing infrastructure. |
Line count is not a quality metric, and token spend is not total cost. Review time, test infrastructure, debugging, coordination, compute and the original system knowledge all belong in the denominator. The numbers are useful because GitHub published them, not because they make every rewrite economical.
Why this was not one giant rewrite
A language migration has two products: the new implementation and the evidence that it still behaves correctly. GitHub kept the behavioral contract visible while translating pieces behind a compatibility boundary. Each pull request could be reviewed, tested and released without waiting for a final all-or-nothing cutover.
- Define an interop seam between old and new runtimes.
- Move one bounded subsystem and preserve its external contract.
- Run unchanged end-to-end tests against the Rust path.
- Classify differences as intended changes, implementation bugs or test assumptions.
- Ship the compatible increment and observe production behavior.
- Repeat until the old runtime can be removed.
The old system served as a fixed oracle
When an agent rewrites code and tests at the same time, both can drift toward the same mistake. Keeping a body of end-to-end tests unchanged creates an external constraint. Golden outputs, protocol fixtures, error codes, timing rules and telemetry schemas can play the same role.
| Regression class | Migration check |
|---|---|
| Semantic mismatch | Run identical inputs through old and new paths and compare normalized outputs. |
| Protocol drift | Replay fixtures for framing, cancellation, retries and malformed input. |
| Performance regression | Measure cold start, memory, throughput and tail latency, not only averages. |
| Observability gap | Verify logs, traces, metrics and incident identifiers before traffic moves. |
| Operational incompatibility | Test deployment, rollback, configuration and resource limits. |
| Test migration error | Require independent review when a test changes with implementation code. |
What the coding agent did and what humans still owned
Copilot could translate repetitive code, propose Rust structures, fill tests, fix compiler errors and iterate on bounded tasks. Humans still selected architecture, defined the compatibility seam, decided whether behavior should change, reviewed security-sensitive code and controlled deployment. A large generated diff without those controls would be a risk multiplier.
GitHub’s report also benefits from an unusually rich environment: the team owned the source runtime, its tests, the destination platform and the coding agent. Organizations with sparse tests, undocumented behavior or outsourced components should expect the discovery phase to dominate.
A migration checklist for other teams
- Inventory external behaviors before translating implementation details.
- Choose one compatibility seam that supports gradual traffic movement.
- Freeze an acceptance suite that the agent cannot casually rewrite.
- Keep pull requests small enough for a human to explain.
- Require reproducible builds, dependency review and secret scanning.
- Define performance budgets for startup, memory, throughput and tail latency.
- Shadow traffic before serving real users from the new path.
- Preserve a tested rollback until production evidence is stable.
- Track agent tokens, developer time, review time and infrastructure cost together.
- Record every intentional behavior change separately from translation work.
Our Copilot and Sentry review guide covers the same human merge boundary at a smaller scale. The AI GitHub repositories reference includes migration, testing and agent tooling useful for reproducing this pattern.
How to read the cost and performance claims
GitHub reports substantial performance gains from the Rust runtime and attributes roughly $120,000 in tokens plus three weeks of one developer’s time. Both are company-reported. A buyer should ask which benchmarks were selected, what hardware and load were used, how review time was counted and whether the new runtime also changed architecture.
The practical verdict
This is evidence that coding agents can participate in very large production migrations when the behavior is constrained and the release path is incremental. It is not evidence that line count can replace engineering judgment. The reusable asset is the migration control system: a fixed oracle, small pull requests, interop, regression classification, production observation and rollback.
Primary source
Checked September 19, 2026. Project size, cost and performance figures are reported by GitHub and have not been independently reproduced by MustHave.ai.
