GitHub Rewrites Copilot in Rust: What AI-Assisted Migration Really Requires

TL;DR: GitHub rewrote a major AI runtime in Rust

GitHub says it rewrote the GitHub Copilot agent runtime from TypeScript and Node.js into more than 800,000 lines of production Rust, with AI agents writing most of the code. The project landed through 128 pull requests over several months, while the team continued shipping Copilot features. The important lesson is not that every JavaScript system should become Rust. It is that AI-assisted migration works best when the codebase has clear boundaries, strong automated checks, small reversible changes, and humans responsible for architecture and review.

What changed in the Copilot runtime

The runtime powers the Copilot CLI, Copilot app, SDK integrations, cloud agents, code review, and other products. Its original design used a TypeScript CLI as a separate process. SDK clients had to start Node.js and V8, communicate through JSON-RPC, and pay the memory and startup cost of another runtime. That architecture was fast to launch but expensive to embed in many host applications.

GitHub chose Rust because it wanted low startup overhead, predictable memory use, native embedding, strong concurrency, and a clean foreign-function interface for C#, TypeScript, Python, Go, Java, and Rust SDKs. The new design separates the agent runtime from the terminal UI and allows products to choose in-process or out-of-process hosting.

The reported performance change is substantial: the create-session, complete-turn, and teardown path moved from 5.25 seconds to 55.3 milliseconds in-process. Throughput rose from 7.55 to 120 sessions per second, while memory for ten clients fell from 1,383 MB to 126 MB. Those numbers are measurements from GitHub’s own workload, not a universal promise for Rust rewrites.

Why AI agents made the migration possible

GitHub describes a workflow in which Copilot handled repetitive implementation, while a developer supplied direction, reviewed changes, ran builds, examined regressions, and made design decisions. The work was divided into sessions and subagents, with build resources acting as a gate so that parallel work did not overwhelm validation.

That division matters. An agent can translate patterns quickly, but it does not automatically know which behavior is contractual, which race is dangerous, or which compatibility promise matters to customers. The human role moved upward: define invariants, choose sequencing, inspect interfaces, and reject plausible but incomplete code.

The migration also used an incremental architecture. Temporary interop layers connected Rust and TypeScript while individual components moved. Pull requests stayed reviewable, releases continued, and regressions could be tied to a smaller change. This is more useful than the headline “AI rewrote 800,000 lines,” because it gives teams a repeatable operating model.

A practical checklist for AI-assisted rewrites

1. Map boundaries first. Identify UI, runtime, storage, network, and FFI layers before asking an agent to edit code.
2. Write behavioral tests. Preserve externally visible behavior, not merely type signatures.
3. Port in slices. Keep a working build and a rollback path after every slice.
4. Use agents for bounded tasks. Ask for one module, one adapter, or one test family at a time.
5. Make validation a hard gate. Compile, run unit and integration tests, inspect resource use, and review diffs.
6. Track temporary interfaces. Every bridge should have an owner and a removal condition.
7. Measure the real workload. Startup, throughput, memory, crash behavior, and latency matter more than language fashion.

Developers looking for tools to organize coding, testing, and automation workflows can also browse the BTTC software catalog. The right utility will not replace review, but it can make the surrounding feedback loop faster.

What this means for software teams

The story is a strong case for treating AI coding as an engineering system rather than autocomplete. Large migrations need a backlog of explicit invariants, a dependency-aware order of operations, observable build health, and a review culture that can challenge generated code. Teams should also budget for integration work: language bindings, packaging, documentation, crash reporting, and operational tooling can outlast the first successful compile.

Rust may be a good fit when predictable resource use and embeddability are core requirements. It is not automatically the right answer for a stable web service or a small script. The durable decision framework is to compare constraints, not to copy the implementation language.

FAQ

Did AI write all of GitHub’s Rust code?

GitHub says AI agents wrote most of the code, but developers directed the work, reviewed pull requests, ran validation, and fixed regressions. “AI wrote the code” does not mean “AI owned the design.”

Why was Rust selected?

The stated goals included low overhead, predictable performance, native embedding, concurrency, and interoperability across several SDK languages. Those requirements made Rust attractive for this runtime.

Should every TypeScript project be rewritten in Rust?

No. A rewrite makes sense only when the benefits of resource use, startup time, embedding, or reliability justify migration cost and ongoing language complexity.

What is the most transferable lesson?

Use agents inside a controlled loop of small changes, automated tests, human review, and measured production-like benchmarks. The process is more transferable than the language choice.

Conclusion

GitHub’s Copilot runtime rewrite shows how capable coding agents can compress a large migration without removing engineering accountability. The winning pattern is incremental: establish contracts, give agents narrow tasks, keep validation close to every change, and measure the result against real workloads. For teams considering their own modernization project, that discipline is a better starting point than chasing a particular language or model.