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

351–360 of 496 posts

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

#351

Post by ModernMech »

em-bee wrote: post #292
renticulous wrote: post #256

Earlier quoted context omitted.

Can't we reach a compromise where proven track record of good use of LLM by a contributor or a company (eg. Bun) be pre-approved or entertained? Blanket ban on a new technology shouldn't be the default option.

if they had a good track record, the current submission that led to this article damaged it. i am reminded of this quote: it takes more cleverness to debug code than it takes to write it. if you write code as clever as you can, by definition you are not clever enough to debug it. using LLM makes your code many times more clever than what you could write yourself. which means by the same definition the code is to clev…

I like the new corollary to that rule, which is that if the AI is the best coder in the room and writes code too clever for itself, then no one including the AI can debug the code. Then where does that leave you?

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

#352

Post by em-bee »

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?

why bother even contributing anything LLM generated if it won't get accepted?

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

#353

Post by all2 »

jbxntuehineoh wrote: post #342
secondcoming wrote: post #179

Earlier quoted context omitted.

"Claude, don't create any technical debt please"

i've been told that it's totally fine because once the codebase turns into spaghetti you can simply tell the agent to refactor it and then everything will be ok

I know this is a tongue-in-cheek response, but this brings me great pain. The spaghetti begins quickly, and your unit/functional tests won't help you unless you hammered out your module API seams before you even began. Oh, your abstractions are leaking? Your modules know too much about each other? Multiply the spaghetti!

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

#354

Post by ejpir »

jcgrillo wrote: post #184
wallst07 wrote: post #153

Earlier quoted context omitted.

Fanbase, maybe. Software engineers using these projects? Probably forking and updating themselves. FWIW, I've opened a half dozen PRs from LLMs and had them approved. I have some prompts I use to make them very difficult to tell they are AI. However if it is a big anti-llm project I just fork and have agents rebase my changes.

Your employer allows/encourages this? Do you run that stuff in production? Would you mind telling us where you work so we can avoid using their products? It is just not possible to trust the software that emerges from the process you've described.

so, they are approved, which means they were most likely reviewed. yet you still think the software cannot be trusted of that and even want to name and shame a company. utterly stupid.

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

#355

Post by all2 »

jmcqk6 wrote: post #320
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…

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.

Can't you prevent pushing from the client side with pre-commit hooks? I would expect a hook to fire on the developer's computer that prevents them from even committing/pushing (unless they nuke the hook in their local repo copy).

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

#356

Post by brokencode »

merlindru wrote: post #336
brokencode wrote: post #287

Earlier quoted context omitted.

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

Well previously lazy contributors simply would never have made a PR because it was too much work. Now they can have an LLM make a PR with virtually no effort at all.

It’s obviously an imperfect rule, and maybe it’ll change over time. But I am just saying that I understand why open source maintainers are doing this.

There is just no possibility for them to review all the low effort AI slop being thrown their way. Yes, some of it is going to actually be very high quality, but you don’t know that until you review it, which is the whole issue.

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

#357

Post by jcgrillo »

ejpir wrote: post #354
jcgrillo wrote: post #184

Earlier quoted context omitted.

Your employer allows/encourages this? Do you run that stuff in production? Would you mind telling us where you work so we can avoid using their products? It is just not possible to trust the software that emerges from the process you've described.

so, they are approved, which means they were most likely reviewed. yet you still think the software cannot be trusted of that and even want to name and shame a company. utterly stupid.

Yes. If a company is running vibeslopped compilers to build their production artifacts I absolutely want to know which one it is, so I can protect myself from their software.

> utterly stupid

That's completely uncalled for.

EDIT: What exactly do you mean by:

> most likely reviewed.

Let's say every line was actually reviewed. That's still nowhere near good enough. The changes are being reviewed by the wrong people. Not the maintainers of the project, just some random folks who have inherited a vibecoded fork.

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

#358

Post by em-bee »

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

Earlier quoted context omitted.

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…

>because if you could understand it, then you could write it yourself. I accept most things you said there as valid opinions, but this is where the logic goes wrong. I use LLMs to give me more from the only resource (now that my basic and mid-level needs are largely met) that ultimately matters: time. That means that I need to waste far less time in front of the computer, typing code, and use far more time doing more…

you are saying that even if you understand the code, using an LLM saves you time writing it. fair enough[*]. the problem on my side still is that if you didn't write the code yourself, i have no evidence that you actually understood it. the only way to prove that you understand the code is to write it yourself. that's where the trust building comes in. you may actually understand the code, but i can't trust that you do.

[*] in my opinion it takes more time to verify that the LLM code is correct than it takes to write it yourself. based on that, if you save time using an LLM then you didn't spend enough time to verify that the code is correct.

Some open-source communities have clearly entered the attacking phase in the last year so

i feel it's more like defense, but yes.

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

#359

Post by logicchains »

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…

>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

Because getting an LLM to do it yourself still takes time and attention bandwidth and tokens.

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

#360

Post by silentkat »

ghosty141 wrote: post #343
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…

Exactly my (and my coworkers) experience. AI generally amplifies the skillset, both in the good and the bad. One fantastic usecase for me just recently was writing up a concept for an authentication daemon. With codex this is like a conversation where I pick from the suggestions, cross reference them with normal web-search and decide on a final draft which I then discuss with colleagues. This "conversational" plannin…

The power of AI is it rewards due diligence.

The weakness of AI is that it is really easy to fall into lazy habits.

Something about having to talk to a machine like it's a human makes me fall for treating it like a human. I want to treat it as a probability engine that collapses to an answer based on input, but that input explicitly needs to be one that has it collapse to something a reasonably knowledgeable person would respond with, which more-or-less means talking to it like it is that kind of person.

I feel like it activates the social part of my brain and then I stop working with it properly. I'm still building the habit, though, only recently started taking the LLMs seriously as a tool.

Post reply on HN