A major runtime just got machine-translated to a completely different language and merged in under two weeks. Let me say that again slowly.

Bun, the JavaScript runtime that the community keeps considering for a serious relationship, finished a rewrite of itself, from Zig to Rust. The rewrite was composed in its majority by the LLM model. The process lasted around 9 days. The Pull Request contained over 1M LoC of Rust.

I don't think everyone realizes how amazing that is.

This Isn't a Rewrite. It's a Translation.

Rewriting software and translating software are worlds apart. The former involves humans re-thinking the architecture, fixing old mistakes, and inevitably making some new and different mistakes in the new language. A translation means you shove code through a machine and hope the output is equivalent.

Who besides the maintainers themselves possibly has a shot at understanding most of the new codebase, given that they didn’t write it by hand? This isn’t a rhetorical question. It’s the only question that counts.

A Million Lines Nobody Wrote

Imagine the scenario of conducting a code review for a million lines of LLM-generated Rust. You're not reviewing logic someone reasoned through. You're reviewing output that looks reasonable — which is the exact failure mode LLMs are famous for.

What worries me the most about this is:

→ LLMs are confident pattern matchers, not reasoning engines. They'll translate idioms from Zig into Rust that compile but subtly violate Rust's ownership model in ways that only surface under pressure.

→ Edge cases are where translations break. The happy path translates fine. The weird concurrency bug that took six months to find in Zig? The LLM doesn't know it exists.

→ Roughly 9 days means roughly 9 days of testing. For a runtime that wants to run your production JavaScript. 😬

Tech Debt Laundering

Here's the phrase I keep coming back to: tech debt laundering.

You had a Zig codebase with known quirks, known debt, known ownership among contributors. Now you have a Rust codebase with unknown quirks, hidden debt, and near-zero institutional knowledge. The debt didn't disappear. It just got dressed up in a new language and a clean git history.

The old codebase was battle-tested. The new one is battle-translated. Those are not the same thing.

Why This Should Worry the Whole Ecosystem

Bun is not just another fun project some people happen to use. Some folks actually depend on it for their business. Some companies have staked their entire technological infrastructure on it. And the heart of said infrastructure is now a pile of almost-generated, not-quite-engineered code.

I don't mind AI in codebases. I use LLMs every day. However, there's a distinction between employing an LLM to generate a utility function that I meticulously check and using one to translate a complete runtime that I distribute to thousands of developers.

The real issue here is the speed. Nine days are just not enough to have the kind of thorough, adversarial reviews that a million-line systems codebase requires. It’s enough to let you know if “it” compiles and the tests pass. It’s not enough to let you know if “we” understand what we’re shipping. 🔥

The Real Question

This creates a dangerous situation that other projects facing a similar "wrong language" issue might try to replicate what Bun has done here, and undoubtedly most of them will lack the same resources and engineering know-how to offset the risks.

I think we're going to look back on this moment as either a breakthrough or a cautionary tale. I still can't say which. But I do know the trust we've placed in open source assumed maintainers knew their own code. That just became a lot more difficult.

So here's what I want to know: Would you run LLM-translated code in production — and if so, what would it take for you to trust it?