[apalmer]

It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.

[egorfine]

> A full rewrite of 1 million loc is essentially a new runtime

It's not a rewrite exactly. Nobody wrote anything. Not a single human has even seen, much less understood those 1m lines.

[jagged-chisel]

Who or what does the writing doesn’t determine whether it was a rewrite. It was definitely a rewrite. Maybe it was 100% automated. But it’s a rewrite.

[johnfn]

I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.

[omnimus]

It's not less reasonable. They don't have to promise giving Bun time in the future to evaluate. They might do it but they absolutely don't have to be responsible for doing it when the project made such dramatic shift.

They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.

[johnfn]

They can absolutely do what they want, and I can absolutely say it's an unreasonable decision. When I say "unreasonable", I am evaluating whether they are operating on sound technical principles or not - not like, "are they allowed to do this" or something more obviously true.

[Capricorn2481]

I think it's fine to not depend on code that nobody, even the maintainers, has read. Is that really controversial?

I do find it ironic you think this project is making rash decisions on no technical merit, and not Bun

[kelnos]

Why is it unreasonable, from a technical standpoint, to avoid vibe-coded software?

To me, proving a vibe-coded piece of software is fit for purpose is much more difficult than if it is human-written, or LLM-assisted with a human reviewing all the generated code.

[tatjam]

Welp, I mean once the Rust rewrite is merged, isn't it vibecoded? Fair enough, it was vibecoded from a pretty detailed Zig specification :)

[wiseowise]

> 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. We are adding a support ceiling of version 1.3.14, as that is the last release built from the original zig codebase.

That’s as reasonable as it gets. Yt-dlp isn’t a beta testing grounds for hyperscalers.

[Brian_K_White]

Even re-written by hand isn't the same because a hand re-write proceeds slower over a longer period of time with more smaller updates that get tested somewhat along the way.

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.