Anthropic's Six-Step Code Migration Playbook: Moving Bun's Million Lines from Zig to Rust in Two Weeks
- Rewriting a production codebase in a new language typically costs about four years, $3–4 million, and often stalls halfway. Anthropic's team migrated 10 code packages in the past month; the Bun migration alone moved a million lines in under two weeks, with the original test suite fully green before the merge.
- The core principle is simple: don't fix the code, fix the loop that produces it. When the same mistake appears across dozens of files, the right move is to add a rule to the rulebook and rerun the whole batch — not to patch files one by one.
- Before you start, you need a judge. Turn the existing tests that can run on both the old and new code into assertions, then validate the judge by running it against deliberately broken code. A judge that can't catch bad code isn't a judge — without it, you have no way to define "done."
- The engineering details are copy-paste ready: the work queue rebuilds from disk each time so it can resume after interruptions; implementation uses a smaller model, review uses a larger one; two independent review contexts that escalate to a third Agent when they clash; and anything you can't port gets a
// TODO(port)marker for later. - There's a clear ledger of costs and benefits: the Bun project consumed 5.9 billion uncached input tokens and 690 million output tokens, roughly $165,000 at API prices. Mike Krieger's project saw compilation drop from 8 minutes to about 2 seconds after the move, startup got 6x faster, and an entire deployment pipeline was retired.
Ten code packages in one month
A million lines of code, a new language, two weeks to migrate, and the full existing test suite passed in CI before the merge.
This is a practical walkthrough from Anthropic's official ClaudeDevs account, detailing how they've spent the past month using Claude Code for code migration — moving a production codebase to an entirely new language. The methodology, along with its templates, is laid out openly for anyone to copy, running on Claude Fable 5, Claude Opus 4.8, and Claude Code's dynamic workflows.
Over the past month, Anthropic's developers have migrated 10 code packages, ranging from tens of thousands to hundreds of thousands of lines. Only two are detailed in the post.
Jarred Sumner—Bun's co-founder, now on Anthropic's technical staff—led the Bun migration. Mike Krieger, Instagram's co-founder and now co-head of Anthropic Labs, handled the Python side.
Why nobody dared before
Jarred chose Zig back in the day because it could match C-level performance while staying simple enough — in his words — for one person in a small Oakland apartment, without the help of large models, to write Bun in a year. That simplicity came at a cost that's been compounding. Bun's CLI now gets over ten million downloads a month, and Claude Code itself relies on it heavily.
Until last quarter, those costs didn't justify freezing the roadmap and betting resources on a multi-quarter project.
- 4-year timeline, $3–4M in engineering resources
- Feature freeze during migration
- Maintaining two codebases in parallel for quarters or even years
- Worst case: you get 90% of the way there and end up in a messier state than when you started
- Tens to hundreds of thousands of dollars — still real money
- Worst case: delete the branch and try again
- You no longer need "we can't survive without this" to justify starting
- A memory bug patch sitting in the changelog for a year, or a long-standing bottleneck, is enough
Mike's project was driven by exactly that kind of bottleneck. His team's internal tool had to be packaged as a single executable for users, and the Python toolchain took about eight minutes to compile for each platform. Running the whole build matrix meant waiting thirty minutes for every release. After the move to TypeScript, the same compilation took about two seconds, the executable started 6x faster, and the team retired an entire separate deployment pipeline.
Same error repeated? Fix the rule
The most valuable line in the entire post is this:
The core insight is that you don't fix the code. You fix the process (loop) that produced the code.The key insight: don't fix the code; fix the loop that produces it. · ClaudeDevs
In practice: when a review agent spots the same mistake across dozens of files, don't reach for those files. You add a line to the rulebook and regenerate the affected batch. The rulebook thickens as the process continues; code is never hand-patched to comply.