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

311–320 of 496 posts

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

#311

Post by minimaxir »

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.

That isn't how LLM training has worked for some time. There's a reason the LLM boom didn't take off until training was separated into pretraining (training on all data) and posttraining (RLHF to make the output actually aligned).

It's also why model collapse is not a thing despite everyone wanting it to be.

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

#312

Post by Bridged7756 »

dannyw wrote: post #163
sesm wrote: post #143

Earlier quoted context omitted.

People who have skill can do the same without LLMs, maybe slightly slower on average but on more predictable schedule.

I wouldn’t say slightly slower; LLMs are massively useful for software engineering in the right hands. For some personal projects I still stick to the basics and write everything by hand though. It’s kinda nice and grounding; and almost feels like a detox. For any new software engineer, I’m a strong advocate of zero LLM use (except maybe as a stack overflow alternative) for your first few months.

It's significantly slower to use LLMs for some things. The only thing it excels at is generic, broad tasks. Getting the 90% done. I find that it's less cumbersome to get it mostly right and touch it up yourself than to prompt over details like syntax.

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

#313

Post by zeeveener »

branko_d wrote: post #91

From https://kristoff.it/blog/contributor-poker-and-ai/ : "Unfortunately the reality of LLM-based contributions has been mostly negative for us, from an increase in background noise due to worthless drive-by PRs full of hallucinations (that wouldn’t even compile, let alone pass CI), to insane 10 thousand line long first time PRs. In-between we also received plenty of PRs that looked fine on the surface, some of which…

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 popularity.

It feels like a lot of the "AI is shit at contributing" problems could be addressed in part by better automated checks and balances.

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

#314

Post by notnullorvoid »

chenzhekl wrote: post #156
grokys wrote: post #152

My issue with AI-generated OSS contributions is: If an AI improves developer productivity so much, why would maintainers of an OSS project want unknown contributors to sit in between the maintainer and the LLM? They'd be typing these queries into Claude Code themselves. To quote my colleague: > We do not need a middleman to talk to AI models. We are not bottlenecked by coding.

maybe you are not bottlnecked by coding. but there is high probability that you will be bottlenecked by verifying the correctness of LLM-generated code.

If you are a responsible maintainer you need to verify the correctness of the contribution wether you used an LLM to generate it or wether someone else did.

Having someone else be the AI-middlemen, just introduces additional complexity and confusion.

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

#315

Post by Bridged7756 »

ericjmorey wrote: post #305
ZaoLahma wrote: post #172

Earlier quoted context omitted.

I'm starting to notice how those who don't use AI end up having to hand tasks over to people who can get them done quicker. It is anecdotal for sure, but it's a pattern that seems to be emerging around me that expectations of velocity increases, and those who don't use AI can't keep up.

Why is velocity the overriding goal?

Shit processes. I don't know what places most of those people work at that crap is being merged into production at insane pace. You would expect any serious piece of software would be important enough to have the code be reviewed by at least one human.

Kind of.... I don't know. To get placed such requirements from the top down and not fight back, just take it head on, not even maliciously, don't even oppose it on a technical basis, just be like "yeah, you've now gotta ship faster or you're left behind, so therefore LLMs must be the future!", no critical thought attached. Is this shit coming from experienced engineers?

Preposterous we're relying on "it's better because I feel like", "dudes who don't use it are falling behind at work", "they ask for it in job interviews".

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

#316

Post by [deleted] »

em-bee wrote: post #304
vga1 wrote: post #121

Earlier quoted context omitted.

It seems to me that people might be arguing from conflicting hidden premises here. "AI Coding" is a spectrum that could mean something as simple as letting the LLM proofread your changes and then act on those with your own human brain, or it could mean just telling the agent what you want and let it rip and tear until it is done. If I do the latter and submit a PR to something like Zig, I'll be certainly caught doing…

Blanket banning all of these seems like a bad idea to me. It actively gates people like myself from contributing in my projects i will reject any contribution that i do not understand. even if the contribution is handwritten by an expert developer. that developer will have to earn my trust like anyone else, like you would have too. LLM contributions are non-deterministic, which means they can never be trusted. theref…

[deleted]

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

#317

Post by [deleted] »

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…

[deleted]

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

#319

Post by Bridged7756 »

chenzhekl wrote: post #156
grokys wrote: post #152

My issue with AI-generated OSS contributions is: If an AI improves developer productivity so much, why would maintainers of an OSS project want unknown contributors to sit in between the maintainer and the LLM? They'd be typing these queries into Claude Code themselves. To quote my colleague: > We do not need a middleman to talk to AI models. We are not bottlenecked by coding.

maybe you are not bottlnecked by coding. but there is high probability that you will be bottlenecked by verifying the correctness of LLM-generated code.

Crazy how this doesn't register in people's heads. Has the real bottleneck ever been code written and not the review of code and everything involved? Understanding the nuance and implications behind design decisions; strategy.

In any REAL, workload, with good processes, code review makes speed of code generated a moot point. You still move as fast as you can review the code, and no, I won't debate that you can rely on LLMs, a deterministic language predictor, to determine the correctness of code; in the context of the business, and technical implications.

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

#320

Post by jmcqk6 »

zeeveener wrote: post #313
branko_d wrote: post #91

From https://kristoff.it/blog/contributor-poker-and-ai/ : "Unfortunately the reality of LLM-based contributions has been mostly negative for us, from an increase in background noise due to worthless drive-by PRs full of hallucinations (that wouldn’t even compile, let alone pass CI), to insane 10 thousand line long first time PRs. In-between we also received plenty of PRs that looked fine on the surface, some of which…

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…

Those things cost resources, and now you're introducing a new attack vector: open up a bunch of shit PRs, burn a lot of cash for the target organization.
Post reply on HN