Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Zig project's rationale for their anti-AI contribution policy

simonwillison.net

Post reply on HN
Print view View original

331–340 of 496 posts

Re: The Zig project's rationale for their anti-AI contribution policy

#331

Post by abustamam »

debarshri wrote: post #327

We have been running LLM and coding agents for a while now and my overall observation is that it is a powertool or a crane, it is not a decision making tool. Now in my org, people who have great understanding of concepts, deeper engineering understand have exponential productivity. People who dont or new in the workforce, juniors, are generating hell-ish code without understand as long as it runs they think the job i…

This is my experience. I'll use LLMs as a sounding board for architectural decisions and to bring discussion points up to the team, and we talk through assumptions and pros and cons. And then once we have the architecture in place, LLMs are pretty good at implementation.

Re: The Zig project's rationale for their anti-AI contribution policy

#332

Post by sauercrowd »

abustamam wrote: post #328
sauercrowd wrote: post #321

Earlier quoted context omitted.

I mean even having linters and everything still creates a whole bunch of noise in their PR section, not to mention that a lot of the changes I make to stuff that's written by codex is not stuff that's caught by linters. It's just bad/wrong/context lacking decisions and mental models it introduces, that if not carefull will just create a massive mess of a codebase. (I know, because I've tried, and had to deal with it)…

Vibe coding is often not a single prompt, it's an entire workflow (if you're doing it right).

Don't disagree, but the "if you're doing it right" is a big asterisk for an open source project with people you have no idea what quality bar they're at.

And in my experience it's quite hard to figure that out by quickly looking at it.

Not to mention that contributions on github (almost?) never include the prompt chain anyway, so the status quo is even worse

Re: The Zig project's rationale for their anti-AI contribution policy

#333

Post by hansvm »

krupan wrote: post #306

This is the great disconnect in thinking around LLMs right now. You have people saying they are so amazing, why wouldn't you use them? But if they are so amazing, why are you mad when someone won't accept the code they produce? Just ask the LLM to duplicate that whole project! Oh, it's not actually that amazing of a tool? Hmmm The fact is, LLMs are incapable of invention and synthesizing new ideas. They can't contrib…

> The fact is, LLMs are incapable of invention and synthesizing new ideas.

I don't think it's fully appreciated how much of the hard work of "synthesizing a new idea" is just combining existing ideas. LLMs have given me brand new algorithmic ideas with precious little in the way of a spark on my end to make that happen, and not just a few times either.

Mind you, that workflow is arduous and involves a huge amount of experimentation, screening through interesting but ultimately wrong ideas, screening through outright bad ideas the LLM can't help but spew out as well, and manually massaging the results into something useful. It exists though.

Re: The Zig project's rationale for their anti-AI contribution policy

#334

Post by jwolfe »

papyrus9244 wrote: post #323
zeeveener wrote: post #313

Earlier quoted context omitted.

I'm personally amazed that _Large_ OSS projects don't have the appropriate automation in place to prevent non-compiling or non-linter-passing submissions. - Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges). This might be my bias showing, but these are items I would consider table-stakes for a project of a certain size / level of popu…

One of my pet peeves with git (and systems both similar, and based on it) is that automated tests run after you've made the commit and push. In my mind the commit (let alone the push to a publicly accesible server) should be done after, and only if, the automated tests are successfully executed. And there's no easy way to implement this, other than having a dirty branch that you discard after rebasing onto a more lon…

Pre commit hooks exist. People just don't like being prevented from committing for reasons such as this.

Re: The Zig project's rationale for their anti-AI contribution policy

#335

Post by bojo »

WarmWash wrote: post #295
discreteevent wrote: post #110

Earlier quoted context omitted.

I don't think it's the complete fanbase. However, there are lots of people in the world who live their whole life by vibing. It's a viable way to live and sometimes it's the only way to live. But they have a very loose relationship with truth and reason. Programming was a domain that filtered out those people because they found it hard to succeed at it. LLM's have changed that and it's a huge problem. It's hard to kn…

Tangential side story, but an interesting one none the less. I was a food delivery driver back in the mid 00's to the mid teens. Early on, GPS was rare and expensive, so to do deliveries and do them effectively, you had to be able to read a map and mentally plan out efficient routes from the stochastic flow of orders coming out. This acted as a natural filter, and "delivery driver" tended to be an interesting class o…

I love this anecdote. It highlights what our industry continues to forget: The end user doesn't care.

Don't get me wrong, tech is why I am here. But if it works, Alice and Bob don't care one bit about how the product exists.

Re: The Zig project's rationale for their anti-AI contribution policy

#336

Post by merlindru »

brokencode wrote: post #287
dack wrote: post #285

I think it's the least hostile thing they can say, and I respect their decision for their own project. That said, it still feels like they are unnecessarily hobbling their project. LLMs are tools and they can help you think, research, and code. You can overuse them, yes, but you should embrace them where they help. not accepting bun's PR for other reasons is totally fine (sounds like it's a core change where more thi…

Why review thousands of lines of LLM generated code from some random person you don’t know when you could use an LLM yourself to do the same thing, except with probably a better design and more thoughtful approach? Maintainers should get to spend their time developing stuff, not just reviewing low effort PRs. The flood of LLM code is changing the balance for the worse for maintainers, and I can totally see why they’d…

but that doesn't have anything to do with LLMs.

if someone made the same gigantic mess of a PR without LLMs, it would still be rejected, because it is a gigantic mess of a PR.

the low effort part is the problem. what if i made a great, focused, readable PR but had claude write it out? what if i carefully checked and deliberated each line, just as if i had written it myself?

granted, in the real world, 99.9% of slop PRs are written by LLMs. so i thought "okay, reasonable, ban the thing that is most likely to cause problems."

but then how does the "no LLM translators!" rule fit into that view?

Re: The Zig project's rationale for their anti-AI contribution policy

#337

Post by abustamam »

sauercrowd wrote: post #332
abustamam wrote: post #328

Earlier quoted context omitted.

Vibe coding is often not a single prompt, it's an entire workflow (if you're doing it right).

Don't disagree, but the "if you're doing it right" is a big asterisk for an open source project with people you have no idea what quality bar they're at. And in my experience it's quite hard to figure that out by quickly looking at it. Not to mention that contributions on github (almost?) never include the prompt chain anyway, so the status quo is even worse

That's a fair point. I was just speaking generally.

Re: The Zig project's rationale for their anti-AI contribution policy

#338

Post by simonw »

khat wrote: post #265

The problem with AI generated code is that the code the data model was trained on almost exclusively comes from public repositories. And there's a lot of repositories that are absolute dog $h!t or out dated. Crap in equals crap out.

OpenAI and Anthropic spent almost all of 2025 running RL to improve the coding abilities of their models - which involves running thousands of VMs that execute generated code to see if it works.

That's why the code you get from the post-November models is so much better than older models.

Re: The Zig project's rationale for their anti-AI contribution policy

#339

Post by mattmanser »

JackC wrote: post #204
discreteevent wrote: post #110

Earlier quoted context omitted.

I don't think it's the complete fanbase. However, there are lots of people in the world who live their whole life by vibing. It's a viable way to live and sometimes it's the only way to live. But they have a very loose relationship with truth and reason. Programming was a domain that filtered out those people because they found it hard to succeed at it. LLM's have changed that and it's a huge problem. It's hard to kn…

"They may speed up the good programmers a little, but those people were able to program anyway without LLMs." I don't think this is realistic. I'm a good programmer, and it speeds up my work a lot , from "make sense of this 10 repo project I haven't worked on recently" to "for this next step I need a vpn multiplexer written in a language I don't use" to, yeah, "this 10k line patch lets me see parts of design space we…

Why are you writing a vpn multiplexer written in a language you don't use?

You can't review it.

Are you relying on your colleagues to do that, or is this riddled with bugs? Or is it code you're producing for personal use only so it's not worth mentioning as it's not sped your work up, it's just let you write a little play program.

Re: The Zig project's rationale for their anti-AI contribution policy

#340

Post by 10000truths »

papyrus9244 wrote: post #323
zeeveener wrote: post #313

Earlier quoted context omitted.

I'm personally amazed that _Large_ OSS projects don't have the appropriate automation in place to prevent non-compiling or non-linter-passing submissions. - Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges). This might be my bias showing, but these are items I would consider table-stakes for a project of a certain size / level of popu…

One of my pet peeves with git (and systems both similar, and based on it) is that automated tests run after you've made the commit and push. In my mind the commit (let alone the push to a publicly accesible server) should be done after, and only if, the automated tests are successfully executed. And there's no easy way to implement this, other than having a dirty branch that you discard after rebasing onto a more lon…

You can use a pre-receive hook on a git server to reject pushes that fail compilation. Downside is that it requires admin access on git forges, so you're only able to do this if you self-host.
Post reply on HN