(Hilarious in the way that's terribly sad, of course.)
Nobody knows.
And what are you referring to as "behavior"?
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.
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.
How on earth does this follow? It's common, so it should be accepted without scrutiny?
>The problem is not that it is written by AI, but rather than some people treat it like a black box.
Yes, and guns don't kill people. Obviously the issue has two facets. It would be irrational to say "AI is flawless" or "humans are flawless".
Allowing genAI code does not imply blindly trusting genAI code.
>as long as it's managed properly.
Correct. Hence the issue. This was vibe-coding by even the strictest definitions of the term. Vibe-coding is, by definition, not "properly managed".
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.
I don't know any bad stories about ai-translated apps. Partially because it's a relatively new trend, but also because a big amount of usual vibe code fail modes are not applicable here.
2. Even if somehow you did make bug-free software with tests alone, even if the Rust port is at perfect parity with the Zig codebase today owing to the years of careful human work that went into building tests as a framework to guide the AI... the future can only be downhill from here. Nobody has a mental model of the new 1m loc codebase that's never read by humans, so Bun's future is committed to 100% vibecoding. Maybe the carefully planned tests minimized the worst case scenario, but the future tests will be written by Claude too.
If, and this is a big if, it turns out that there are no major problems and Bun is better off in a year from today than it is now... then somebody can just fire up Claude and fork yt-dlp to support Bun anyways and their decision doesn't matter. In any other scenario than human code becoming completely obsolete, they are simply saving themselves a headache by getting rid of a troublesome dependency.
That is to say, techno jesus cometh.
The PR that was merged.
Bun is also iterating back and forth with AI. The rewrite only got popular because of bigger scope. The bigger the scope is, the more bugs there are.
> getting node compatibility tests passing
So does Bun.
> which is something an LLM is very good at.
Doesn't matter. The code those LLMs operate on is simple enough that any middle software engineer can do.
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.
> Removed: mathjs dependency. 14MB, 200+ functions. Twelve functions used. Added: Custom math utilities module (src/math-utils.js). Addition, subtraction, multiplication, division, a handful of trig functions. Co-authored-by: chatgpt. Changed: Bundle size reduced by 68%. Build time down from 12s to 4s. Module: 47 lines across 1 file. 0 tests. 0 dependencies.
That it took so long before they started trying to phase out their home-rolled library for the "hard cases" is somewhat unrealistic, although possible in a sufficiently-dysfunctional organisation. Some of the details about the problems of their homespun library are clearly anecdotes translated from other settings, and are unrealistic in the context of a mathematics / finance library. (They only noticed that interest calculations were wrong when a customer complained? Seriously?) The development of 6.1.0 (via 6.0.0) taking only two weeks isn't congruent with the rest of the story, although it may be realistic for AI-driven development (with which I am unaccustomed).
But otherwise, this is one of the more realistic satire pieces I've read.
Go binaries are immensely satisfying, but I don't follow your logic here. The vast vast majority of dependencies in Go do not depend on the outside world, so the binary would remain self-contained whether it has 1 or 100 dependencies, no?
It is impossible to review the entire rewritten codebase. There are just too many lines of code, 1 million lines to be exact [1].
It’s all the same just different syntax. Which, by the way, is why it looks ugly to rust developers. The devs wanted the code to look familiar to them.
I do think they should have called this 2.0 though. Would not feel such a rush (1.3.14 has a few regressions, and no one really cares because there are lots of small rust fires now).
Overall, the bigger issue is that bun chases shiny objects. But never finishes. Just look at test stuff. Most of vistest, but not all. Most of jest, but not all. Most of pnpm, but not all. Now we have image stuff, so most of sharp, but not all. dev server? Most of vite, but you guessed it… not all. Long running process… mostly like node but with memory leaks (and a motivation for rust I’m sure).
When I saw them posting about the Image routines my heart sank. Another shiny object. Coincided with test bugs so I moved to vitest completely.
With quite a peculiar set of supported formats different between operating systems.
Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version?
Really? Did they just completely admit that the great AI future can't secure a significant project repository?
I think you are not understanding the new paradigm. The idea that 'humans are going to understand the codebase' is dead. Codebases will be maintained and reviewed by AI. You might think this is bad, but in many aspects of human history, we have traded understanding for convenience—that's the reason why we buy food at the supermarket instead of hunting for our meal. This has happened in every area of humanity, and it seems foolish to think that code generation would be immune.
Again, you might think this is a bad thing, but it’s simply how humanity has been functioning. 'Oh, but who is going to maintain this?' AI. 'Oh, but what if one day that's not possible?' Well, what if one day the electricity goes out due to solar flame or whatever? You get it?
You could always take a job on a cattle ranch or an abattoir or meat-packing plant, or watch a How It's Made documentary, and get some understanding of how the sausage gets made and put on the supermarket shelf for your convenience. This was also true as we built abstractions in computer technology: you could start off learning a high level language, then learn a lower level one, then study or build an operating system kernel, a compiler, an assembler, machine code, and then crack some books on microprocessor architecture and signal processing. You could always "go deeper" if you wanted to. And there is a payoff: understanding at a deeper level helps you get things done better at the higher levels (e.g.: understanding the concept of memory hierarchy helps you lay out data structures to make code faster).
There is no such step for slop-coded codebases: you become entirely dependent on a context-limited LLM to have a shot at even approximating some understanding. The proponents of this style will tell you, don't look at the code. It's the antithesis of every other abstraction we've built in computing.
Perhaps more productively, you treat the slop as a black box and build something understandable around it.
This is also why the notion that developers in the future will be committing LLM prompts in English to repositories instead of code written in a programming language is so foolish. I am saying this as someone who uses LLMs quite a lot to help with generating and understanding code.
The entire chain from farm to table is managed and operated by humans.
Every automatization effort ever always had human oversight.
Its not the same thing as entrusting the entire codebase to overachieving markov-chain who has no concept of correctness over anything of sounding ok.
Honestly, saying the humans understanding codebase is a dead concept is the most techbro-ish I heard today.
Large LLM-written code is called slop for a reason. It's hard to understand because oftentimes it does not follow human logic.
It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or expensive machines and they can't just buy another one for another X years.
First they essentially wrote a translator that preserved the C idioms (so it wasn't idiomatic go) until they had byte for byte output.
Then they started changing code one by one to be more Go-based.
Bun is doing the same. Right now it is mostly a one for one translation of the zig code. Over time they'll make it more idiomatic Rust.
Deno and Bun have decent Node compatibility, so couldn't Node APIs be used as the generic runtime interface?
--js-runtimes [deno|node|bun|quickjs]I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here.
I really appreciate the maintainers' effort towards this awesome project. However, I think it is fair to be a little bit less confident with the current state of Bun.
I see lots of ground for that claim.
or... they just trust that their ai got it right, which to most people is "vibe coding".
Once bitten twice shy, y'know. Maybe the first bite wasn't even from bun. If bun can't take this on the chin and come back stronger, maybe bun wasn't a good choice to begin with. I'm sure a future version of bun with a rebuilt reputation will have an easy time getting re-adopted by most projects that needed to play it safe during the transition.
Bun being replaced entirely with stochastically generated code is red flag (regardless of whether it was or not). But Bun was also acquired by a huge corporation, which has been classically a huge red flag. Both of these are plenty of reason for yt-dlp not to support Bun.
In either case, this seems like a niche use case. I've used yt-dlp for years and I've never used Bun with it. If Anthropic really wants their recent acquisition to be supported in yt-dlp, it can fork it and support it itself.
Cool production? false
On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to experiment on your users if you thought there was a reasonable probability of increased security vulnerabilities.
I think there's a good argument that the responsible thing to say would be "we aren't going to immediately support running our software on a new bun release cut from main right now".
It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable engineering decision. Saying "because they vibe coded we are dropping support for Bun" sounds political.
Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.
Sure it’s political but it is also just a sane approach, to stay away from such disruptive change and treat it as wait-and-see instead of tagging along for the ride. There is not really any technical upside to tagging along and promising support.
If it’s based on predictions of how some alpha software might turn out in the future then I don’t see how you can claim it’s cheaper.
If a bunch of new bug reports came in then you said no, then everyone would understand.
This is pretty obviously ideological otherwise. Which is fine, but we shouldn’t pretend otherwise because we might agree with it
I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in.
It happens that in this case that I'd disagree with their politics if that's why they are dropping Bun support - I think there's a great deal of value in moving to memory safe languages, little harm in accepting anthropic compute and funding to do so, and that use LLMs themselves is roughly value neutral (though many uses are very much not value neutral). That said reasonable people definitely disagree with me.
EDIT:
Everyone is rightfully calling me out that this doesn't make a lot of sense. What I meant is that the move is driven by ideology.
I'm not familiar with this definition in any modern or archaic sense. Is there somewhere I can read about it? Just because a decision is not directly engineering related (which I'm not even convinced this is) doesn't mean that it's not thoughtful.
Regardless, the decision was 99% logical. In fact, even the emotional parts are laudable. For example, I love software. That's an emotion. If you disagree with that foundation, we will fundamentally never be able to converse with each other about what's best for software.
Fear (emotion) is used (advantageously) to force us to check that something isn't going to break us
In this instance fear is being used to ensure that yt-dlp is not exposed to (genuine) concerns about the quality of bun that is openly being built making use of tools we as a whole know is problematic.
I agree with you that the statements are a bit over the top (that's an emotional response to their statements btw) and that (eventually) you would /hope/ that bun gets to a point where it's got some genuine reliability from a users perspective.
Edit: I see your edit to explain that the issue is ideology - but unfortunately (perhaps) that's not an improved stance - ideology has to guide us when we just don't know - it's a heuristic.
If they had decided to drop Bun for "AI assisted coding," that might strike me as a political decision.
I disagree that this is a political stance. People based on their experiences have formed opinions on whether they trust that model of development or not. Bun having taking extreme measure of going 100% in within a week is itself extreme positioning from their side which will likely result in extreme reactions because depending on who you are and your experience you'd bet on the fact that it may or may not work out.
I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.
...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on.
As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your code still works and no effects show up at runtime. Are you going to keep using it or dump it based on the "feeling" that something isn't right?
You cannot take back a promise after you make it. So if you discover bugs later you cannot just leave.
This script is just a JavaScript helper to bring full YouTube support to some media download tool. It does not seem important to anyone that executing it using Bun is supported. They support the Deno and Node runtimes.
We've known for decades that machine-translated code is garbage, and should only be done as a last resort.
Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.
Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.
If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.
What kind of code can't node run?
At the same time, his arguments in favor of Rust are sound, there is no doubt about that.
They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.
It's not a rewrite exactly. Nobody wrote anything. Not a single human has even seen, much less understood those 1m lines.
Also I don't think it's wrong to use an action as an input to judging engineering character. That could be read as judging yt-dlp or judging bun but in this case I mean it's reasonable to judge bun's developers.
IDK if i'd personally judge this action quite so badly though. It depends how they went about it and what they proffessed to get out of it.
I am very much against letting llms think and decide for you, but I don't think it's so wrong for an actual coder to employ automation.
But if they are acting like it's magic and everything will be so much better after the magic llm uses the magic safe language... yeah that definitely gets the side eye. Or no eye. Just no longer interested in or concerned with their output.
Since this is being offered as the next release version while still being new and stuffed with unsafe, looks like it's the latter. So I'm with yt-dlp in this case.
It doesn't matter if the new code happens to be ok or not, it's still a problem that they got there by hoping a black box does the right thing. A black box that that no one wrote and no one understands, not just themselves.
gcc is a black box to me, but I know that someone wrote it and understands it (or some people collectively understand all it's parts), and I know that any time I want, I can choose to understand any part of it, and satisfy myself that it is doing something both sane and deterministic.
So a developer choosing to use gcc when it's a black box to them does not reflect badly on them to me.
But no one can say that about any llm or ai. So yeah, a developer choosing to use them, depending on exactly how, may reflect badly on them.
The same was true for cheap off-shore gig coding by humans too. I have tried to use them myself in the past, hire out for small generic programming jobs using those web sites where you put up some escrow money and post a job and people bid for it, you choose one, they do it and get paid from the escrow. I only tried about 3 times for the same small job and every time I git ridiculously shit (but technically functional) results.
These were humans 15-20 years ago, no possibility of hidden ai usage like today, and it's essentially the same dynamic of just hoping some magic will get you something good for cheap, and accepting any result that appears good as good.
If someone said that that's how they made their product, I would decide that product is probably pretty crap inside and no way should I buy it or invest in it as a dependency if I have any choice.
And that's humans not ai. The problem isn't really the ai, it's the judgement to use an ai that way.
What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.
They may have been rejected for being vibe coded if they were original, but they were rejected for being pointless. The rust rewrite was because Bun was butt hurt that they didn't actually help.
I'm glad some engineers realize that technology is inseparable from politics. It always has been. All evil came from engineers who beleived they were above politics. Selecting the tool which got the job done/made the number go up/paid a paycheck is how we got Facebook, Google, Palantir, crypto, AI, techno-fascism and neo-feudalism. None of it would've have happened without engineers blindly applying their knowledge to achieve "purely" technical results, while ignoring the social consequences. With the hindsight of the last 20 years, anyone who still advocates for an irresponsible adoption of technology should be considered automatically suspect
being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks
You are 100% right. This is a decision made on VIBES and not evidence. The proof is here:
> Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid.
They haven't tested it, they haven't found a single problem. They just don't like AI code and they're clearly saying "the fact that the project tested every line of code and it passes all tests doesn't matter to us. The fact that it's vide coded by people who literally make coding LLMs also doesn't matter."
Pure ego, no data.
No healthy engineering team is going to do that. And I’d want to distance myself as far as I could from a project that behaves like that.
Seems reasonable to preemptively drop support and let someone else either suffer the fallout, or get proven wrong and just pick up support again. It's not for a lack of people motivated by IA. Unless the motivation is more "use my IA generated content" than "actually consume IA generated content", of course.
Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse
All Bun devs are happy to change programming language?
When their competition is already in rust and more mature
While using the LLM that is now paying their salaries. Kind of a conflict of interest
Even a major version upgrade is enough for me not to touch it for 6 months, let alone a full rewrite
Has Bun posted any analysis and shown the data?
Jarred promised a blog post just like he promised to not merge the slop branch.
Even multiple people can not go through 1m lines of code for any kind of vulnerability in 7 days, let alone 'observe' more segfaults, OOMS, unsafe behavior, on who knows how many possible ways things can go wrong in this new condition.
Only guaranty is 99% tests passed, and the engineer who is paid by the same LLM company.
How in the world, any sane engineer would agree, this would be remotely a good idea to continue using this tool, for a chance that such a expensive change won't actually land in production?
I do, for example when I see constant behavior of lying, or negligence for security issues or not considering valid PRs and rewriting it to fit their paid plan and so on.
> I select them because they do the thing I want them to.
This is one of the dimensions when I pick the tools, I know Oracle produces nice products, but I don't want to get sued if I do something accidentally their lawyers dislike.
and yet...
> If Bun starts having more bugs and feeling like worse software, I'll stop using it.
Is it not possible to judge that certain approach is more likely to bring unforseen controlable problems than another by analyzing how it works without assessing it's output? No "feeling" is needed
But you do select your engineering tools on faith apparently.
Can we at least try to be a bit more accurate and less hyperbolic?
I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others.
I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.
Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.
Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to man.
Suffice to say, I'm yet to see anything that really worries me in any major way with this.
Didn't they also change the tests to make the re-write pass?
When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not.
You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost.
There are a lot of unknowns about vibe bun right now.
One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out.
If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.
Your argument could go other way too. Why haven't they landed if they're so confident with the change?
> Due to foreseeable compatibility and security issues
Hmm, Zig bun crashes plenty.
I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites. Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would be good to see.
I hope Bun.rs is 1.4 or even 2.0 and not a minor release, with some alpha/beta releases.
But it's been available for a week. And so far, seems like crickets on actual data on any regressions. It's more "I just don't like this!" style grumbling.
It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually has when they just use "vibe coding" as a general LLM usage slur.
I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster.
I'm using LLMs to assist my development and I'm measurably (in all the ways we
engineers could possibly care about) doing better work faster.
Writing code is rarely the limiting factor in our work.
I'm not vibe-measuring my output ;)
https://x.com/karpathy/status/1886192184808149383
In the case of this specific port, the port was done so fast that it is clear humans did not verify the soundness of the translation. It is not clear whether this manual verification will ever occur.
That being said, most software projects were already doing "vibe coding" by Dijkstra's standards long before AI showed up. Going on vibes and forgetting that correctness even exists ;)
Guaranteeing the correctness of complex code is difficult, but it will increasingly become non-optional as we now have a billion hackers in a data center.
---
Edit: "Bun's unreleased Rust port has 13,365 unsafe blocks"
Bun’s source code rewrite from Zig to Rust was executed primarily through AI-assisted development using Anthropic’s Claude agents, specifically within a branch named claude/phase-a-port. The project creator, Jarred Sumner, merged the massive pull request (PR #30412) on May 14, 2026, which involved over 1 million lines of code added and 6,755 commits completed in roughly one week.
primeagen's view
It’s just someone quoting someone to help ground their position.
What if it was a journalist writing about a security vulnerability then a programmer quoting them, would that count then?
Which defeats the purpose of having it in rust.
Identifying where code is unsafe, is a qualitative improvement. Not guaranteed to be complete, but more complete than a language that does not focus on that concern. Moving forward, the benefits of Rust compound. The concern about AI is orthogonal to the concern about moving to Rust.
Now there are 2 versions[1] that can be instrumented, regardless of the misgivings about AI.
[1] Bun v1.3.14, released on May 13, 2026 (commit 0d9b296af) and current.
And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem.
Strange.
Or did we forget software inherently is opinionated
if it works, it will keep working. they just don't want to support and maintain it and solve issues.
https://jxself.org/shifting-the-trap.shtml
You can run a BF and, soon, subleq.
To be fair, I'm not quite sure why it would prefer either Deno or Bun when it's far more likely that a user has Node on their system.
It’s not the same obviously, but here’s why I can’t help but view it analogously:
The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with rigor or just trying random stuff until it seemed to work.
In other words, we didn’t judge someone’s software by inspecting their methodology or what tools they used. Heck, we often ended up using software that had no test suite or where the test suite was junk! And so many of us who are fans of memory safety use tools written in C, and vice versa (I’m no Rust fan but I use plenty of tools written in Rust).
So yeah, the logic that goes, “I won’t use your stuff because I don’t approve of your use of AI” is about as believable to me as if you stopped using something because you didn’t like the authors choice of editor
I don't think many would say the same for LLMs.
Maybe vibe bun is just as good or better than old bun, but how would we know at this point?
> ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology...
That's not true. First, some people do directly check whether a project has a level of rigor they are comfortable with before adopting it (or when deciding whether to continue using it). I personally do it, where it matters. Many more use reputation signals, which, while certainly not perfect, correlate, may be good enough, and are a lot easier than direct, manual reviews.