Beyond the News
Sign in
Artificial IntelligenceWeb DevelopmentAI CodingDeveloper Tools Active dossier

GitHub rewrote Copilot’s 800,000-line agent runtime in Rust with agents doing most of the coding

GitHub has completed an in-place rewrite of the shared Copilot agent runtime from TypeScript/Node.js to 832,378 lines of production Rust. One primary engineer drove the migration with Copilot agents writing most of the code across 128 pull requests, while the runtime kept shipping to users.

Reviewed and published by Lars Jansen Updated 7 min read
Comment
First published

Key details

  1. GitHub published the migration account on September 16, 2026.
  2. The port ran from May 12 to August 21, roughly 14.5 weeks.
  3. The finished runtime contains 832,378 lines of production Rust and 468,689 lines of Rust unit tests, according to GitHub.
  4. Roughly 430,000 lines of production TypeScript passed through the migration.
  5. Agents wrote most of the code across 128 pull requests; the runtime shipped through more than 135 releases during the work.
  6. GitHub attributes about $120,000 in model-token cost and roughly three weeks of the primary engineer's directly attributed time to the port.
  7. GitHub had identified and fixed dozens of known port regressions by September 14, including some that reached stable releases.
  8. A workload-specific benchmark improved from 7.55 session lifecycles/second in the TypeScript process tree to 120/second with the in-process Rust runtime.
  9. Measured private-memory growth in one ten-client workload fell from 1,383 MB to 126 MB in the in-process Rust configuration.

What builders should take away

  1. Do not start a large agent-assisted migration until you have a trustworthy behavioural oracle: tests, compatibility fixtures and production observability are what make cheap generation useful.
  2. Migrate behind stable interfaces in small replaceable slices so old and new implementations can coexist and ship continuously.
  3. Track agent cost separately from engineering cost. GitHub's roughly $120,000 token bill was acceptable because the alternative was estimated in team-years, but that arithmetic will differ radically for smaller systems.
  4. Expect semantic regressions even when the target language has stronger safety properties; Rust's compiler cannot detect every behavioural mismatch in a translated system.
  5. Measure the architectural reason for a rewrite independently of AI productivity. GitHub gained from eliminating Node/V8 process overhead and enabling in-process embedding, not merely from changing languages.
  6. Plan review throughput and approval latency as first-class constraints when many agents can produce changes faster than humans can validate them.

What changed

On September 16, GitHub published a detailed engineering account of a migration completed between May 12 and August 21, 2026: the shared agent runtime behind Copilot CLI, the Copilot app and Copilot SDK moved from TypeScript running on Node.js/V8 to Rust. GitHub says roughly 430,000 lines of production TypeScript passed through the port and the finished runtime contains 832,378 lines of production Rust plus 468,689 lines of Rust unit tests. Copilot agents wrote most of the code. The work landed through 128 pull requests and more than 135 releases rather than a single cutover, with one engineer leading the port while the wider team continued changing the live runtime.

Why it matters

This is one of the clearest public case studies yet for what coding agents can change about the economics of a large software migration. GitHub's claim is not that an autonomous agent rewrote a production system from one prompt: the migration depended on existing behaviour, tests, incremental replacement, human review and repeated regression fixing. The project is useful precisely because GitHub publishes the ugly parts too—token cost, long-running agent sessions, approval bottlenecks and dozens of regressions—alongside evidence that the new in-process Rust architecture materially reduced runtime overhead.

Agents changed the cost of the rewrite, not the need for engineering

GitHub says the project was primarily driven by one engineer over roughly 14.5 weeks and consumed about $120,000 of model tokens. The author estimates a comparable rewrite before coding agents would have required a team for a year or two and would probably have lost the prioritisation battle. But the agents were constrained by a mature implementation, tests, compatibility requirements and human review; GitHub explicitly rejects the idea that it simply asked an agent to port the whole codebase.

The migration stayed shippable instead of waiting for a flag day

The team replaced TypeScript modules incrementally, landing 128 pull requests while both the old and new implementations coexisted behind an internal seam. More than 135 releases shipped during the migration. That made production behaviour and existing tests an oracle for the Rust implementation and reduced the risk of a single giant cutover.

The rewrite still produced dozens of regressions

By September 14 GitHub had traced and fixed dozens of known port regressions. Most were correctness failures, with a smaller group of performance regressions; some reached stable releases. GitHub groups recurring failures around incomplete migration, state/lifetime handling, behavioural-contract mismatches, host boundaries and incorrect test oracles. The result is evidence for agent-assisted migration, not evidence that generated ports can skip review.

The architecture change removed a costly process boundary

The TypeScript runtime required SDK hosts to launch Node/V8 and communicate across a process boundary. The Rust runtime can run in-process behind a C ABI while retaining an out-of-process JSON-RPC option. In GitHub's 100-client, ten-lifecycle benchmark, the old implementation completed 7.55 lifecycles per second; Rust reached 57.45 out of process and 120 in process. In a separate ten-client memory measurement, private resident-memory growth fell from 1,383 MB to 247 MB out of process and 126 MB in process.

The strongest lesson is verification capacity

Large agent-generated diffs are only useful when a team can cheaply establish equivalence and catch failures. GitHub repeatedly used existing behaviour, unit tests, end-to-end tests, CI, review and staged releases as constraints. The bottleneck visible in some long-running agent sessions was not generation but waiting for review and approval. Teams considering similar migrations should budget for the referee—the tests and observability that tell an agent when its translation is wrong—as seriously as they budget for inference.

What to watch next

  • Whether GitHub publishes post-migration reliability data once the Rust runtime has spent longer in stable production.
  • Whether other large engineering organisations reproduce the one-engineer-plus-agent migration pattern with similarly detailed cost and regression data.
  • How much additional performance GitHub gains once it replaces TypeScript-shaped translated algorithms with Rust-native designs.
  • Whether agent tooling improves at behavioural-equivalence checking, reducing the human review bottleneck exposed by long-running migration sessions.

Still unclear

  • The engineering, cost and performance measurements are primarily GitHub's own case-study data rather than an independently reproduced benchmark.
  • Lines of code are a poor direct measure of engineering complexity; the Rust implementation is substantially larger than the TypeScript code that passed through the port.
  • The reported 15.9x lifecycle result is workload-specific and GitHub explicitly says the Rust runtime is not universally 15.9x faster.
  • The project had an unusually strong starting oracle: a mature implementation, extensive tests and a large engineering organisation. Greenfield agent development does not have the same verification advantage.
  • Some regressions reached stable releases, and GitHub says additional unknown regressions may remain.

Sources

Direct reading behind this dossier.

3 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading