Just think about what "tests pass" means for a rewrite. If you rewrite from language A to language B then any unit tests have to be rewritten during the rewrite.

So either "tests pass" does not include unit tests or unit tests were rewritten probably by the same AI that is doing the rewrite!

The good part about a language runtime is there's a massive corpus of tests that are in that language and agnostic to the implementation language.

For a JS engine that's Test 262: https://github.com/tc39/test262

For node that's its unit tests which are mostly JS: https://github.com/nodejs/node/tree/main/test

Node also runs the web platform tests too: https://web-platform-tests.org/

Bun has a similar large corpus of JS/TS tests: https://github.com/oven-sh/bun/tree/main/test

You're right about general purpose rewrites, but language runtimes are a lot easier.

> quite a lot of analysis went into the rewrite

Literally just prompted for an LLM to review it and asked for a fancy presentation. That is not "quite a lot of analysis". That is anything but.

> If the tests pass, then why not accept the rewrite?

Because (1) tests passing are absolutely not a guarantee that no regressions were introduced in a change, and (2) even if they were, those tests are the result of thousands of hours of human labour, which is all well and good for the codebase as it currently exists, but who is going to be writing the tests for the 1m loc repo of unread code in the future? Unless you've proven that specifically LLM-generated tests can prevent all possible regressions, you're condemning the future of the project because nobody will be able to continue writing robust tests.

I hear a lot of complaints about bun but nothing concrete about what broke in the migration.

You are also assuming one prompt, and then arguing against your assumptions with zero evidence. It is lazy arm chair criticism.

>I hear a lot of complaints about bun but nothing concrete about what broke in the migration.

Because it hasn't been released yet (at least not outside of some unstable branches). You can find some criticism of the actual slop here though: https://old.reddit.com/r/rust/comments/1t4033y/buns_rewrite_...

Hmm, it sounds like the main example of “slop” there is 1000 global variables.

I’m curious if that matters if humans are never going to even read this code?

>I’m curious if that matters if humans are never going to even read this code?

If by never even read you don't include attaching a debugger to solve an issue. 1,000 global mutable variables would make debugging anything an absolute nightmare.

For us, but for an LLM with the right tooling? Idk…

Poe's law is making it hard to tell if your comment is sarcasm or AI-induced psychosis.

People are forgetting that "if the tests pass" is not a good measure of reliability. CS 101 from Dijkstra: tests cannot prove the absence of bugs.

Almost no test suite is comprehensive enough to cover even the kinds of bugs that will appear commonly in wide production use, let alone all of them. A big rewrite needs a lot of actual use as well to shake out the issues not covered by the test suite.

The ones who accept rewrites are expected to support it indefinitely.

That's why Jared didn't consider using it for Bun even if it's undeniably better, they don't have human resources to support it

We've repeatedly seen that these test-driven LLM rewrites consistently produce absolute garbage.

Got any specific examples? I believe you, I'd just like some concrete examples to show my coworkers.

Sure.

https://www.theregister.com/software/2026/02/13/anthropics-a...

https://pivot-to-ai.com/2026/01/27/cursor-lies-about-vibe-co...

Thanks!

Given that even the unsafe audit article appears to be written by AI that doesn't seem like much thought to me.

It explicitly says "AI-generated" at the top, so there's no doubt about it.