The Perils of 'Vibe-Coding': Lessons from the Bun Rust Rewrite

The recent announcement that the Bun runtime was rewritten in Rust—facilitated largely by agentic AI—was intended to be a showcase of modern development speed. However, the excitement quickly turned to scrutiny when a GitHub issue revealed that the new codebase fails basic Miri checks and allows for Undefined Behavior (UB) even within "safe" Rust.

This incident has become a flashpoint for a broader conversation about the current state of software engineering. It pits the "move fast and break things" ethos of AI-driven development against the traditional rigor of systems programming, raising critical questions about what it means to "rewrite" a project in a memory-safe language when the process is automated by an LLM.

The Technical Failure: Safe Rust and Undefined Behavior

At the heart of the controversy is a report that the Rust port of Bun contains unsoundness. In Rust, the primary value proposition is that "safe" code is guaranteed to be free of memory errors. However, when developers use unsafe blocks to perform low-level operations (common in runtimes like Bun), they must ensure that the safety invariants are maintained.

If an unsafe block is wrapped in a function marked as safe, but that function allows a user to trigger Undefined Behavior, the codebase is considered "unsound." As one community member noted:

The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code... Temporarily in a porting stage incorrectly marking some unsafe functions as safe isn't a real issue [unless] they made an actual release with the code in this state.

Miri, a Rust interpreter used for detecting UB, flagged issues where pointers derived from mutable references were invalidated—a classic memory safety error. For a project migrating to Rust specifically for its safety guarantees, failing these checks suggests that the "port" was a literal translation of unsafe Zig patterns into unsafe Rust, rather than a redesign to leverage Rust's safety model.

The Rise of "Vibe-Coding"

Much of the community backlash centers on the method of translation. The rewrite involved a massive diff—reportedly over a million lines of code—generated by AI and merged into the main repository with minimal human review. This has led to the emergence of the term "vibe-coding": a style of development where code is generated based on the "vibe" of the original project, passes a basic test suite, and is merged without a deep understanding of the underlying logic.

Critics argue that this approach transforms the codebase into a "black box." When a million lines of code are generated by an AI, no single human truly understands the entire system. This creates a dangerous cycle: when bugs are found, the solution is often to feed the bug report back into the AI to generate a fix, further distancing the human engineers from the actual implementation.

The entire codebase is slop now. Nobody knows what it does. It manages to pass some tests, but its largely a black box just on the basis of humans haven't read it yet.

Porting vs. Rewriting: A Philosophical Divide

Not all observers view the situation as a disaster. Some argue that the goal was a "port" rather than a "rewrite." In this view, the priority was to move the codebase into the Rust ecosystem as quickly as possible to gain access to its superior tooling and type system. Once the code is in Rust, the team can iteratively refine it, using the compiler and Miri to identify and fix the bugs that were previously hidden in Zig.

This perspective suggests that a rough translation is a pragmatic first step:

Couldn't a case be made that it's better to get Bun to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as a follow-on effort?

The Trust Gap and the Marketing Asymmetry

Beyond the technical details, the Bun saga highlights a growing trust gap between developers and the companies driving AI tools. There is a perceived asymmetry between the "flashy announcement" of an AI-powered rewrite and the "quiet correction" of a GitHub issue.

For some, this feels less like an engineering milestone and more like a marketing stunt. The transition from Zig—a language respected for its explicit control—to an AI-generated Rust codebase has left some long-time supporters feeling betrayed. One user expressed that the decision-making process behind the rewrite is more concerning than the code itself:

I got really excited about Bun for many reasons... the decisions were ones that I respected and would probably have made myself... This behavior, though, is exactly the sort of decision-making that I don't respect.

Conclusion: The Future of Large-Scale AI Migration

The Bun incident serves as a cautionary tale for the industry. While LLMs can accelerate the boilerplate of a migration, they cannot yet replace the architectural rigor required for systems-level safety. The transition from a memory-unsafe language to a memory-safe one is not merely a syntax change; it is a conceptual shift in how memory and ownership are managed.

If the industry moves toward a future where codebases are too large for humans to comprehend and are maintained by AI-fixing-AI, the very definition of "maintainability" will have to be rewritten. For now, the Bun Rust rewrite stands as a stark reminder that in systems programming, the "vibe" is not a substitute for a proof.