Bun's Rust Rewrite Shipped. Nobody Read the Full Diff.

Bun 1.4 shipped last week. The headline feature isn't a new API. It's that the entire runtime — close to a million lines — got rewritten from Zig to Rust in six days, and no single human read the whole diff before it merged.

Anthropic owns Bun now, remember. It bought the company in December to make Claude Code's runtime faster. So when I say "AI agents rewrote it," I mean Claude Code, fanned out across hundreds of agents working the migration in parallel, with two bots — claude[bot] and coderabbitai[bot] — doing the review.

I run Bun in production. My site's bun.lockb has been sitting in the repo for over a year. This isn't a story I read about from a distance. It's a runtime I depend on, that just got replaced underneath me by something no single person fully inspected before it shipped.

What Actually Happened

The timeline is the part people gloss over. Zig to Rust. Full runtime. Six days.

Not six weeks, not a quarter, not the year most companies would budget for a rewrite this size. The team used Claude Code's dynamic workflow system — the same fan-out-and-verify pattern I use on much smaller refactors — scaled up to a codebase most engineering orgs would treat as a multi-team, multi-quarter project.

The results have real numbers behind them, not vibes:

• 5x lower idle CPU usage
• Up to 35% less memory
• 50% faster startup on Linux
• 1,517 newly passing Node.js compatibility tests

Prisma moved Prisma Compute onto the Rust build before the public release even went out. That's the kind of validation that actually means something — a company betting production infrastructure on it before the announcement blog post existed to convince them.

It also shipped with more than 13,000 unsafe blocks. That's the number everyone online is fighting about.

The Unsafe Block Panic Is Missing the Point

Rust's entire pitch is the borrow checker catching memory bugs at compile time. Wrap huge sections of the codebase in unsafe, and you get Rust syntax running on Zig-era guarantees. You inherit the ecosystem and the tooling. You don't automatically inherit the safety story.

That's a fair criticism of the code as it exists today. It's not a fair criticism of the process that produced it.

// what "13,000 unsafe blocks" actually looks like in practice
unsafe {
    // pointer arithmetic ported near line-for-line from the Zig original
    // works today, isn't idiomatic yet, isn't the final state
}

Nobody on the Bun team shipped this and called it finished. They've been public that this is a first pass: lock in behavior parity first, then spend the next several point releases shrinking the unsafe surface with the same agents that wrote it. That's a completely normal migration strategy — stabilize, then clean up. It's just moving at a speed that makes "normal" hard to recognize.

Why "Nobody Read the Diff" Is the Real Story

Here's the part I'd actually push back on if you brought this up over coffee: the unsafe blocks aren't what should worry you. The review process is.

A codebase this size, reviewed primarily by two bots and spot-checked by a small group of humans, is a genuinely new kind of trust relationship between builders and their tools. I don't fully trust code I haven't personally read either. But I've been shipping features off Claude Code's output for months, and every single time, I read the diff, understood the change, and approved it myself before it touched anything real. That's still a human decision sitting at the boundary.

Bun 1.4 is the first time I've watched that boundary move for infrastructure I actually run in production. Nobody at Anthropic can walk you through this change line by line and tell you why each one is correct. What they can tell you is that the test suite passed and the behavior matches the old runtime. That's a different guarantee than a senior engineer reading this and understanding why it's correct.

Those two things get treated as interchangeable right now. They aren't.

The Uncomfortable Take

Everyone arguing about whether this was reckless is asking the wrong question. The real question is: what kind of software is this okay for, and what kind isn't?

For a JavaScript runtime with a massive existing test suite and an easy fallback — you can pin to 1.3.14, the last Zig release, if 1.4 breaks something for you — this is a reasonable bet. The blast radius is bounded. Bugs show up as crashes or performance regressions in dev, not silent data corruption in someone's production database three weeks later.

For anything touching money, auth, or user data, this exact process should worry you. Not because AI agents can't write correct code — I use them for that every single day — but because "the tests pass" and "a human understands this" are not the same claim. Right now, the industry treats them as interchangeable whenever the speed number is impressive enough to distract from the question.

Six days is an incredible number. It's also not proof of anything except speed.

I've written before about running Claude Code routines unsupervised overnight, and the pattern holds here too. I let agents run unattended on scoped, reversible work. I still read every diff on anything that touches a customer. Scale doesn't change that rule — it just makes it more tempting to skip.

What I'm Actually Doing About It

I didn't upgrade my own site to Bun 1.4 the day it shipped. Not because I distrust the team behind it — I don't — but because "first stable release of a from-scratch rewrite" is always a bad week-one bet, whether the code was written by a person or an agent swarm.

Here's my actual plan:

• Stay on the last Zig release, 1.3.14, for at least a month.
• Watch the issue tracker specifically for unsafe-block cleanup progress, not just new features.
• Let other people's production traffic find the edge cases first.
• Upgrade once a couple of 1.4.x patch releases land without a memory-safety CVE.

None of that is dramatic. It's just the same due diligence I'd apply to any major version bump, applied without getting talked out of it by an impressive changelog.

The Actual Lesson Here

The speed is real. The performance numbers are real. Prisma betting production infrastructure on it before launch day is real signal, not marketing copy.

What hasn't changed is the risk model for adopting someone else's rewrite of your dependency tree. That risk model doesn't get smaller just because the code got written faster. If anything, it gets a little bigger, because the pace makes it easy to skip the boring parts — reading changelogs, waiting for patch releases, checking whether anyone else has hit the edge cases yet.

Six days doesn't buy you the right to skip due diligence. It just moves due diligence to after the merge instead of before it.

Ship fast. Verify slower than the thing that shipped.