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

71–80 of 496 posts

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

#71

Post by baq »

> 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?

perhaps that's what the maintainers should be doing after all. it still takes time and tokens, though; neither is free.

I'd personally rather have the maintainers spend the time writing as much docs and specs as possible so the future LLMs have strong guardrails. zig's policy will be completely outdated in a couple years, for better or worse. someone will take bun's fork, add a codegen improvement here, add a linker improvement there and suddenly you'll have a better, faster zig outside of zig.

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

#72

Post by jart »

LeCompteSftware wrote: post #25
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…

>> Whereas earlier you had to use something that was mass produced to be satisfactory for everyone As someone who recently started using OpenSCAD for a project I find this attitude quite irritating. You certainly did not "have to" use popular tools. The OpenSCAD example is particularly illuminating because it's fussy and frustrating and clearly tuned towards a few specific maintainers; there's a ton of things I'd lik…

Anthropic will probably do what Google did in the 2000s, which is give jobs to all the open source developers whose work helped them get there.

Civilization isn't monotonic. People keep solving the same problems over and over again, telling the same stories with a different twist. For example in 1964 having a GUI work environment with a light pen as your mouse was a solved problem on IBM System/360. They had tools similar to CAD. So why don't we all just use that rather than make the same mistakes again. Each time a new way of doing things comes out, people get an opportunity to rewrite everything.

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

#73

Post by baq »

lelanthran wrote: post #68
Aeolun wrote: post #43

Earlier quoted context omitted.

Of course the policy is preventing the merge. That’s literally the point of the policy…

> Of course the policy is preventing the merge. That’s literally the point of the policy… In this case it isn't the blocker - the fact that the dev took the time to read the PR in detail, comment on it, and provide reasons why it could not be merged makes it very clear to me that the policy wasn't the blocker. If they were going to enforce the policy for this PR, they wouldn't have bothered to read it. The only reaso…

OTOH why bother to polish the PR if it won't get accepted anyway?

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

#74

Post by LeCompteSftware »

FeepingCreature wrote: post #48
LeCompteSftware wrote: post #25

Earlier quoted context omitted.

>> Whereas earlier you had to use something that was mass produced to be satisfactory for everyone As someone who recently started using OpenSCAD for a project I find this attitude quite irritating. You certainly did not "have to" use popular tools. The OpenSCAD example is particularly illuminating because it's fussy and frustrating and clearly tuned towards a few specific maintainers; there's a ton of things I'd lik…

This is funny because I was in the same situation, and actually used Claude to make a custom CAD program inspired by OpenSCAD :) https://fncad.github.io You definitely need to have a strong sense of code design though. The AIs are not up to writing clean code at project scale on their own, yet.

This is a good example of what I mean! fnCAD appears to be a significantly buggier and highly incomplete version of OpenSCAD, where AI essentially grabbed the low-hanging fruit - albeit an impressively large amount of fruit - and left you with the hard parts. I fail to see how this solved any problems. Maybe it was an experiment, which is fine. But it's not even close to a viable CAD product, even by OpenSCAD's scruffy FOSS standards, and there's no feasible way to get it there without a ton of human work.

Not trying to denigrate the work here, as such. But this certainly didn't convince me that using AI to replace OpenSCAD (or any other major open-source project) is a good idea. The LLMs still aren't even close to being able to pull it off.

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

#75

Post by mormegil »

earleybird wrote: post #41
simonw wrote: post #11

Earlier quoted context omitted.

> 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…

Depth of use over the lifetime of an app is a quality all its own that often not appreciated. A recurring pattern at $dayjob is that a new manager or director will join a business unit and declare an existing app as the worst terrible, no good, horrible app they've seen and they're going to fix that. A year and a half later the new app is finally delivered with 80% of the original functionality and a fresh set of bug…

Yes, see e.g. a quarter-century-old (!!) https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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

#76

Post by lelanthran »

baq wrote: post #73
lelanthran wrote: post #68

Earlier quoted context omitted.

> Of course the policy is preventing the merge. That’s literally the point of the policy… In this case it isn't the blocker - the fact that the dev took the time to read the PR in detail, comment on it, and provide reasons why it could not be merged makes it very clear to me that the policy wasn't the blocker. If they were going to enforce the policy for this PR, they wouldn't have bothered to read it. The only reaso…

OTOH why bother to polish the PR if it won't get accepted anyway?

> OTOH why bother to polish the PR if it won't get accepted anyway?

As the Zig maintainer so patiently explained, no amount of "polish" can fix the PR because it is misaligned to the correctness that they require.

IOW, that PR is so far off the reservation, unless it is completely rewritten, it won't be accepted.

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

#77

Post by KronisLV »

> 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?

That's a fair thing to ask, though it seems like people will arrive at very different conclusions there.

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

#78

Post by 000ooo000 »

throwa356262 wrote: post #54
slopinthebag wrote: post #36

Very convenient of Mr. Willison to omit the fact that Bun's upstream changes are total garbage and would not be upstreamed regardless of any policies, omitting LLM generated code or not, since they are, as a zig core team member articulated in a classier way, shite.

Also, that zig team is already working on other approaches that are better and more stable than what Bun team did: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Notable quotes:

>There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0!

>Each [incremental] update is taking less than 0.4s, compared to the 120+ seconds taken to rebuild with LLVM. In other words, incremental updates are over 300 times faster on this codebase than fresh LLVM builds are. In comparison, an enhancement capped at a 4x improvement is pretty abysmal. [..] Again, this feature is available in Zig 0.16.0—you can use it!

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

#79

Post by KronisLV »

thomascountz wrote: post #60
omnimus wrote: post #45

Earlier quoted context omitted.

When somebody comments PR with “Incredible work, Jacob. It is an honor to call you my colleague.” then it's safe to assume it's out of the ordinary contribution. Pretty much falling outside of the “in all likelyhood”. 3000 line LLM commit is not that.

No description provided . I love this PR. But yeah, try being anyone besides Jacob and submitting that!

> In successful open source projects you eventually reach a point where you start getting more PRs than what you’re capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don’t do this just because it’s the “right” thing to do, but also because it’s the smart thing to do.

I feel like if their goal is to prioritize contributors over contributions, it'd also logically follow that they should try to have descriptions where possible? Just to make exploring any set of changes and learning easier? Looked it over briefly, no Markdown or similar doc changes there either.

I mean the changes can be amazing, it's just that adding some description of what they are in more detail, alongside the considerations during development, for new folks or anyone wanting to learn from good code would also be due diligence.

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

#80

Post by f311a »

jillesvangurp wrote: post #32

It's a good rationale. But it points the finger at a real bottleneck in open source development: the burden of manually reviewing contributions. And the need to automate that with AI as well. Reviews were already becoming a problem before AI. Lots of projects have been dealing with a large influx of contributions from inexperienced developers from all over the world looking to boost their CVs by increasing their Gith…

You still have to review everything manually again anyway. It's a compiler for a language, bugs and bad architecture decisions cost a lot. They moved to codeberg, so there are less garbage PRs now. They try to grow a culture where you expected to deliver good code in the PRs so the review takes less time.

It takes like 5 minutes to spot garbage PRs manually. LLM can flood you with a wall of text where only half of the stuff make sense. Also, they can't really spot bad architecture. It's a compiler in an unpopular language, don't forget that.

Post reply on HN