Large programming-language migrations used to be the kind of project engineering teams postponed for years. They were expensive, disruptive,...
Large programming-language migrations used to be the kind of project engineering teams postponed for years. They were expensive, disruptive, and risky. A company could spend several quarters maintaining two implementations and still end up with a replacement that behaved differently from the original.
Claude Code is beginning to change that calculation.
Anthropic recently published the process it uses for large-scale code migrations with AI agents. The most striking example is Bun creator Jarred Sumner’s migration of Bun’s core from Zig to Rust. In less than two weeks, Claude Code workflows generated more than one million lines of code, while Bun’s existing test suite passed in continuous integration before the merge.
The project was not completed by asking a model to “rewrite Bun in Rust” and waiting for a perfect answer. It relied on a carefully designed system of rulebooks, dependency maps, mechanical queues, adversarial reviewers, compilers, smoke tests, and behavior-parity checks.
The central lesson is straightforward: for a migration this large, the developer should not spend most of their time repairing individual files. They should improve the process that generates, reviews, and verifies those files.
Jarred Sumner originally built Bun in Zig. The language gave a solo developer low-level control and C-like performance without the full complexity of a larger systems-language ecosystem.
That choice helped Bun move quickly in its early years. Sumner has said that he wrote the first version in roughly one year from a small apartment in Oakland, before modern coding models were available.
By 2026, Bun had become a widely used JavaScript and TypeScript runtime, package manager, test runner, and bundler. Its command-line tool was receiving tens of millions of monthly downloads, and products including Claude Code depended heavily on Bun.
Growth also made old engineering trade-offs harder to ignore.
Bun combines a garbage-collected JavaScript engine with manually managed native memory. In Zig, developers must explicitly reason about allocation, cleanup, error paths, and object lifetimes. Bun’s team had invested heavily in sanitizers, fuzzing, safety-checked builds, and memory-leak tests, but use-after-free errors, double frees, leaks, and lifetime mistakes still appeared.
Rust offered a different foundation. Its ownership system, borrow checker, and automatic cleanup could turn many runtime memory problems into compile-time errors.
Historically, that benefit would not have justified a complete rewrite. Bun contained hundreds of thousands of lines of Zig, plus extensive native integrations. A traditional rewrite could have consumed a small engineering team for a year or more while slowing feature work and security fixes.
Claude Code made a full mechanical migration appear possible.
Sumner used a prerelease version of Claude Fable 5 and Claude Code dynamic workflows to carry out the migration.
The main writing and review process ran continuously for 11 days. Around 50 dynamic workflows handled different stages, including:
.zig files into .rs filesAt peak throughput, the workflows produced roughly 1,300 lines of code per minute. Each generated unit was checked by two independent adversarial reviewers before a fixer applied confirmed changes.
The final pull request added more than one million lines across over 2,000 changed files.
Before the merge, Bun’s existing test suite passed in CI. Nineteen regressions appeared afterward, and Anthropic reported that all of them were subsequently fixed. The Rust port had already shipped inside Claude Code in June 2026.
This result was not proof that the first million generated lines were correct. Sumner explicitly noted that the earliest translated output did not work. The successful part was the feedback system that gradually turned non-working output into compiled, tested, behavior-compatible code.
The Bun migration consumed approximately:
That is a substantial amount of money. It is also far below the cost of a traditional multi-year migration involving several full-time engineers.
Anthropic estimated that million-line migrations previously could cost roughly $3 million to $4 million in engineering resources over four years. AI changes the business case because the migration no longer needs to solve an existential problem to justify the expense.
A persistent memory bug, an aging language ecosystem, an expensive build process, or a recurring maintenance bottleneck may now be enough to make a migration worth evaluating.
The comparison should still be made carefully. Token cost is not the entire project cost. Teams also need human planning, infrastructure, testing, code review, security work, and post-merge maintenance.
The migration was motivated primarily by reliability rather than raw speed.
Bun already performed well in Zig. The problem was the burden of safely coordinating manually managed native memory with a garbage-collected JavaScript runtime.
Common failure categories included:
In safe Rust, many of these mistakes cannot compile. Values have explicit ownership, cleanup is tied to object lifetime, and the compiler checks references before the program runs.
The migration aimed to preserve Bun’s existing architecture, data structures, behavior, and performance. It was intentionally closer to a mechanical port than a complete redesign.
That decision was important. Redesigning the system and changing the language at the same time would have made behavior comparison much harder.
Jarred Sumner was not the only Anthropic engineer using Claude Code for a major migration.
Mike Krieger, co-lead of Anthropic Labs and a co-founder of Instagram, migrated an internal Python codebase into approximately 165,000 lines of TypeScript over one weekend.
The main migration consumed around 27 million tokens and involved:
The original tool needed to be delivered as a single binary. With the Python toolchain, compilation took about eight minutes per platform, and the complete build matrix delayed each release by around 30 minutes.
After the TypeScript migration:
Krieger did not rely on an existing comprehensive cross-language test suite. Instead, Claude created a parity harness covering seven real-world scenarios, then compared the output of the old and new implementations.
Claude also designed additional end-to-end tests and ran them overnight for four consecutive nights, fixing failures and repeating the process. This uncovered small behavioral differences that the original scenarios had not anticipated.
Large migrations look intimidating to people because they involve huge numbers of repetitive changes. Those same characteristics can make them suitable for agent workflows.
A large repository can often be divided into files, packages, crates, modules, or dependency groups. Separate agents can process independent units at the same time.
The dependency map determines which units can move in parallel and which must wait.
The original implementation already contains the required behavior, edge cases, data structures, and integration details.
The model does not need to invent the product. Its job is to preserve the existing system in a new language or framework.
Agents work better when they can evaluate their output mechanically.
A compiler, test suite, output diff, benchmark, or parity harness gives the system a concrete signal. The agent can continue working against that signal without requiring a human to judge every intermediate attempt.
A compiler error becomes the next task. A failed test becomes the next task. A crash becomes the next task.
This turns a large migration into a queue that can be repeatedly reduced.
When reviewers find the same problem in many files, the best solution is not to patch each file manually.
The rulebook should be updated, and the affected batch should be regenerated. This prevents the same error from returning in later work.
The most important idea in Anthropic’s process is to treat generated code as the output of a system.
Suppose 200 translated files contain the same ownership mistake. Manually repairing those files may solve the visible errors, but the workflow can produce the same mistake again.
A stronger approach is:
The code improves because the production process improves.
This resembles ordinary software engineering. A recurring production bug should lead to a better test, type rule, static check, or process—not just another isolated patch.
Before beginning a large migration, define how the team will prove that the new implementation is correct.
Without a judge, there is no reliable completion condition.
The judge must evaluate the original and target implementations on equivalent terms. Existing tests may depend on private functions or language-specific internals that disappear during the port.
Anthropic recommends three preparation tasks:
A test suite that cannot detect known breakage is not a useful migration judge.
Bun had a major advantage: much of its test suite was written in TypeScript rather than Zig, so the same suite could test the Rust implementation.
For projects without this advantage, a parity harness can compare real inputs and outputs between the two versions.
Anthropic generalized the lessons from these projects into a six-step process.
The first stage creates the shared documents every later agent will follow.
The rulebook defines how concepts in the source language map to the target language.
For a structure-preserving migration, it may contain:
For a redesign, the rulebook becomes closer to an architecture document.
Jarred Sumner developed Bun’s porting guide through conversations with Claude and human review. The final artifact was hundreds of lines long.
The repository must be divided in an order that respects dependencies.
A deterministic script can inspect imports, manifests, build files, and symbol relationships to produce the map. The result helps the orchestrator decide which files can be translated independently and which should be processed together.
The source and target languages do not enforce the same rules.
For Zig to Rust, memory ownership was a major gap. For Python to TypeScript, implicit object shapes and interfaces had to become explicit contracts.
The gap inventory records places where simple translation is insufficient.
It should identify:
The rulebook should be created before the gap inventory, because the inventory is partly defined by what the normal rules cannot handle.
Do not immediately translate thousands of files.
Run a small, disposable pilot on a few difficult and representative files. The purpose is to expose weaknesses in the rules before those weaknesses spread across the repository.
In Bun’s pilot:
The output of this stage is a better rulebook—not production code.
For a redesign migration, the equivalent test is to attack the design document with adversarial reviewers, then perform a disposable end-to-end run.
Once the rules survive the pilot, the repository can be processed through a parallel queue.
A typical unit uses:
Describe your idea once, and We0 AI can generate a showcase site, pages, and CMS, then help you attract customers and traffic after launch.
One complete project generation for free registration
Best for trying one complete generation flow and seeing a first project draft quickly.
The queue should be resumable. A script should be able to determine which work is complete by checking files or recorded artifacts rather than depending on one agent’s memory.
Agents should flag unresolved work consistently, for example:
TODO(port): explain why this section could not be translated safely
Do not use the most expensive model for every unit. Smaller capable models can handle high-volume translation, while stronger models are reserved for reviewers, architectural choices, and rule changes.
The first full build turns compiler errors into a structured work queue.
Depending on build cost, the compiler may run inside each agent loop or through a separate orchestrator.
For Bun, compiling the whole workspace was expensive, so Claude agents did not run cargo freely during file translation. Instead:
This prevents dozens of agents from launching the same expensive build at the same time.
Systemic compiler errors should update the rules. For example, a target language may reject cyclic dependencies that the source compiler tolerated lazily. That is a process-level issue, not merely a list of unrelated file errors.
A successful compile only proves that the target language accepts the code.
The next stage uses basic execution and smoke tests to find crashes, initialization failures, missing resources, invalid assumptions, and broken integrations.
Failures should again be grouped by cause.
If 40 smoke tests fail because of one incorrect initialization pattern, fix the migration rule and regenerate the affected code rather than assigning 40 isolated patches.
The final gate is behavioral parity.
Run the portable test suite, parity harness, output comparisons, and relevant benchmarks against both codebases.
For each failure:
The original codebase remains the ground truth unless the project explicitly intends to change behavior.
A missing test suite does not make this step optional. Teams can use Claude to create an external parity harness from real scenarios and then validate that harness against deliberately broken behavior.
Anthropic released a public starter kit containing generalized prompts, templates, and scripts based on the migration process.
The repository is reference material rather than a fully managed migration product. Its prompts are reconstructed templates, not exact transcripts from the Bun project.
On macOS or Linux:
curl -fsSL https://claude.ai/install.sh | bash
On Windows PowerShell:
irm https://claude.ai/install.ps1 | iex
Review remote installation scripts and your organization’s security policies before running them.
From the repository you want to migrate:
git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit
This optional step copies the migration skill into the local Claude Code skills directory:
cp -r migration-kit/skill ~/.claude/skills/code-migration
Update the kit path inside the installed SKILL.md as described in the repository.
Start with the kit’s read-only feasibility prompt:
prompts/00-feasibility.md
The result should answer three questions:
“Do not migrate” is a valid result.
Before translation fan-out:
Then run the migration prompts in order rather than skipping directly to mass translation.
The Bun migration was not smooth from the first run.
When many agents began working in one repository, their Git operations interfered with each other. One agent ran git stash, another used git stash pop, and another reset the working tree.
Sumner changed the workflow so agents could not freely run destructive Git commands. He later divided the work into four workflow shards with separate worktrees, each coordinating multiple agents.
This example highlights a critical point: agent permissions must match the workflow design.
A coding agent with broad shell access can:
The orchestration layer must restrict commands, define file ownership, serialize expensive operations, and make recovery simple.
Anthropic’s published lessons can be reduced to several practical rules.
Every codebase has different build systems, test coverage, runtime behavior, deployment constraints, and risk tolerance.
Use the six-step framework as a starting point, then ask Claude to adapt it to the actual repository.
Fixer agents can process individual failures. Human attention is more valuable when it identifies repeated patterns, missing rules, unsafe assumptions, and architectural problems.
The implementing agent should not be its own only reviewer.
Give reviewers separate context and tell them to assume the generated code is wrong. Their job is to find reasons it fails, drifts, or violates the rulebook.
Use compilers, tests, linters, output diffs, benchmarks, and deterministic scripts as judges.
A subjective “looks correct” review cannot safely validate a million-line change.
High-volume translation can be assigned to smaller or cheaper models. The strongest models should handle rule creation, architecture, ambiguous failures, and review.
The highest-value human work happens before mass generation:
Once those foundations are reliable, much of the remaining work becomes a mechanical queue.
A migration that runs for days must survive crashes, restarts, model failures, and infrastructure interruptions.
Completion should be derived from durable artifacts on disk, commits, test records, and queue state—not from one long conversation.
Anthropic reports that Bun’s Rust-based code is now running in production.
The migration did not eliminate every trade-off. Roughly 4% of the Rust code remained inside unsafe blocks, mainly for small pointer operations at C and C++ boundaries.
However, the new implementation produced measurable improvements:
These results show why the migration mattered. The goal was not to produce a large amount of AI-written code. It was to produce a system that was safer, smaller, and easier to maintain while preserving behavior.
A large migration may be suitable for an agent workflow when:
It may be a poor fit when:
The ability to generate a million lines quickly does not make a migration automatically sensible.
Yes. Jarred Sumner used Claude Code dynamic workflows and a prerelease Claude model to migrate Bun’s core from Zig to Rust. The process generated more than one million lines of code in less than two weeks, followed by compilation, testing, review, and post-merge fixes.
Anthropic reported approximately 5.9 billion uncached input tokens and 690 million output tokens. At API pricing, the estimated model cost was about $165,000, excluding human labor and infrastructure.
Anthropic says Bun’s existing test suite passed in CI before the merge. Nineteen regressions were found afterward, and all were later fixed.
The main goal was to improve memory safety and reduce recurring lifetime, cleanup, use-after-free, double-free, and leak problems. Rust’s ownership and type systems can catch many of these issues during compilation.
No. Successful migrations require a strong judge, explicit rules, dependency analysis, controlled permissions, repeatable queues, adversarial review, and human oversight. Some projects should not be migrated at all.
An adversarial reviewer receives the generated change in a separate context and is instructed to find defects rather than approve it. The implementer and reviewer have different roles, which reduces the risk of the author simply defending its own output.
A strong existing suite is ideal, especially when it tests public behavior independently of the implementation language. When that is not available, teams can build a parity harness that compares real scenarios and outputs between the old and new systems.
No. Anthropic describes the repository as a generalized and reconstructed starter kit. The actual Bun migration used more specific artifacts, including a long project rulebook and custom dynamic workflows.
Claude Code did not make Bun’s migration successful by generating a perfect million-line rewrite in one attempt. The project worked because the team built a disciplined production system around the model: a rulebook, dependency map, gap inventory, pilot, parallel translation queue, adversarial review, compiler loop, smoke tests, and behavior-parity checks.
The same approach helped Anthropic migrate a large Python codebase to TypeScript over a weekend. In both cases, objective verification was more important than raw generation speed.
AI can significantly reduce the cost and duration of large migrations, but only when the process is resumable, permissions are controlled, and repeated defects improve the rules that generated the code.
The real breakthrough is not that AI can write one million lines—it is that a well-designed loop can repeatedly generate, challenge, test, and correct those lines until the new system behaves like the old one.
Start from one sentence and have a complete website in minutes.
