Is Bun's Rust Rewrite Slowing Down Releases?
Bun is moving from Zig to Rust. That sounds like a standard language migration on the surface, but the commit history tells a different story. We're looking at a massive architectural shift happening behind the scenes, and the timeline is where things get weird.
Jarred claims that a huge chunk of this rewrite happened in just 11 days. According to him, it cost $165,000 in Anthropic API calls to get it done. I'm skeptical. It's a very convenient narrative when you consider that Anthropic recently acquired Bun. The story here isn't just about a faster runtime, it's about proving that AI can replace open-source maintainers if you throw enough money at the API.
The numbers don't quite align with how Bun usually ships. The longest gap between releases was six weeks back in 2022. Now we're seeing a total rewrite delivered in a timeframe that feels more like a marketing demo than a software engineering cycle.
Was this actually a coordinated rewrite, or are we seeing the first real attempt to automate the core of a major developer tool?
The Scale of the Migration
The Bun repository is 1.23 GiB. For a codebase, that's huge. When you clone it, you're pulling 304 objects at a speed of 11.97 MiB/s. That footprint is a direct reflection of the complexity here; you aren't just moving a few scripts, you're migrating a massive amount of state and history.
The CI pipeline is where the real friction lives. It takes between 40 minutes and 1.5 hours to merge into main once the Buildkite checks finish. If you've ever worked at a tech company, you already know why that's a problem. It kills your momentum. You push a fix, go grab coffee, and by the time you're back, the state of the branch has shifted or a flakey test has failed.
This part is genuinely confusing: the sheer volume of objects doesn't always correlate to the number of lines of code, but it does correlate to the pain of the migration. To see how the repo handles this scale, you can check the size of your own local clone with a simple git command.
du -sh .gitI don't know how to feel about the "Canny" references in the logs. It's a weird touch. But the numbers don't lie: 1.23 GiB is a lot of baggage to carry into a rewrite.
Release Cadence vs. Development Speed
The rewrite is slowing down public updates. If you look at the 6-week gap in releases from 2022, it's a clear benchmark for how the team handles deep architectural shifts. The current pace is slower because the internal cost of a merge is high. It takes between 40 minutes and 1.5 hours for a change to hit the main branch after Buildkite checks finish. When your CI pipeline is that heavy, you can't just ship a dozen small fixes a day without grinding the whole process to a halt.
The sheer size of the project makes this friction worse. The Bun repository is 1.23 GiB. When you clone it, you're pulling 304 objects at a speed of 11.97 MiB/s. That's a lot of data to move every time a contributor needs a fresh environment.
git clone https://github.com/oven-sh/bun.gitThis part is genuinely confusing because the team claims high velocity while the release dates drift. But if you've ever worked at a tech company, you already know the answer. High-intensity rewrites create a bottleneck where the "work" is happening, but the "release" can't happen until the chaos settles. It's a trade-off: you either ship broken things quickly or wait longer for something that actually works.
The CI Bottleneck
The six-week gap between v0.2.2 and v0.3.0 was the previous high-water mark for Bun's release silence. This current stretch is longer. In a project that has built its brand on raw speed—not just in execution, but in shipping—this slowdown is noticeable. It suggests the team has hit a wall where the volume of changes is outstripping their ability to verify them.
I find the community's skepticism about the Rust rewrite grounded. There is a tendency to assume that "more Rust" equals "more performance," but that's a lazy correlation. If the commit history is bloated with non-idiomatic patterns or LLM-generated noise, we aren't seeing a transition to a better architecture; we're seeing the introduction of a different kind of technical debt. I suspect we're seeing the friction of trying to rewrite a moving target while maintaining a public API.
The real question is whether the performance gains from this rewrite actually outweigh the maintenance burden of a more complex codebase. If the benchmarks don't show a meaningful jump once this finally lands, this whole period of instability was for nothing.
Conclusion
The numbers don't lie, but they are weird. We've gone from a world where six weeks without a release was the longest gap in Bun's history to a state where 2,475 pull requests from "robobun" are just sitting there. That is a staggering amount of automated noise for any team to sift through.
I’m still not sure if this rewrite is a technical win or a massive experiment in AI-driven churn. Spending $165,000 on API calls to rewrite a project in 11 days sounds great in a pitch deck for a high valuation, but it doesn't solve the bottleneck of actually shipping the code.
The real question is whether a human can actually maintain a codebase generated at this scale, or if we're just watching the first major case of "AI technical debt" accumulate in real-time.