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

481–490 of 496 posts

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

#481

Post by zeeveener »

schmichael wrote: post #412
zeeveener wrote: post #387

Earlier quoted context omitted.

You're right. It doesn't solve for all scenarios and doesn't block malicious actors. I do believe, however, that it would have a meaningful impact on the "drive-by" PRs that keep being used as examples; the thoughtless, throw-spaghetti-at-the-wall PRs that do not have malignant intent behind them. Many large OSS projects would have the resources to eat that cost with Donors, Sponsors, and OSS hand-outs. That's why I…

The problem is you can get the LLM to iterate until it compiles and lints and even passes LLM review, but will that actually improve the quality of the contribution or just produce more line noise to mechanistically meet criteria? To large complex projects often the kernel of an idea is the core value of a contribution, and it can take a lot of iteration to figure out how to structure it. Token bashing until CI is gr…

For sure, but that's not what I was referring to in my posts. I'm specifically referring to the callout that the contributions are so low quality they don't even pass linting or compile.

I could have been more explicit on that nuance, I suppose.

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

#482

Post by sieabahlpark »

PeterStuer wrote: post #462

I know my take on this is not popular. Don't blame the tool, judge the output. Ofc, the scattershot 10k changes PR touching 30% of all your code files can be auto rejected without even looking at it. Who cares who or what wrote it. And a small focusses PR from a new contributer that needs clarification which the author can not provide, shelve it. But a blanket no-ai policy? I hear echos of business execs refusing ema…

[dead]

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

#483

Post by thesz »

vehemenz wrote: post #226
dgellow wrote: post #164

Earlier quoted context omitted.

I generally do have that mindset, but over the past 1y of Claude code I do notice that I’m clearly losing my understanding of the internals of projects. I do review LLM generated code, understand it, no problem reading/following through. But then someone asks me a question, and I’m like… wait, I actually don’t know. I remember the instructions I gave and reviewing the code but don’t actually have a fine-details model…

I've had this issue too, and I feel it was an important lesson—kind of like the first time getting a hangover. On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).

  > On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
Writing and rewriting piece of software performs what is called "spaced repetition" [1].

[1] https://en.wikipedia.org/wiki/Spaced_repetition

You ask questions about code when you implement something and if you cannot answer these questions, you go to code to find answers out and refresh your understanding of it.

For this to work you have to be interested in the understanding of the code and code should be created at the pace you can keep up.

Software engineers usually do create code economically because they need to remember and understand it. Vibe coders do not have this particular constraint, they just do not aim for most understandable code possible. Even if there are more comments in code.

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

#484

Post by saulpw »

solid_fuel wrote: post #452
amelius wrote: post #186

Earlier quoted context omitted.

Where is the real bottleneck, if I may ask?

> verifying the correctness of LLM-generated code It's... pretty clear in the original conversation.

I find that people who write "may I ask" are often/usually bad-faith arguers under cover of being polite.

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

#485

Post by krupan »

yjftsjthsd-h wrote: post #464
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…

> 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 Is the barrier to entry really that you must be able to perfectly recreate the project from scratch before you can possibly have anything to contribute?

No, and sorry if that's what I implied, but most of the work that needs to be done on cutting edge software like zig, most of the little tasks, are things LLMs have never been trained on. They will struggle to do even small tasks correctly if the small task is something they haven't been trained on. And of course the worst part about it is they will lie the whole time, telling you they can do it, that they did it, that it works, when none of those are true.

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

#486

Post by krupan »

umvi wrote: post #414
krupan wrote: post #384

Earlier quoted context omitted.

That was a lot of words to agree with me that LLMs don't invent new things

OP said "The next generation of developers will, for better or worse, grow up using AI assistance to write their code, but none of them will ever become a Zig contributor." You rebutted with (paraphrasing) "no, you can't build compilers with LLMs because LLMs don't invent new things" I used a lot of words to demonstrate that you can invent new things with LLMs, including compilers, as long as it's a human + LLM itera…

To me it sounds like you did all the actual hard work of the inventing. If an LLM brainstormed some ideas and you validated which ones worked and implemented the idea and fully grokked the code then the zig developers probably wouldn't ever know that an LLM was involved and you'd be fine to contribute.

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

#487

Post by solid_fuel »

saulpw wrote: post #484
solid_fuel wrote: post #452

Earlier quoted context omitted.

> verifying the correctness of LLM-generated code It's... pretty clear in the original conversation.

I find that people who write "may I ask" are often/usually bad-faith arguers under cover of being polite.

That's a good rule of thumb, it seems that way more often than not.

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

#488

Post by sethammons »

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…

There are lots of reasons to commit when things are yet working. How else would you share code that you need help with?

The solution is gated merges. No merging to main unless ci passes.

Every org I have worked at bemoaned a flaky release process and refused e2e black box acceptance tests because "they are too slow." And every org I have worked at has realized they were wrong. We got appropriate gates that run in 5 minutes and an ops person is the only person who can force past any gate in case of emergency.

Guardrails like this only become more important with the accelerant that is ai.

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

#489

Post by pdimitar »

hirako2000 wrote: post #425
aerhardt wrote: post #403

Earlier quoted context omitted.

You're at least describing someone who sounds hard-working... what's the problem? I'd be more concerned if I was someone who signed up to play ping pong two hours a day and do a bi-weekly commit. There was a time not so long ago where I was watching "a day in the life of a software engineer" videos on Youtube and I was wondering if some of these were parodies. I still remember one in particular which I'm pretty sure…

I do believe in hardship. As sacrifice. It yields long term benefits for oneself, and for society. But submissions into slavery for immediate gain accomplishes little, and costs society a lot more (physical and mental health issues are a huge burden). Those parodies you saw, they were caricature of elite engineers, who sacrificed decades of his life to become so competent. Can work from home, eat pasta while glancing…

I've met programmers who severely outclassed me. It was extremely uncomfortable and it took me months to accept that reality and reshape my hurt ego into curiosity and desire to learn from someone clearly superior in the craft.

That being said, most people in the privileged positions you described are there by sheer luck and connections. In the very very best-case scenario that offends them the least: they stumbled upon an opportune position and were smart enough to make full use of it... in the first 6 months (when people pay the most attention and lasting impressions are formed). And then rode the reputation they made for years. Their value as engineers on the team after the initial honest burst of productivity becomes... very unclear from that point and on, shall we say.

Again, I've met engineers who fully deserved their privileges. 2-3 times over 24 years of career though (a good chunk of it as a contractor so I've been around). My anecdotal evidence obviously means nothing but we all develop pattern-matching skills with time, making me think what I saw is generally the statistical curve that would apply almost everywhere. Maybe.

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

#490

Post by stirfish »

i_love_retros wrote: post #472
stirfish wrote: post #239

Earlier quoted context omitted.

It's great when I know how the code should look. Sometimes I just can't bring myself to write yet another http handler.

Already libraries for that which are battle tested, why vibe code a unique solution each time?

Pretend I said "crud handlers using i_love_retros's favorite library" or whatever makes the most sense for you.
Post reply on HN