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.

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,

C obviously.

Perl

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.

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.

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

Thanks, that is the answer.

What a sober, detailed forum post.

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

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

Stay away. Everyone wins.