Imagine telling your boss you can migrate half a million lines of code in less than two weeks. They’d laugh you out of the room. Then Jarred Sumner did it. And he spent $165,000 in API fees to make it happen.
This isn’t a fairy tale. It’s a case study that should terrify and inspire every developer. Anthropic’s internal team used Claude Code to rewrite Bun from Zig to Rust — 530,000 lines, 100% test pass, merged in 11 days. Mike Krieger converted a Python project to 165,000 lines of TypeScript over a weekend. A weekend.
If you think AI code migration is about translating files one by one, you’re already behind. The real game is something else entirely.
Your job isn’t to modify code. It’s to design the process that produces code.
Traditional migration is a death march. Translate file A, check it, fix bugs, move to file B. With a thousand files, you’re doomed. The smartest teams don’t do that. They build a production line for code.
Here’s the six-step method Anthropic used — and how you can apply it today.
Step 0: Lock in a Verification Mechanism
Before you touch a single line, you need a way to know when you’re done. Bun had a full test suite written in TypeScript — independent of the source language. That’s ideal. But Mike Krieger had no tests. So he made Claude create a diff script that ran seven real scenarios and compared Python vs. TypeScript output. Any difference was a bug.
If you can’t measure correctness, you can’t migrate.
Step 1: Write a Rule Book — Not Code
Jarred spent three hours talking to Claude about how to map Zig idioms to Rust. The result? A 576-line rule document. He didn’t write a single translated line during that time. He wrote the rules for how translation should happen.
This is the most human-intensive part. You decide the architecture: keep the same structure (mechanical translation) or redesign (architectural shift). Jarred chose mechanical. Mike chose redesign. Both wrote rule books accordingly.
You also need a dependency graph. For Python, Claude can script one. Anthropic open-sourced a migration toolkit that includes it.
Step 2: Pilot on 3 Files — Then Throw Away the Output
Jarred ran three files through Claude, then had a second Claude instance act as a senior Rust engineer to review the same three files. A third Claude compared the two outputs and extracted new rules. He found two critical issues that would have been disasters across 1,448 files.
Mike ran the full migration three times — and discarded the first two results. Only kept the third. Wasteful? No. The goal of the pilot is to refine the process, not produce code. Discarding output is a feature, not a bug.
Step 3: Full Translation — But Not How You Think
Now the assembly line kicks in. Three roles: a Translator Agent, two Adversarial Reviewer Agents, and a Fixer Agent. The reviewers are told to assume the code is buggy. Their job is to find the flaws. The translator and reviewer work in completely separate conversations — no contamination.
Use cheaper models for heavy lifting (Claude Sonnet for translation) and premium models for review (Claude Opus). Mike used 12 Sonnet agents in parallel.
If the translator hits a doubt, it drops a // TODO(port): and moves on. Don’t stall. The compiler and tests will tell you later.
Steps 4–6: Compile, Smoke Test, Behavior Alignment
Same pattern every time: run the tool, collect errors into a list, send a battalion of Fixer Agents to fix them, repeat until green. Jarred used 64 parallel fix agents for the compile stage. Each fix was reviewed by two adversarial agents.
When he hit 16,000 compilation errors (due to circular dependencies after splitting into 100 modules), the agents handled it in hours. For a human, that’s months.
AI turns a mountain of bugs into a to-do list.
Bun’s CI went from 972 failing tests to all green in about four days. Nineteen regressions after merge — all fixed.
The Cost That Will Make You Think Twice
Sixteen and a half thousand dollars. That’s what Jarred spent on API calls. Sounds insane until you ask: what would three senior engineers cost for a year? Plus the opportunity cost of not shipping?
Suddenly, $165,000 is a bargain.
But here’s the catch: human judgment remains irreplaceable. Jarred monitored every workflow output, manually checked AI behavior, and adjusted the process when systematic issues surfaced. The AI is the laborer, but you’re the architect.
What You Can Do Right Now
- Before any large refactor, negotiate a rule document with your AI. Define the ‘how’ before you start.
- Pilot on 3 files. Fix the rules, not the output.
- Separate the writer from the reviewer. Use
/code-reviewin Claude Code or a fresh conversation. - Treat every error list as a task queue. Let AI work through it systematically.
If AI can migrate 530,000 lines in 11 days, your 10,000-line project is trivial. The only question is whether you’re willing to stop writing code and start designing processes.
Most people think the bottleneck is AI capability. It’s not. It’s the quality of your process design. The tools are ready. Are you?
FAQ
Q: Isn't $165,000 way too expensive for a code migration?
A: Compare it to the cost of three senior engineers working full-time for a year — easily over $500,000. The API fee is a fraction of that, and the migration happened in 11 days instead of 12+ months. For most companies, it's a massive net savings.
Q: What's the practical takeaway for a solo developer with a small project?
A: You don't need $165k. A few thousand lines of code can be migrated using a Claude Pro subscription. The key is the process: write a rule document first, pilot on a few files, separate writing and reviewing, and treat errors as a checklist. The same principles scale down.
Q: But doesn't this mean developers will be replaced by AI?
A: No. It means the role shifts from writing code to designing the process that produces code. Human judgment, monitoring, and rule-setting are still critical. The developers who learn to orchestrate AI will be more valuable than those who only write code. This is augmentation, not replacement.