I wonder if I'm the only one for whom the bun project vanished completely.
In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package.
Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
I was willing to gloss over the AI usage because I really like the Bun DX. I used Bun in Shell scripts and small prototypes before and decided to use it for something bigger.
But then in a week or so of use, tons of issues appeared. Use-after-free bugs when a client disconnects (both in Zig and the Rust port, funnily enough) which will kill Bun. Unimplemented feature which just return “0” always. Many backpressure bugs which means something like “return new Response(fs.createReadStream(bigFile))” will greedily read and OOM your box.
All of these have been reported, robobun has made fixes of various quality, but none of this has been addressed. Some of them have been reported for months.
I’d prefer Bun to work on stability rather than fancy features like image processing or threads.
Everyone's excited about using AI to make their quick end products. But no-one wants to actually build on or rely on vibe-coded frameworks, languages, or tools.
I am constantly confused at work that people see AI as binary: it’s either a person writing the code and taking ownership of it, or it’s AI and the poor person has no control. It’s rather bespoke or entirely vibe coded. Why? When I use AI it’s still me writing the code, I just get better autocomplete and a tool that can verify my changes using fuzzy sentence as the linting rules. Why did so many people just immediately assumed that it all must be vibe coded now? Maybe it’s because everyone hates reviewing code they didn’t write?
I shouldn't have used the term "vibe-coded" as that's an extreme charicature. But I would argue in general heavy use of LLMs just does lead to sloppier code, and I think there's a general feel for that. Has AI use helped Microsoft make better software lately?
People live to benefit from AI for their own work, but are understandably uneasy about depending on code written by AI, even if it's (mostly) human reviewed. 2-3% more bugs may not seem like a big deal, but when you start building stacks of things these bugs bubble up and increase exponentially.
I think AI is fine, the problem is what you mentioned: vibe coding.
Have AI do work for you, it’s certainly faster in most cases. But just know exactly what it’s generating and building before putting it into production. That’s not some massive bar to surpass.
Yeah, but you dont know who is vibe coding and who actually knows the output of what they had LLM make
This leads to lack of trust, which the entire open source community is based on. Even if that vibe coded slop is flawless, the stigma will never go away.
That’s why you read the code and see what it looks like
In the infamous words of Spolsky - "It’s harder to read code than to write it."
What about Claude code?
What is vibe coding?
The term was coined by Andrej Karpathy in early 2025 where he wrote:
> There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
[flagged]
No it’s not.
Yeah, I have prepared our company software for migration back to node.
I would like to read the promised Jarred's blog post (if it ever comes out) before pulling the plug though.
I’m amazed folks ever migrated to it at a workplace level TBH. It’s a VC funded runtime, something was always going to happen to it. Node is boring but its governance and ownership is clear.
Well, it was (is?) significantly easier to use, faster, the team behind it is fantastic, and generally had enough compatibility to run the projects I needed it to.
When it’s enough of a drop-in replacement, that’s more than good enough. As long as we’re not adding a hundred bun-specific things, it’s not terribly difficult to back out of, either. Kind of a no-brainer.
Faster I get. But easier to use?
There is no comparison when running a TypeScript project with Bun vs with Node. Or when mixing ESM and CJS. Or when setting up unit testing.
Node and its ecosystem was considerably behind in multiple regards.
OP said:
> it’s not terribly difficult to back out of, either
Things like ESM/CJS interop are great but backing out of an ecosystem that uses it is absolutely not trivial.
Either it’s a trivial replacement you can drop in with no changes or it’s a notable change you can’t easily switch out. It’s not both.
Yeah. Take a look at the docs. So much niceties
...and now we also have Nub :
https://nubjs.com/blog/introducing-nub
Take a look at Deno. It's pretty great and now has exceptional node compatibility
> Take a look at Deno.
It's still heavily AI driven. Maybe less than Bun.
And they've gone in the route of just taking Node native libraries and what not just because they gave up on working out the compatibility. It's a bit of tacked on mess now.
Where are you seeing that it's heavily AI driven?
---
Edit: the contribution guidelines allow AI-assisted patches with disclosure. Also, there are a bunch of recent commits co-authored by bots
The entire RIIR saga , not the fact that it's rewritten in a different language, but how the author selectively choose to let certain information surface without clarification, tells you a lot
Personally not interested in performative/marketing-driven decision so I am done with the project and the author. Quite disappointed
"Even it that'd be the best code and design in the world, I won't use it. I don't trust it."
Nothing about this sentence makes sense. What don't you trust about code you can see and audit yourself? What's untrustworthy about "the best code and design in the world"?
I don't have the time to audit all the code in a JavaScript runtime myself, so I am forced to make assumptions about the quality of the code based on my trust of the authors.
Additionally, even if the code is good today, I am trusting their process will produce good code tomorrow (as migrating to/from bun has a non-trivial cost). A single person approving the code of an LLM is not such a process with today's technology.
I think this is precisely why I don't mind it that much. I can't audit a huge codebase like a JavaScript runtime, whether the code is by a human from scratch or not. I just have to trust it as a black box.
I've seen LLMs produce terrible code indeed, but I have also seen humans produce terrible code. I haven't dug in to JS runtimes specifically but have read plenty of code in openjdk and cpython - there are many points that could be done better, but there's also no point since it's working, and keeping working code unchanged tends to be a smart decision in software engineering.
So of course the last point brings up whether it was a good idea to rewrite bun if it was working. Apparently the bun team thought the difficulty in getting changes in zig upstream meant it is. I don't intend to hold LLM code to a higher bar than human code - notably if the runtime continues to work, that is as good as I can expect from what is otherwise a huge black box of extreme programming (not that agile kind).
The difference is you can evaluate a small bit of the output of a human or a team of humans and expect all their other code to be roughly in the same ballpark of quality.
An LLM can’t be trusted to produce code and make higher level project structure choices of the same quality at all times, because it can’t be trusted at all - trust is for deterministic systems. But still it begs us to trust it. Every prompt that yields good results sets us up to expect good results, so we get lazy - and then the next prompt it spews out garbage.
As long as the odds are good enough (and/or you know the distribution), there is nothing wrong in relying on and profiting from stochastic systems despite not every outcome being positive. What matters is the sum of outcomes, not the individual ones.
It means you need to be able to handle failure, but you should always have a good grip on how to correct if you intend to set things out in the real world which messes up everything always anyways.
Sure, but that’s not how most llm coding is done, because if a human has to carefully supervise the llm then what’s the point - might as well write it yourself.
Add to that, we’re very good at anthropomorphizing, and very bad at supervising systems that are usually right. Makes for a mess.
Oh, and this all relies on the ai providers not changing things up behind the scenes and feeding you a dumber model sometimes.
jhack's perspetive is something that is all too common in tech. The implication that if code is open source the owners and maintainers don't owe consumers anything because "you can always fork or build it yourself"... as if that were ever possible for the average user, or in a digital world where anything you do with a computer depends on endless recursive sub-dependencies.
It's analogous to saying "it's your fault because you didn't read the T&C's", when all the T&C's you've implicitly agreed to already would take more than a human lifetime to read and understand. That is not a reasonable implication or expectation for the vast majority of people, the vast majority of the time; therefore it is logically corrupt, and should not be entertained.
This is ofcourse a fair point of view for 1-few person codebases built for fun, or to solve their own problems, open sourced out of the kindness of their hearts, but when the open source code is built or maintained as part of a job function (receiving a paycheck) &/or to generate profit (either directly or indirectly to influence standards, gain market share, etc) the open-sourcing is more of a means to build trust and becon attention or adoption in the age of relentless enshittification.
Open sourcing should not be an accepted path for profit seeking orgs or individuals to exploit and screw over consumers, as though they are eternal beta testers whose trust and dependence are worthless externalities. It also completely ignores the time and effort consumers must invest themselves to learn your product, workaround any errors, and build it into their workflow. That is arguably worth significantly more than whatever fee they could pay you for your code.
I still really don’t understand what is so entitled about asking for a level of base empathy and care from maintainers.
People now yell at you that their only obligation is whatever is spelled out in the license they attached to the code. I think this is the same place where the logic of Code = Law comes from. People who think that you can encode the legal/judicial system into a set of axioms. This is not how the law works nor is it how it is taught and asserting this is a fundamental misunderstanding of human systems. It is incredibly destructive when people start applying maths as ground rules for human interaction. People do not live in black/white. We live in grey.
I am certainly not old enough to have experienced it, but I would venture a guess that the reason the BSD/MIT licenses originally existed was so that the universities had a CYA clause. I think you can see this erosion from a group of people sharing software in academic and hobbyist circles into weird legal absolutism as software becomes more of a business. For instance, Bill Gates’ famous letter to hobbyists or the PKZIP fiasco.
> I still really don’t understand what is so entitled about asking for a level of base empathy and care from maintainers.
> People now yell at you that their only obligation is whatever is spelled out in the license they attached to the code.
Let’s turn your implied question around: if a person wants to share code without any expectation of care and maintenance, what should they do? Is the entire concept bogus, and the developer should just keep the code to themselves forever? Or put a “DO NOT USE FOR YOUR BILLION DOLLAR COMPANY” in a README? What communication other than the license could reasonably be provided?
I think the person you’re responding to made a pretty good point that open-source is sometimes the passion of an unpaid 1-person “team” and sometimes the product of a VC-funded attempt to buy goodwill. The idea that asking for more from maintainers is entitled is clearly suitable for the former case but not the latter. Now that Bun has been bought out perhaps they are more deserving of scrutiny.
I'm not arguing against a base level of empathy and care for maintainers.
I'm arguing FOR a base level of empathy and care FROM maintainers WHO CHOOSE to build for-profit products in the open, and that empathy for all parties should be the base expectation from a healthy community, rather than the narcissistic view of "nobody owes their communities anything, regardless of context".
The narssisist view leads to the behaviour of Minio, Bambu, etc becoming an accepted norm; to the abuse, exploitation, and deterioration of open source communities by for-profit orgs.
I honestly trust code reviewed by llms multiple rounds more than human reviewed code. Here is the thing. I don't know the human who wrote the code but i am familiar with the model they use, which might already be better than many human.
It's not about the code or the use of AI. It's about the governance of the Bun project.
Nobody knows if the Rust AI rewrite was a good decision from a technical pov. We do know it was a unilateral and drastic decision taken behind closed doors and imposed onto all Bun users.
There was a poll on r/bun where only about 30% of users said they were going to use the Rust port.
https://www.reddit.com/r/bun/comments/1u3j4d7/are_you_going_...
Even worse, users on the Zig version have been pretty much abandoned. Any future bug fixes, security patches, etc will only be released in the Rust version.
It's called "mileage". This new codebase doesn't have any. Who knows what gremlins lurk in some of its darker corners.
> new codebase doesn’t have any
Claude Code & Prisma use it as of last week.
That comment had me reaching for the skull emoji.
Claude is riddled with bugs. That doesn’t inspire confidence.
original comment:
>> new codebase doesn’t have any
> No longer accurate. As of last week, Claude Code (an incredibly popular CLI tool) runs on Bun’s Rust rewrite.
How can you trust that they won't just rug pull all of the code you've hand-audited when they merge some 1800 file PR written by an LLM? Even if you decide to hold off on any security updates or minor bumps until you can hand audit again, what's the point? You could just go back to Node where they aren't engaging in a modern day Ship of Theseus every other week.
I do not agree with OP but to not understand “i don’t have the knowledge and/or resources to audit/review a language port of an entire JS runtime, but I still understand that a big-bang language port is something to be cautious of” is almost wilful tonedeafness
First word of second sentence:
> Stability
ie: lack of volatility, ie: integrity, ie: I know it does what it says and don’t have to second guess that.
Anthropic stuff runs on Bun, that's why they bought it. Should they be careful with Bun? Could Anthropic be a high value target for someone?
might as well use openclaw at this point. that's the same vibe I'm getting with bun. from engineering excellence and jesus this guy really sweats the details (using zig woah!) to wow this is just openclaw ai permagenerated stuff. not a fan
> And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package.
Bun is mostly AI written and AI reviewed at this point (all automated).
The 1-person is luxury.
citation needed
go clone the repo and run `git blame`.
I was already not much interested into it, now even less.
For me it’s still up in the air. I won’t bet against them just yet. Also, did they say only one person reviewed it? I really doubt that. Don’t assume that what you can see on GitHub is the sum of all actions taken.
Yea, more likely for the majority of the code nobody reviewed it. It was over a million line diff.
If we are generous and assume a review speed of 1 line per second, that is still over 11 continuous uninterrupted days of review by a single person.
[dead]
I agree with you. Human is a forgetful race, they just unlearned the zlib lesson.
Edit: fixed typos.
Do you mean XZ?
yes, It was XZ.
The problem is that you need to twist the cube
So you were fine with AI writing zig code, but AI writing rust is a step too far?
Im here with ya :)
It looks like quite a lot of analysis went into the rewrite
https://bun.com/bun-unsafe-audit
If the tests pass, then why not accept the rewrite?
An interesting article of Prisma using the rewrite:
https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
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.
My experience is that the people who talk about AI psychosis when it comes to coding are mostly skeptics with their head in the sand.
Do you seriously think that in a decade we'll all still have our agents writing code in the same architectures that we were using a few years ago?
[flagged]
>Dude, stop with “slop”.
No.
It's a useful term, just like "clickbait" was 10 to 15 years ago (and still is). Trying to police other people calling it slop is reminiscent of Microsoft autobanning anyone using the term "Microslop" on their Discord, it's idiotic language policing and I'm not going to do it, simple as.
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.
[dead]
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.
[dead]