This content was generated with the help of AI and published without prior human review. It may contain errors and is not professional advice. Report a problem: info@delionsoft.com.
GitHub has published an account of rewriting the Copilot agent runtime — the shared engine behind the Copilot CLI, app and SDK — from TypeScript on Node.js into Rust. According to the original report, the result is more than 800,000 lines of production Rust, landed through 128 pull requests into the main branch, with agents writing most of the code. The interesting part for the rest of us is less the language choice and more the migration method.
What happened
The runtime started as TypeScript, and the SDK ended up layered on top of the CLI rather than the other way around. Consumers created a client by spawning a CLI subprocess and talking to it over JSON-RPC. That meant every SDK user — C#, Python, Go, Java, Rust, TypeScript — shipped a second language runtime, paid roughly 100 MB of working set as a floor, pushed every event and file operation across a process boundary, lost the session if Node crashed, and had two processes to supervise.
The target was a library with no TUI inside it, embeddable in-process through a C ABI, with low startup cost and predictable memory. Rust was chosen for those reasons plus tooling and supply-chain posture; the authors are explicit that this is not a general recommendation to port large TypeScript codebases.
The migration was done in place, component by component, with atomic replacement: each pull request swapped a TypeScript implementation for a thin shim calling into Rust and deleted the old code in the same change. Main stayed shippable, existing end-to-end tests ran against the new code at every step, and failing required tests blocked the merge. They deliberately avoided keeping both implementations hot-swappable, because the subsystems that would benefit most from a cautious parallel cutover — session orchestration, for example — are the ones with shared mutable state and bidirectional callbacks, where two copies are hardest to maintain.
One detail worth noting: the initial scoping said about 130,000 lines of TypeScript. The author estimates roughly 430,000 production lines actually passed through the port, because code kept moving down from the TUI layer and other teams kept merging new TypeScript throughout.
Why it matters
The headline claims — a one- or two-year team project done mostly by one developer in a few months, performance improved by orders of magnitude — come from the team itself and should be read as such. But the structural lesson transfers to much smaller codebases: agent assistance changes what a rewrite costs, which means architectural debt you had written off as permanent may now be worth reopening. It also raises the value of the things that make such work safe, namely test coverage, reviewable diffs and clear module boundaries.
What to do
- Before considering any agent-assisted rewrite, check whether your end-to-end tests are good enough to act as a merge gate. Without that, incremental porting has no safety net.
- Prefer in-place, component-by-component replacement over a long-lived rewrite branch. Keeping the main branch shippable removes the worst failure mode of big-bang migrations.
- Split by layer before porting. Much of this effort was untangling a runtime from a UI; that work is useful even if you never change language.
- Scope by dependency graph, not line count. Components with shared mutable state will cost far more than their size suggests.