Comment by stingraycharles

Side note, but I think using LLMs like this to write PoCs in existing projects is actually a good idea to prove whatever you had in mind is feasible and worth it to pour time into. Obviously you need to not vibecode the entire thing once you're past that point though...

> It would have been much better if the bun team joined forces and helped out instead of vibe coding a broken PoC patch that never can get merged

Bold of you to assume they have the expertise.

> It would have been much better if the bun team joined forces and helped out

Submitting patches is joining forces and helping out.

In the context of this post, that's absolutely hilarious they're vibe-porting their Zig codebase to Rust.

I love Rust, but you couldn't pick a language with slower compile times... XD

That reply was educational indeed. Thanks for sharing.

One non-obvious reason is that an important aspect of their community is to shepherd new contributors [1]. LLMs crushing everything would reduce that. More obvious is all the toil for maintainers dealing with LLM PRs (broadly it’s an issue). The Zig maintainers prefer to put their energy into improving people and fostering those relationship.

[1] https://kristoff.it/blog/contributor-poker-and-ai/

There are other reasons why a project like Zig might not want to accept LLM generated contributions.

Zig, as programming language, has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will, as it's a fundamental building block of everything that uses Zig. Just that could be worth the extra scrutiny on every individual commit.

There's also the usual arguments: copyright ethics, environmental ethics and maintainer burden.

>Makes me wonder why zig announced the strict LLM rule recently.

I guess there are 2 philosophies in software development: move fast and break things and move at a pace that guarantees everything is rock solid.

Most commercial software, Anthropic included is taking the former path, while most infrastructure teams are taking the later.

I guess Linux and FreeBSD kernels are also not accepting LLM based contributions yet.

The LLM rule has been a thing for a very long time at this point.

Possibly, but the Zig creator is active on Lobste.rs, where he's been vocally anti-LLM for a year now, so the timing could just be a coincidence.

It's a combination of pragmatism (not wanting to wade through slop, not wanting to shove out newbie developers) and politics (usual contemporary techie progressive stuff that's now oddly anti-technology).

Rust is a significantly more mature language. Adoption of zig has to be done on the assumption that the language will significantly improve as your project evolves, and if those improvements don't agree with your project's goals you're in something of a lurch. Rust is basically finished and adopting it has to be done on the assumption it won't change very much. I don't know what their initial logic for adopting zig was, but I think porting to a more mature language was inevitable, unless by some miracle zig happened to rapidly mature in exactly the direction they wanted,

Perl

C obviously.

Javascript

Rust is legit one of the best languages to "vibe code" in.

The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.

This should be the top comment in the whole thread. AI is not the point, the PR is just not of a good quality.

What a sober, detailed forum post.

Thanks, that is the answer.

That is a devastating comment. I will now be extremely skeptical of bun.

Perfect A/B experiment opportunity. Fork Zig, call the fork Zag.

Lock the syntax/api together for a couple of years. Allow AI code in Zag.

Review after a few years, see which is better.

Take off every Zig

...and rewrite it in rs.

It depends: https://github.com/rust-lang/rust/pull/155403#issuecomment-4...

Very likely not, if they are of similarly low quality.

No. The Rust project developers are more lenient when it comes to developing patches with AI assistance, but the amount of leniency one receives is proportional to the amount of pre-existing trust a contributor has with the project, and every PR still has to be reviewed by an independent human. A stranger dumping a zillion lines of slop in a PR is a one-way ticket to having your PR politely closed.

Then that becomes an ongoing effort. The rewrite is once. (Good idea or not)

Stay away. Everyone wins.

Yeah, it's a distinction worth making, and the language for making it kind of sucks. Vibe coding means "AI does the whole thing", or "I use tab autocomplete" depending on who you ask. It's not a very useful term anymore, we need better ones.

My benchmark is basically, "are you letting the AI drive."

In this case, an AI appears to have written the migration guide...

"Vibe coding" = "let Dario take the wheel" as ThePrimeagen puts it.

You are right but recently, vibe coding has become a demeaning term for AI assisted code by anti-AI people. It’s interesting seeing how words evolve very quickly on the internet as they spread to different demographics.

That is one person's definition of vibe coding, not "the definition" of vibe coding. Words have multiple meanings.

> it requires a hands-on approach and actually understanding what's being built.

I think this is true regardless of what language you’re using.

I’ve built a lot in Zig and there’s no difference between vibing stuff in it versus TypeScript/React. Claude can “one-shot” them both, and will mimic existing code or grep the standard library to figure everything out.

> unless you feed it source

Which isn't particularly difficult - the language docs and std source come with the installation, so all you need to do is tell Claude where those directories are in your skill/plugin/CLAUDE.md.

> and guide it closely (in which case it's useful for focused work)

It does struggle sometimes with writing code that compiles and uses the APIs correctly. My approach to that so far has been to write test blocks describing the desired interface + semantics, and asking Claude to (`zig test` -> fix errors) in a loop until all the tests pass.

The Rust ecosystem is also a moving target.

Virtually all crates are still at version 0.x and introduce constant breaking changes: [https://00f.net/2025/10/17/state-of-the-rust-ecosystem/](https://00f.net/2025/10/17/state-of-the-rust-ecosystem/)

If you don’t want to use obsolete versions of dependencies, you need to explicitly tell the model that. Then you have to hope it can adopt new APIs it wasn’t trained on, rewrite existing code to handle the breaking changes, and keep your fingers crossed that nothing else breaks in the process.

LLMs perform much better with Go, not only because of the lack of hidden control flow (LLMs can deal with that, but it costs a lot of tokens) but mainly because both the language and its dependencies introduce very few breaking changes.

I wouldn't call any port "prudent". In general, taking mature software and doing any major rewrite is one of the riskiest thing you can do. It is a large scale attempt to fix what isn't broken.

Sometimes it is worth it, but it may also kill projects. A risky move. And AI doesn't help its cause. AI can save a lot of time when making ports, it is one of the things it does best, but it doesn't protect from regressions.

I am not using Bun in production, but if I was, I would consider it a risk. Not because of Rust vs Zig, but for changing things that work.

This is likely irrelevant given bun has stopped taking community PR's entirely and Jarred is pitching that human contributors should be banned.

Why didn't they use Rust in the first place then ? All this was true before AI

I don't think Zig is different enough from rust or any other systems language for it to matter. If you can write rust you can write Zig.

100%. For many people, Bun is the only reason they've even heard of Zig. I'm not in a position to comment intelligently on comparative language features per se, but when it comes to mindshare and community size, Rust is a clear winner.

I have no doubt that LLMs are good at Rust.

But I can’t reconcile the reasoning about “strong, thorough compiler” with the fact that LLMs are also fantastic at Ruby.

They also write really great posix shell (including very sophisticated scripts) and python.

Something more subtle is going on.

But there isn't any change in someone's expertise in Bun though, currently, just in development. Why would they have to dive you into a daily stand-up about their development process?

That the incentives have changed after being bought by Anthropic. So don't be surprised by a sudden change of heart.

The definition is at https://x.com/karpathy/status/1886192184808149383 and no that does not match what is in the branch. Systemically migrating a code base using an LLM does not match the defintion of vibe coding.

There's a decent article by Simon Willison that talks about this: https://simonwillison.net/2025/Mar/19/vibe-coding/

> I’m seeing people apply the term “vibe coding” to all forms of code written with the assistance of AI. I think that both dilutes the term and gives a false impression of what’s possible with responsible AI-assisted programming.

The commit would look exactly like that if it was a 100% deterministic transpilation (like Golang did with their original C implementation?).

This is obviously very different from that, but the way the commit looks doesn't make it so.

Just another Monday in 2026.

The blind leading the blind.

I'm sure it will be called Systems Programing . Because Rust.

> How does manual reviewing affect whether or not it's vibe coding?

I think the most commonly-accepted definition of "vibe coding" is when you "forget that the (generated) code even exists"[0]. So vibe-ness entirely hinges upon whether you're manually reviewing. If you make/prompt changes based on what you observe in the generated code (rather than only based on runtime behavior), then you're not "vibe coding".

I think the other things you mentioned are orthogonal to vibe-ness.

[0]: https://en.wikipedia.org/wiki/Vibe_coding#Definition

This is just a matter of priorities - I use LLMs to write code every day and I have never put a single line of code up for review that I didn’t read and understand.

Not to mention that manually writing code is itself a process of understanding. It cannot be replicated by reading code, no matter how carefully.

While I'm sure you're speaking for many, this is definitely not true across the board.

[dead]

This is all wild conjecture, but I'd assume that teaching the LLM to do that mapping is an achievable goal and then it get's close to automatic -- effectively slurp the source AST into a rust AST and render.

My only experience with ports so far is Python to Go, and it's been near flawless (just enough stupid shit to make me feel justified to be in the loop).