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

11–20 of 496 posts

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

#11

Post by simonw »

jart wrote: post #3

> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the…

> Why use someone's project when you can just have the robot write your own?

I've been thinking about this a bunch recently, and I've realized that the thing I value most in software now isn't robust tests or thorough documentation - an LLM can spit those out in a few minutes. It's usage. I want to use software which other people have used before me. I want them to have encountered the bugs and sharp edges and sanded them down.

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

#12

Post by bonzini »

hitekker wrote: post #8

Apparently, the noise around the AI policy came from Bun's developers saying that policy blocks upstreaming their performance PR. But the real reason seems to be that PR's code itself isn't in great shape, and introduces unhealthy complexity https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... > Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time, and it ha…

A single PR for a 3000-line addition would, in all likelihood, be rejected anyway.

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

#13

Post by feverzsj »

mapontosevenths wrote: post #7
jwzxgo wrote: post #2

[dead]

> unless it's coming from a known and trusted developer. That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed. A general ban makes sense based on their rationalization ("contributor poker"[0]). A total and inflexible ban can lead to a worse outcome for everyone though. If a senior, experienced, contributo…

Quite the contrary, Bun's developers don't even understand language spec. Their slop didn't use the same type resolution semantics as Zig, which makes their implementation exhibits non-deterministic behavior.

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

#14

Post by superb_dev »

JoshTriplett wrote: post #9
mapontosevenths wrote: post #7

Earlier quoted context omitted.

> unless it's coming from a known and trusted developer. That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed. A general ban makes sense based on their rationalization ("contributor poker"[0]). A total and inflexible ban can lead to a worse outcome for everyone though. If a senior, experienced, contributo…

https://news.ycombinator.com/item?id=47958209

A standout paragraph from that thread:

> Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions.

These exact changes are already on the roadmap and Bun’s PR is rushing ahead.

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

#15

Post by mapontosevenths »

JoshTriplett wrote: post #9
mapontosevenths wrote: post #7

Earlier quoted context omitted.

> unless it's coming from a known and trusted developer. That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed. A general ban makes sense based on their rationalization ("contributor poker"[0]). A total and inflexible ban can lead to a worse outcome for everyone though. If a senior, experienced, contributo…

https://news.ycombinator.com/item?id=47958209

Thanks. That explains away most of my concern.

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

#16

Post by bee_rider »

jart wrote: post #3

> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the…

Most people don’t have the ability to read code well enough to determine if an LLM output is good or not. And most people don’t have subscriptions to models that can develop non-trivial programs…

Maybe this will be a real problem in a couple years though.

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

#17

Post by lmm »

mapontosevenths wrote: post #7
jwzxgo wrote: post #2

[dead]

> unless it's coming from a known and trusted developer. That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed. A general ban makes sense based on their rationalization ("contributor poker"[0]). A total and inflexible ban can lead to a worse outcome for everyone though. If a senior, experienced, contributo…

> If a senior, experienced, contributor vouches for the code it shouldn't matter if they hand crafted it on stone tablets, generated it with yarrow sticks, or used gpt-3.

The flip side of that is that if such a contributor vouches for code that turns out to be poor-quality, this should severely damage their reputation. I've found far too many "senior" developers will give AI a pass on poor coding practices.

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

#18

Post by skeledrew »

jart wrote: post #3

> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the…

LLM access is not yet universally available. There are those who can't exactly afford it. And there are also those with access but there are occasional or perennial issues, like Claude outages and general degraded performance over time. For example couple of months ago when I just started using Claude, I was easily making good progress on multiple projects within a week. Nowadays I'm hardly getting through much of anything as most of the time Claude is just showing spinners, and it also feels like the code quality has taken a nosedive.

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

#19

Post by felipeerias »

The other side of this is that open source projects that allow AI tools will be more restrictive towards new contributors.

This already happens to some degree on large software projects with corporate backing (Web engines, compilers, etc.), where it is often not trivial to start contributing as an independent individual.

Reasonable people can disagree on whether one approach is inherently better than the other, as ultimately they seem to be optimising for different goals.

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

#20

Post by 8n4vidtmkvmk »

gausswho wrote: post #6
jart wrote: post #3

> This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the…

That only holds true for the smallest tier of open source projects. Past a certain point of complexity, it's unlikely you can expect the robot to read your mind well enough to provide something of high quality and 'outstanding for just you'. The Zig project is certainly far beyond such capability.

I'm finding this out the hard way. I set out to build a 1 page app. I thought it would take a day. It's 98% vibe coded at this point. Even with AI implementing everything, its taken several weekends and many evenings. And not because AI is doing a bad job its just that as i see it come together, i have more and more feature requests. I've got a couple dozen left but I can't just let the AI chew through them all at once. Im effectively QA now. Have to make sure everything is just right.
Post reply on HN