|
GitHub Used AI Agents to Rewrite Copilot’s Runtime in Rust
GitHub migrated the core agent runtime behind Copilot from TypeScript and Node.js to more than 800,000 lines of Rust.
|
| |||||||||||||||
Your mobile carrier knows who you are. We don’t. (Sponsor)
 |
Cape is America’s privacy-first mobile carrier—unlimited talk, text, and 4G/5G data, built from the ground up with privacy and security at it’s core.
Most carriers track everything: where you go, who you call, what you do. Cape collects the minimum amount of information required to run your service, deletes call and text metadata after 24 hours, rotates your network ID to prevent tracking, defends against SIM-based attacks, and more.
Privacy shouldn’t cost more. Switch today and get $29 off for life.
Large software rewrites have traditionally been one of the easiest projects for engineering organizations to reject.
They are expensive. They consume senior engineers. They compete with product development. They introduce regressions. And after months—or years—of work, customers may receive essentially the same product running on a different implementation.
GitHub has just demonstrated what happens when AI coding agents dramatically change that equation.
On September 16, 2026, GitHub disclosed that the agent runtime powering GitHub Copilot had been rewritten from TypeScript running on Node.js and V8 into more than 800,000 lines of production Rust. Most of that code was produced with assistance from AI agents, distributed across 128 pull requests and continuously merged into the live codebase instead of being developed as one giant replacement branch.
The migration matters because the Copilot runtime has become much more than an implementation detail behind a command-line tool. It is evolving into an embeddable agent engine used across GitHub, Microsoft products, SDKs, and other applications.
That changed what the runtime needed to be.
And once that happened, the original architecture started becoming a constraint.
Copilot Was Outgrowing Its Original Runtime Architecture
The original runtime was built using TypeScript, Node.js, and V8. That was a sensible choice when rapid development and product iteration were the dominant requirements.
Node is extremely effective at exactly that kind of work.
But the architecture becomes more complicated when the same runtime needs to sit inside many different products.
The earlier Copilot SDK architecture generally involved an SDK starting a separate Copilot process and communicating with it using JSON-RPC over pipes or sockets. That architecture provided a convenient language-independent boundary, but every host application effectively inherited another runtime, another process lifecycle, another IPC boundary, and the associated memory and startup overhead.
Think about the difference.
The original model roughly looked like this:
Application → SDK → JSON-RPC → separate Node process → Copilot runtime
That is perfectly workable for a CLI.
It becomes less attractive when Copilot functionality needs to be embedded inside IDEs, desktop applications, services, productivity software, or systems running hundreds of agent sessions.
At that point, startup latency, memory consumption, process supervision, deployment complexity, and server density stop being implementation details.
They become product constraints.
The real architectural objective therefore wasn’t simply:
Rewrite TypeScript in Rust.
It was closer to:
Turn Copilot’s agent runtime into a small, predictable, native engine that can run almost anywhere.
That distinction explains many of the decisions that followed.
 |
Why Rust Was a Means, Not the Goal
One of the easiest conclusions to draw from the migration would be that GitHub decided Rust is categorically better than TypeScript.
That would miss the point.
GitHub framed the requirements around low startup overhead, predictable resource usage, native embedding, cross-language interoperability, reliability, and a more controlled dependency and security model.
The resulting Rust runtime exposes a C ABI that can be consumed through the native interoperability mechanisms of languages including C#, Python, Go, Java, TypeScript, and Rust itself.
This is an important architectural pattern.
Instead of maintaining six implementations of an agent runtime, GitHub can maintain one native engine while letting each programming ecosystem expose an idiomatic SDK.
The runtime becomes infrastructure.
The SDK becomes an interface.
That separation is arguably more consequential than the language itself.
Rust happens to fit this architecture well because it can produce native libraries with low runtime overhead while providing strong static checking and memory-safety guarantees across most ordinary application code.
But another subtle point from the project is worth emphasizing: the migration deliberately avoided immediately redesigning everything to be “Rust-native.”
The team generally translated behavior first.
Architectural optimization could come later.
That is exactly the opposite of how many ambitious rewrites fail.
The Smartest Decision Was Not Doing a Big-Bang Rewrite
Rewriting hundreds of thousands of lines behind a widely deployed developer product could easily have become a multi-year branch followed by a terrifying cutover.