It took nine days to rewrite all of Bun from Zig to Rust using an LLM and get the new code to the point where I could merge it. I saw that and my reaction was not “cool.” It was “oh no.”
Let me be clear. The speed isn't what scares me. The confidence is. Bun's lead developer had publicly downplayed the idea of a Rust rewrite just days before it happened. Then an LLM-assisted rewrite landed and got merged in nine days flat.
This is not just refactoring some part of the codebase. It's not porting a utility library. It's literally re-implementing an entire JavaScript runtime system - which is known to be one of the most complicated pieces of software.
The debate between Zig and Rust is not the real issue. That's the wrong argument.
The fundamental issue we should be discussing here is whether or not the team has a solid comprehension of the code that has been recently delivered? If a Large Language Model is used to translate hundreds of thousands of lines of code from one language to another, the output could be compilable. It could even pass all the tests. However, the conceptual understanding, meaning the knowledge regarding "what was the purpose of writing this line" is not simply transmitted alongside it.
→ LLM-generated code can be correct without being understood.
→ Code you don't understand is code you can't debug under pressure.
→ A runtime is the worst possible place for "it works, don't touch it" code.
I have worked on codes where some person wrote a critical module and then left the company. Thats already terrifying. Now, imagine the "some person" is a language model who cant expound on its design decisions.
Nine days is impressive engineering velocity. It's also a red flag for review depth.
Imagine the level of detail in a thorough code review of a runtime. You would be reviewing memory safety, edge cases related to the event loop, how syscalls behave consistently across all supported operating systems, and subtle concurrency bugs. These kinds of checks already take weeks when the code is authored by a human who can provide insight into the logic behind their implementation.
Fast merges feel great until the first mystery bug in production. The kind where the stack trace makes no sense because the code was mechanically translated and nobody on the team wrote it by hand.
I don't believe that the Bun team works carelessly. They possess evident skills. But talent doesn't give you a shortcut past the "deeply knowing your own codebase" requirement. Especially when it comes to a critical system like this.
Here's what keeps me up at night. If Bun can do this, every team is going to try it.
Startups will leverage LLMs to rephrase decades-old services in a few days. CTOs will approve language shifts that previously required months to complete. And some of those rewrites will work beautifully. But some will ship half-understood code into production systems that handle money, health data, or infrastructure.
→ The barrier to "just rewrite it" just dropped to near zero.
→ The barrier to "actually understand what you shipped" hasn't moved at all.
We are about to step into a time where writing code can be done incredibly fast and the real challenge will be in understanding the code. This disparity will likely result in some epic failures. 💀
I don't think LLM-assisted rewrites are inherently bad. They are like power tools. Power tools are fantastic until someone ignores the safety rules.
The Bun rewrite could be successful in the end. The team might spend the next few months internalizing every line. Rust's compiler catches entire categories of bugs that Zig doesn't. So, there are advantages in this approach.
What concerns me most is not the particular case but the precedent this sets. A decision-making timeframe of 9 days from “we’re not doing that” to “it’s merged” does not leave room for the slow, boring work of actually understanding what you built.
The best engineers I know aren't the fastest coders. They are the ones who are able to articulate every obscure line of code in the codebase when there is an outage at 3 AM. LLMs can not do that. Not at the moment.
My question is, would you mass-merge LLM-translated code into a critical system your team ships to millions of users? And if so, what's your plan for when something breaks in a part of the code that nobody actually wrote?