In nine days, an AI system ported over one million lines of production code from one systems programming language to another — and passed 99.8% of the test suite. That is not a hypothetical benchmark. That is what happened when Anthropic's Claude Code rewrote Bun, the JavaScript runtime, from Zig to Rust.
The story broke on Hacker News over the weekend with 528 points, and it is still the most-discussed AI story in the developer community. Simon Willison covered it. Bun's own creator, Jarred Sumner, weighed in with a warning: "high chance all this code gets thrown out." The codebase now contains over 13,000 unsafe Rust blocks.
This is a landmark moment for AI-assisted software engineering — but not necessarily in the way the headline numbers suggest. Let me walk you through what actually happened, the quality arguments, and what it means for the future of code migration.
The Claude Code Rust Rewrite: What Actually Happened Over 9 Days
Bun, created by Jarred Sumner, is a fast all-in-one JavaScript runtime written in Zig — a low-level programming language designed for speed and safety. Claude Code, Anthropic's autonomous coding agent, was tasked with converting Bun's entire codebase from Zig to Rust.
The numbers are staggering on the surface:
- 1,009,257 lines of Zig code ported to Rust
- 9 days of continuous AI-driven work
- 99.8% test pass rate immediately after conversion
- 13,000+ unsafe Rust blocks in the resulting code
Claude Code itself now runs on this very Bun runtime written in Rust — a circular dependency that makes the story even more interesting. The AI that rewrote the runtime is running on the rewritten runtime.
How This Claude Code Rust Rewrite Worked at Scale
Claude Code is Anthropic's agentic coding tool — it can browse codebases, plan changes, write code, run tests, and fix failures autonomously. For the Bun port, it processed the entire Zig codebase section by section, converting each module to equivalent Rust while maintaining the same API surface.
The Iterative Conversion Process
The AI did not dump a billion lines overnight. It worked module by module: read the Zig source, understand the logic, generate Rust equivalent, compile, fix errors, run tests, fix failures, repeat. This is the same workflow a human developer would use — just compressed into nine days without sleep.
Why Zig to Rust Made Sense for This Experiment
Both Zig and Rust are systems programming languages targeting similar use cases. Zig prioritises simplicity and explicit control flow. Rust brings a borrow checker, memory safety guarantees, and a significantly larger ecosystem. Converting from Zig to Rust is not a language family jump — it is a controlled migration between two close cousins in the systems programming world.
99.8% Test Pass Rate: Impressive or Misleading?
A 99.8% pass rate sounds almost perfect. But the developer community has pushed back hard on treating this number as proof of production readiness.
Here is why the 99.8% figure needs context:
- Tests reflect known behaviour. The test suite was written for the Zig implementation. Passing the same tests means the Rust version reproduces the same outputs — but tests cannot cover every edge case, especially subtle concurrency bugs or memory issues that Rust's borrow checker would normally catch.
- Unsafe Rust bypasses safety guarantees. The whole point of rewriting in Rust is memory safety. With 13,000+ unsafe blocks, much of that safety is explicitly opted out of.
- Test coverage matters. We do not know the coverage percentage of Bun's test suite. If tests cover 60% of the codebase, a 99.8% pass rate covers only 59.8% of the code.
- Performance is unverified. The test pass rate does not measure whether the Rust version matches the Zig version's speed. In systems software, performance regressions can be as critical as correctness bugs.
The 13,000 Unsafe Rust Blocks: Quality Concerns in the Claude Code Rewrite
This is the most debated aspect of the story. Rust's unsafe keyword allows operations the borrow checker cannot verify — raw pointer dereferencing, calling foreign functions, and implementing certain low-level patterns. Production Rust code typically minimises unsafe usage.
Thirteen thousand unsafe blocks is an enormous number for any codebase. By comparison, the Linux kernel's Rust-for-Linux initiative uses roughly 1,000 unsafe blocks across hundreds of thousands of lines. The Bun Rust port has 13x more.
Why So Many Unsafe Blocks?
Zig is built around explicit memory management — it does not have a borrow checker. When Claude Code converted Zig's direct memory manipulation patterns to Rust, it naturally produced unsafe blocks because Rust's safe type system cannot express many of the operations Zig handles natively. The AI translated semantics, not idioms. A human Rust developer would likely restructure the architecture to minimise unsafe usage, but Claude Code preserved the Zig-style approach.
Does Unsafe Mean Low Quality?
Not necessarily. Unsafe Rust is still Rust — important safety properties like thread safety, lifetime management, and type correctness outside unsafe blocks remain intact. The unsafe boundary is what matters: is each unsafe block small, well-documented, and auditable? Or are they scattered everywhere without clear justification? The community is still debating this about the Bun port.
Bun's Creator's Warning: "This Code Might Get Thrown Out"
Jarred Sumner, Bun's creator, publicly stated that the Claude Code-generated Rust code "might get thrown out." This is not an indictment of Claude Code — it is a realistic assessment of how AI-generated production code should be evaluated.
Sumner's reasoning is rooted in maintainability. Code that no developer on the team fully understands becomes a liability. If a bug surfaces in the Rust port six months from now, who fixes it? Claude Code produced the code, but it cannot support it post-deployment. The team would need to reverse-engineer AI-generated Rust to fix production issues.
What the Claude Code Rust Rewrite Teaches Us About AI Migration
Regardless of whether Bun keeps the Rust port, this experiment reveals several truths about AI-assisted code migration that apply to every engineering team:
- Speed is real. Nine days for 1M lines is transformative. Any migration that would take a team of humans 6–18 months can now be attempted in weeks.
- Quality is the bottleneck. Getting a high test pass rate is the easy part. Achieving idiomatic, maintainable, auditable code is the hard part — and AI is not there yet.
- Unsafe boundaries need human review. AI will produce safe-ish code, but it will not make architectural trade-offs the way an experienced human would.
- Test coverage determines real quality. The 99.8% number only means as much as the test suite covers. Teams need to invest in coverage before attempting AI migration.
- Post-migration support is unsolved. Who owns the AI-generated code after it ships? This organisational question is harder than the technical one.
Is AI Code Production-Ready? The Developer Community's Divide
The Hacker News thread reveals a developer community split roughly into three camps:
- The Optimists: "This is exactly how we should use AI — brute-force translation of working code with human review on top. The 99.8% pass rate proves the approach works."
- The Sceptics: "13,000 unsafe blocks is not a port — it is a liability. A human Rust developer would restructure fundamentally. This code is not production-ready."
- The Realists: "Use the AI port as a first draft. Treat it like a junior developer who worked very fast. Then invest the real engineering effort in cleaning it up. The time savings are still enormous."
My take aligns with the realists. The Bun Rust rewrite is neither a triumphant victory nor a cautionary disaster — it is a signpost. AI can now do the grunt work of code migration at a scale that was previously impossible. But the grunt work was never where the value was. The value is in architecture, trade-offs, maintainability, and safety. Those remain firmly in human hands for now.
FAQ: Key Questions About the Claude Code Bun Rust Rewrite
How long did Claude Code take to rewrite Bun in Rust?
Nine days of continuous AI-driven work to port 1,009,257 lines from Zig to Rust.
Is the Bun Rust rewrite production ready?
Bun's creator himself said "high chance all this code gets thrown out." The 99.8% test pass rate is impressive, but the 13,000+ unsafe blocks and unknown performance characteristics mean production readiness is not confirmed.
How many unsafe Rust blocks are in the ported code?
Over 13,000 unsafe blocks were detected in the Claude Code-generated Rust port. This is roughly 13x more than the entire Rust-for-Linux initiative.
Can Claude Code rewrite entire codebases?
Yes — this experiment proves Claude Code can port a 1M+ line production codebase between systems programming languages. However, the quality ceiling remains a concern that requires human oversight.
Should you use Claude Code for code migration?
For exploratory migrations, prototyping, or first-draft translations: yes. The speed is unmatched. For production-ready migration artifacts intended for long-term maintenance: treat the output as a starting point, not a finish line.
Conclusion: The Dawn of AI-Accelerated Rewrites
The Claude Code Bun Rust rewrite is a preview of how software engineering will look in the next 2–3 years. AI will handle the mechanical translation. Humans will handle the architecture, safety boundaries, and long-term maintainability. The teams that figure out this division of labour first will have a massive productivity advantage.
But do not mistake speed for quality. A rewrite that takes nine days and passes 99.8% of tests is still a first draft. The real engineering starts after the AI finishes.
What is your take? Would you trust Claude Code to port your production codebase to a new language? Drop a comment below — I read every response.