Rewrites Are Now a Business Case

[!abstract] In one sentence Big migrations used to be multi-year projects that froze the roadmap and rarely paid back. With agents, a rewrite costs tokens and a strong test suite rather than engineer-years. That turns “we should really rewrite X” from a wish into a business initiative you can price and propose.

This started with a run of recent ForrestKnight videos on Rust adoption, and with Bun’s move from Zig to Rust. The language question is interesting. The economics are what changed.

The old maths of a rewrite

• Expensive: a big rewrite took years of senior engineers’ time.
• Roadmap freeze: features and bug fixes stop, or the team maintains two systems at once.
• Moving target: the old system keeps changing while you port it, so the finish line drifts.
• Payback rarely arrives: by the time the migration is done, the team is exhausted, the business case is stale, and the benefits (speed, safety, cost) have to be earned again by people who’ve just spent two years on plumbing.

So the standard advice was “never rewrite; strangle it gradually” (Strangler Fig Migration). It was good advice under the old maths.

What changed: Bun, Zig → Rust

Anthropic acquired Bun in December 2025. During 2026 Bun’s creator, Jarred Sumner, ported the whole runtime from Zig to Rust:

Size	~535k lines of Zig → 1M+ lines of Rust
Time	~4 months, vs an estimate of ~1 year for three engineers with full context
How	A mechanical port, file by file. Up to 64 parallel Claude agents. Implementer and reviewer agents kept separate. A porting guide mapped Zig patterns to Rust, and a table recorded every struct field’s lifetime
Oracle	The existing TypeScript test suite, with 1M+ assertions
Cost	Billions of tokens ≈ $165k at API prices
Outcome	Shipped as Bun 1.4 (Aug 2026). 128 long-standing bugs closed. Memory on a repeated-build test plateaued at ~0.6 GB instead of climbing past 6.7 GB. HTTP throughput up a few per cent. A smaller binary
Cost of speed	19 subtle semantic regressions from the mechanical translation. Lots of unsafe left to refactor out later. Fixes came from rounds of security review and parser fuzzing

Sumner on why the move worked: “Compiler errors are a better feedback loop than a style guide.” And on how the agents were split: “The implementer doesn’t review. The reviewer doesn’t implement.”

$165k of tokens is less than one senior engineer’s fully loaded cost for a year. It replaced roughly three engineer-years, without freezing the roadmap for a year. That’s the shift.

Tokens are now the cost

• It’s still a lot of tokens. Bun’s port used billions. Budget it like compute, not like a seat licence.
• The cost is falling:
  • Cached reads made up most of Bun’s tokens and are much cheaper.
  • Some companies have negotiated very large or flat-rate token allowances with model providers.
  • Local or open models can take the bulk mechanical work (file-by-file translation, test fixing), with frontier models kept for planning and review.
• A caveat to keep honest: local models aren’t yet doing million-line ports unaided. The realistic split today is frontier models for planning and review, and cheaper models for volume.

Why Rust?

1. Memory safety without a garbage collector. Use-after-free, double-free and leaks in error paths were the bugs Bun kept hitting. The borrow checker and Drop remove most of those classes of bug, not just instances of them.
2. Predictable performance. No GC pauses, a low memory footprint and small binaries. That matters for latency-sensitive systems (trading, gateways, real-time) and directly cuts cloud bills.
3. The compiler is the agent’s best reviewer. A strict type system and borrow checker turn many AI mistakes into compile errors instead of production incidents. With agents, a language that refuses to compile wrong code is worth more than it used to be.
4. The ecosystem is proven. The JS and Python toolchains have already moved: SWC, Turbopack, Rolldown/Rspack, Biome, Ruff, uv.
5. It’s the safe-language answer for C and C++. Security agencies and large vendors push memory-safe languages because memory-safety bugs are a large share of serious CVEs.

What makes sense to rewrite in Rust

Good candidates:

• Hot paths: API gateways, proxies, parsers, serialisers, market-data and feed handlers, matching or pricing engines, where latency, throughput or memory is the product.
• Memory-unsafe C/C++ components: native extensions, codecs, network daemons. Rust gives you safety you can’t add to C by policy.
• Expensive compute services, where CPU and memory translate straight into the cloud bill.
• Developer tooling and CLIs: build tools, linters, bundlers. Speed compounds across every engineer and every CI run.
• Code shared via WASM, where one Rust core runs in the browser, on the server and on the edge. Benchmark first, though: Rust and WebAssembly: Benchmark Before You Bet.

Poor candidates:

• IO-bound CRUD services, where the database is the bottleneck and the language barely matters.
• UI and fast-changing product code, where iteration speed beats runtime speed.
• Anything without a test suite. No oracle means no safe port; see below.
• Teams with nobody who can review Rust. Someone still has to own the result.

The precondition: tests are the oracle

Bun worked because a 1M-assertion test suite said “same behaviour” or “not the same”. Zig’s creator, Andrew Kelley, made a fair criticism: if the tests weren’t enough to keep the Zig code correct, why trust them to certify a million lines of unreviewed Rust?

The lesson for any large codebase: most of the migration budget is now spent before the port starts.

1. Lock behaviour first. Write characterisation tests, golden files and contract tests at the boundary (Brownfield Agentic Engineering). Record and replay production traffic where you can.
2. Write the porting guide. Map patterns, types and ownership in one document. That’s the agents’ style guide.
3. Port mechanically, then make it idiomatic. Get to green first (even with unsafe or awkward code), ship, then refactor in the new language.
4. Separate implementation from review. Use adversarial reviewer agents in clean contexts, then fuzzing and security review.
5. Prove it at the boundary. Run old and new side by side (shadow traffic, Blue-Green Deployment) before cutting over.

The bigger principle: propose migrations as business initiatives

The point isn’t really Rust. Migrations that were obviously valuable but never fundable are now worth re-pricing:

• Java 8 → 21, Python 2-era code, AngularJS and CRA front ends (Migrating from CRA to Vite)
• monolith → services, one cloud → another, one database → another
• C/C++ → Rust, Zig → Rust, JS → TS

How I’d pitch one:

• Cost: a token budget plus a small team running the agents, measured in weeks. Not a two-year programme.
• Benefit: the hard number the rewrite moves, e.g. infra cost, p99 latency, incident or CVE rate, or lead time (DORA Metrics).
• Risk control: tests first as a funded phase, a shadow run, a reversible cutover, and a time-boxed spike (Bun started as a one-week experiment).
• What doesn’t stop: the roadmap keeps going, which is the thing the old maths could never promise.

The question used to be “can we afford to rewrite it?” Now it’s “can we prove the rewrite behaves the same?” That is a testing problem, and you can fund it.

Sources

• InfoQ: Bun rewrites 535K lines of Zig into Rust in four months
• The Register: Anthropic’s Bun Rust rewrite merged at speed of AI
• Morello: Bun Rust rewrite, 64 Claude agents