What Bun's Rewrite from Zig to Rust Taught Me About AI and Software Engineering

A few days ago, I found out that Bun had been completely rewritten from Zig to Rust. At first, I thought it was just another programming language migration, but after reading Jarred Sumner's engineering blog on the rewrite, it completely changed the way I think about software rewrites and AI.

I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days..

Back in April 2021, Jarred wrote the very first line of Bun in Zig after discovering the language on Hacker News. Interestingly, Bun itself started as a line-by-line port of esbuild's JavaScript and TypeScript transpiler from Go to Zig before gradually evolving into something much bigger.

Today, Bun is no longer just a JavaScript runtime. It includes:

JavaScript runtime
Package manager
Bundler
Test runner
HTTP server
Node.js compatibility layer
And many other components

After more than five years of development, Bun has grown into a massive codebase.

That's why I was surprised when I heard they decided to rewrite it in Rust.

As a software engineer, rewriting a mature system is something I've always considered a last resort.

Years ago, I worked at GHTK, one of the largest logistics companies in Vietnam. During that time, many parts of the platform were already using outdated or deprecated technologies. Yet, nobody wanted to replace them — not because engineers didn't know better, but because the cost and risk of rewriting a production system were simply too high.

Building new features is expensive. Rewriting existing features that already work is even more expensive. That's why most companies continue maintaining legacy systems for years instead of starting over.

So naturally, my first question was: why would the Bun team decide to rewrite everything?

My first assumption was simple: "Rust must be significantly faster than Zig."

After reading the engineering blog, I realized that wasn't really the point.

The reported improvements—smaller binaries, lower memory usage, reduced stack usage, and a modest performance gain—are certainly nice. However, they weren't the primary motivation behind the rewrite.

Even Andrew Kelley, the creator of Zig, pointed out that some of these improvements could also be achieved through different compiler optimizations such as LTO (Link Time Optimization). I'm not interested in debating who is right or wrong here.

What caught my attention was something else entirely.

Looking through Bun's recent releases before the rewrite, I noticed many fixes related to memory management.

Jarred also wrote:

"We could have kept fixing these kinds of bugs one-off in perpetuity, but we owe it to our users counting on us to do better than that, and systematically prevent these kinds of bugs from recurring."

That sentence completely changed my perspective.

This wasn't about chasing benchmarks.

It was about reducing an entire class of bugs that consumed engineering time.

When your product becomes mature, developer productivity and reliability often become more valuable than squeezing out another few percentage points of performance.

It was AI.

The Bun team completed the migration in roughly 11 days, producing thousands of commits with the help of AI.

More importantly, they didn't simply ask an AI model to rewrite the project and hope everything would work, as is often the case with vibe coding. Instead,they built an agentic engineering workflow: multiple AI agents handled different responsibilities, and every change was compiled, tested, benchmarked, reviewed, and validated before being merged. Basically you can see image show below here, there will be 1 implementer, 2 or more adversarial reviewers per implementer. The reviewer's only job: find bugs & reasons why the code does not work. The implementer doesn't review. The reviewer doesn't implement.

That was the most interesting lesson for me. AI wasn't replacing engineers — it was becoming another engineer on the team if you know how to use it properly.

If someone had asked me a year ago how long a rewrite like Bun would take, I probably would have answered: a large engineering team, more than a year of work, and millions of dollars.

For years, software rewrites have been considered one of the riskiest decisions a company can make — not because engineers couldn't rewrite the code, but because the cost was simply too high.

AI doesn't eliminate that cost, but it dramatically changes the equation. If AI can generate code, explain unfamiliar codebases, review changes, migrate APIs, run tests, and help debug issues, then the cost of maintaining or modernizing large systems becomes much lower than it was just a few years ago. As Jarred wrote in his blog:

"Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would've taken 3 engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features"

That doesn't mean every company should start rewriting everything. It means some rewrites that were previously impossible may now become economically reasonable.

Another interesting observation is that the Bun team didn't redesign the product. They kept the same architecture, the same runtime design, and the same data structures — only the implementation language changed.

To me, that reinforces an important engineering lesson: architecture is often more valuable than the programming language itself. If your architecture is solid, changing implementation details becomes much less risky.

While reading more about Zig, I also learned that it is still in the 0.x stage. The language is evolving rapidly, and the Zig team intentionally does not guarantee backward compatibility before version 1.0. That allows the language to improve quickly, but it also means early adopters need to accept more breaking changes over time.

I also noticed that the Zig community has a much stronger preference for human-written code and documentation than AI-assisted development, and I found this on Zig Code of Conduct

Strict No LLM / No AI Policy

No LLM-generated content, whether it be code or prose.

No paraphrasing LLM-generated content.

No LLMs for editing, including fixing spelling or grammatical errors.

No LLMs for translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.

No LLMs for brainstorming and then sharing the results of that brainstorming, even if you create the prose. If you use a chatbot to give you advice on a comment on the issue tracker, that comment is unwelcome.

No LLMs for finding bugs.

No talking about use of chatbot/LLM services.

Whether that's good or bad is a matter of philosophy. Personally, I think AI will become an increasingly important part of modern software engineering. If a language and its ecosystem are difficult for AI to understand, navigate, or assist with, that may eventually influence engineering decisions — not because the language is bad, but because developer productivity increasingly includes collaboration with AI.

For me, Bun's rewrite wasn't really a story about Zig versus Rust. It wasn't even a story about AI writing code. It was a story about how AI is changing software engineering itself.

Five years ago, rewriting a mature codebase like Bun would have sounded almost impossible. Today, with the right engineering process, AI can significantly reduce the time, cost, and effort required to modernize large systems.

I believe we'll see more companies making decisions like this in the coming years — not because programming languages have changed, but because the economics of software engineering have changed.

If your team has a legacy system everyone's afraid to touch, it might be worth asking: is it still too risky to rewrite — or did that math just change? I'd love to hear how you're using AI in your own engineering workflow, so feel free to reach out and share your take.