I'm wondering if you foresee remaining open to new contributors or focusing on a trusted set of like minded contributors? How much time are you willing to spend enforcing this policy? (To put my cards on the table I think it's good for projects to pursue different and incompatible agendas and if you are volunteering to conduct this experiment I think that is great and genuinely wish you the best, I'm just wondering whether this will become a tarpit that either soaks up all of your time or makes onboarding new contributors take an inordinate amount of time.)

I agree with what you've shared here, regarding personal choice etc. Can you say more about "No LLMs for finding bugs." What are some downsides that you've experienced or are protecting against?

I really appreciate the thoughtful message of "these two coding styles are simply incompatible, and as the lead maintainer I'm using the non-LLM style". No hate or hard feelings for those that prefer the alternative.

I really wish a lot more of this debate could show that level of respect for the other side.

So you are completely open minded about any form of expression in the known universe and do not under any circumstances tolerate harassment, discrimination or exclusion…unless it involves AI/LLMs. Got it.

Go ahead, use all the LLMs in the world for finding bugs! It's not different than finding bugs by fuzzing, sitting with gdb, or receiving a revelation in your dream.

But then use your own brain to understand the bug, its implications, maybe ways to fix it. Again, use whatever tools, as long as your mind forms a clear understanding, which you can operate on independent on any LLMs or whatever.

The problem with "LLM bug reports" is that the submitters run a machine tool to find something that looks like a bug, but have a poor / no idea themselves what the issue is, and whether it's really an issue. It's easy to flood maintainers with such reports. The "no AI" policy pushes the responsibility of doing proper assessment onto you, the submitter.

If you can use LLMs to produce a bug report with the quality of assessment equal or above that of a diligent qualified human bug reporter, godspeed.

If an LLM finds a bug, is that almost the same as an LLM writing code for you? You can write lazy code as a sketch, for example without thinking about nested loops in your head, and then just use an LLM that will fix this loop in the bug report? This can be viewed as a level of AI usage: 10% (for example), where vibe coding is 100%. I think any percentage of usage affects your personal mental sharpness. We know that if something gained somewhere, something lost somewhere. The only question is where the "loss" is, and how it will affect everything and everyone.

Plus some of the issues are clearly written with LLMs, and apparently there's an active contributor who has been using LLMs to translate comments and help with code - https://github.com/ZigEmbeddedGroup/microzig/pull/1087:

> Yeah we know you're working with an LLM. That is fine (imo), as long as you're not doing drive-by slop PRs. These have been rather good quality, and you've been testing on hardware (which is important)

So it feels odd for them to suddenly change from this (clearly working) setup.

I'm actually seeing a lot less annoyance at this policy -vs- others like it. I'd assume that's partly because the policy makes sense here, and partly because the policy was respectfully communicated instead of implying that AI-users are committing some sort of cardinal sin.

It really depends on what the application does. It's only really a problem if it's internet-facing, and even then, the harm is limited to the application's own permission set. I don't really care if someone can chain together zero-day exploits to "pwn" my lightbulbs.

A lot of the recent major exploits like php2shell require a fair amount of effort to use, so unless you're a major public figure or holding on to something very valuable, there's not a lot of reason to be concerned.

Obviously, if you're writing a password manager, it's a very different story and I'd be horrified by such a policy there. But you've got to make an argument that this specific app is actually a target

I’m not so sure, it currently feels like forgotten coding practice, missed documentation, intersystem reasoning blunders, configuration mistakes, lack of test coverage are all massive tells that a human wrote the code.

Agents have us beat and we can’t win back the ground.

I think the idea is to weed out the obvious stuff and have a rule you can point to. When someone opens 20 PRs in a day with an entire novel in the PR description. You can just close them without having to sink effort in to each one. The LLM signs are less in the code itself and the patterns of how the person interacts with the project. A normal contributor might join the IRC, be involved in the project, start on smaller issues and work up. An AI power user just drive by dumps a mountain of content and then leaves.

If a contributor genuinely understands the problem, has tested the code themselves and writes the PR description themselves, it would be indistinguishable from human written code anyway.

I think for the past year anyone determined enough could direct Claude to make the codebase look purely human.

I don't believe that time will ever arrive.

Or if it does, it could be hundreds of years in the future.

But maybe it'll be next year? LOL.

As it is, we seem to be developing detection techniques at a good clip and the way current LLM tech works it doesn't seem like there is a path towards avoiding detection... Plus, humans are genuinely very good at self-tuning to detect LLM output.

In the spirit of a balanced discussion, I have to admit that said extension is full of flaws and is nowhere reliable. However it was/is widely adopted amongst the Zig team.

I remember how someone used it to guess vibe-codeness of the infamous and long awaited bun2rust article by Jared Summer from Anthropic. It was completely off-base vs real numbers of em/en dashes and hyphens.

Why are AI pushers always scheming to go against people's wishes like this? It's incredibly anti-social.

"I'd like to request a vegetarian meal."

"This is a clever request. It will not be an obstacle for a good chef who knows the best spices to use to disguise meat."

Unenforceable - sure, but it's interesting and I see the logic. While LLMs are extremely useful, I find they homongenise things. Claude text is instantly identifiable and now all my co-workers presentations and docs sound like it. I'm sure that extra effort helps differentiate things (so many LLM generated sites look the same so not many people put in the effort).

A project without everyone putting the same filter between them and the work they submit might help a project evolve in interesting and different ways.

> ...is also completely unenforceable...

It's exactly as enforceable as when projects require you to swear that you can legally assign copyright of your submissions to the entity that runs the project, and/or swear that your submissions don't infringe on anyone's patents, and/or -as the ReactOS project does- swear that you've never seen the code that the project is reimplementing.

If someone swears that they're conforming to the rules and you later find out that they lied, then you ban them forever, publicly announce why, and -if needed- purge their contributions and do your best to alert affected users about the tainted versions. These sorts of policies work for the same reason ordinary doors and door locks work: most folks aren't profoundly antisocial shitbags.

it is enforceable, just the wrong rule.

the rule is ultimately "dont submit stuff where only your llm session knows whats going on"

if you brainstorm with an llm, then rewrite the llm prose but have no understanding, youve still broken the rule.

if you understand what it suggested, why, and so on, then you do know whats up, and thats unenforceable, but who cares

It is deeply unserious.

There was someone on a previous thread about zig who reported a bug and was ignored, ostensibly because he used LLMs to confirm the accuracy of his bug report before submission. https://news.ycombinator.com/item?id=49938732

i think its probably asking people to not submit things they dont understand themselves.

if you want to submit an LLM found bug, you could instead donate the tokens directly to the maintainers, rather than making them read your agent outputs

What if the behavior you don’t want is reliance on the technology?

You’re saying that like it’s a gotcha, but it’s completely reasonable, and a later section clarifies that discussing the CoC elsewhere is fine, just not on the fora that are focused on technical issues.

Basically, the person running the project has made their stance clear, they’re not interested in debating it, and if you don’t like it, take your patronage elsewhere. Clear and straightforward.

I don't think Andrew is arrogant. But if he was, he's gained that privilege by 10 years of working on Zig.

Hard feelings?