Comment by hootz
2 days ago
Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
2 days ago
Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
Have there been any significant issues caused by the vibecoded translation?
To be clear, I'm not implying support for the merge. I am against this whole YOLO approach to engineering. Just curious how the switch is going since I haven't seen any news since the merge announcement.
IMO the source of the new code is less important than the sheer volume of it. Bun does not need to be entirely rewritten; certainly not over a period of a week, possibly not even over a period of a year. Stability is hard-fought and battle-tested. Everyone has a plan until they get punched in the face; and every repository has passing tests until it runs production code.
How many lines of translated code would have been acceptable? What about before AI all the machine translated projects that people used for years without a single complaint? The person who did this was the lead for Bun from the get go no? So it stands to reason that they are one of the highest authorities in Bun itself.
7 replies →
I agree, I'm just wondering whether the punches have come already. Honestly, the fact that they haven't is against my expectations, my guess was that we'd see a noisy one here a day after merging.
It's too early. It might be too early forever.
Epistemically: if it can be so easily vibecoded to rust, why can't it be vibecoded to be reparted? Isn't the great and Almight AI unable to parse and repair Zig? Identify it's weak points and route around it?
I think it's hilarious how hopeful people were at the acquisition that Bun would be able to continue on mostly as it had been but then that all got completely thrown away and trashed.
(Hilarious in the way that's terribly sad, of course.)
It usually takes years for someone's values to be thrown out the window! How long was this one?
Give man a Claude subscription and he can work for a day, let Anthropic buy the man and he doesn’t need to work a day in his life anymore.
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it"
changing your employer tends to accelerate that if the new employer has different values.
I don't think the man had any values to begin with.
https://news.ycombinator.com/item?id=48243990
How has it been trashed? Does the Bun software not work anymore?
They literally threw out every line of code that existed before and rewrote it in a completely different language, seemingly on a whim. That's how it was trashed, in the very literal sense that all of the existing project was tossed in the trash in favor of a completely brand new code base. That's a big deal even if you ignore the coding agent aspects.
7 replies →
>Does the Bun software not work anymore?
Nobody knows.
Spatting on community was a big deal in OSS circles.
According to the bun team, it was already vibecoded for months before the Anthropic acquisition.
vibe coding on top of an existing battle-tested codebase is very different than merging a 1 million LoC pull request that is a week old
Probably a lie tbh
Why is it so hard to believe that Jarred Sumner, a self-described "Thiel Fellow and a high school dropout", had values aligned with Anthropic's before Bun was approached for acquisition? It's not like Claude was an asteroid that crashed into Eden.
3 replies →
the proof is on github; it's true
Why dont you want it vibe coded? Does that make it worse?
Not necessarily, but I don't trust Anthropic in making sure it doesn't become worse. They are already doing a terrible job with their own Claude Code CLI.
Ah I see, yep agree with that 100%
ITS NOT VIBE CODED , JUST TRANSLATED .
Nondeterministically translated
It is vibe coded with a very good prompt.
Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?
It's just a trust issue. Have you seen the absolute state of the Claude Code CLI development? I don't want that to suddenly happen to Bun after I've already used it for production stuff.
I don't see any hypocrisy in the comment you are criticizing. The behavior they are criticizing appears to be vibe coding. How is rejecting something for being vibe coding "exhibiting the behavior" of vibe coding?
You aren't allowed to dismiss vibe coded software based on the slop vibes. It must be well-researched and human reviewed in order to have an opinion.
1 reply →
There’s a big difference between vibe coding and agentic engineering. If you think they are at all the same thing, you need to update your priors
2 replies →
The ground truth is that the new maintainers can’t possibly have a good understanding of the many millions of lines of vibe-translated code. Even assuming that the code happens to work okay in its current state, the lack of understanding means a high risk that its continuing maintenance won’t result in a satisfactory level of reliability.
Aren't the maintainers the same people? I haven't seen any talk of who's working on it changing drastically.
You want the yt-dlp authors to review the entire post-migration Bun codebase?
And what are you referring to as "behavior"?
Do you review your dependencies’ entire code?
1 reply →
Virtually no one reviews entire code bases of dependencies, what on earth are you talking about?
1 reply →
No, would you use a proudly vibe-coded banking app?
How would you know it was out wasn’t vibe coded?
1 reply →
I'm not sure what "exhibiting the behavior you are criticizing" would even mean here.
BUT.
"Ignore anything but actual problems" is a terrible stance to take generally for software and dependency selection. Incidents are fairly sparse, process is much easier to observe. So if you can find connections between process and incident possibility, that's a very reasonable heuristic. And it's easy to find examples of overaggressive LLM usage introducing problems into software.
You are putting words in my mouth, I never said anything about such a stance.
The vast majority of new software is written using AI. The problem is not that it is written by AI, but rather than some people treat it like a black box. It is entirely possible to use AI to write code and verify that it is correct. Even Linus Torvalds is allowing AI generated code into the Linux kernel as long as it's managed properly.
4 replies →