A must read if you have ever had your PR(s) for ziglang/zig closed without merging.
Also a must read to understand the whole “strict no LLM policy”. I think @kristoff puts it really well in this post, I hope this will get shared around so more people start to get why that policy is in place.
I’ve been observing the Zig dev process and I came to the conclusion that creating an issue for a simple bug is better than creating a simple PR, the issue will get noticed sooner. And I guess it’s easier for the team to do it themselves, no trust issues that way.
Great Article Loris!
I can confirm from my own experience that there’s always something lost when you go from generating the code yourself to having an AI to generate the code for you. The tradeoff seems clear for Zig contributions.
The people who remarked on how it’s impossible to know if a contribution comes from an LLM or not have completely missed the point of this policy and are clearly unaware of contributor poker.
I made this remark on a previous thread, so I fall into this category. I admit I still miss the point even after having contributor poker described to me. Either a contributor takes the time to make sure their contributions are valuable and respect the time of the maintainers, or they don’t - the tools used to produce those contributions are entirely unrelated to that.
Also, to be clear, I’m not advocating zig change their AI policy, but it seems worthwhile to interrogate so if I ever do decide to contribute to zig I don’t run afoul of the policy. So what does an AI ban mean?
- No code written by LLMs?
- No code audited by LLMs?
- No code produced through ideation with an LLM?
If nothing else, it seems like a very vague policy still very much open to interpretation.
I guess it goes like this:
- LLM gives the ability to produce more contributions
- Maintainers’ time is scarce and doesn’t scale the way LLM fueled contribution do
- Maintainers get their time wasted on bad contributions (loosing at contributor poker), and those are often made with LLMs
- Maintainers decide that banning LLM contribution is a good way to avoid most of the noise
Now, there might be a bit of survivor bias - maybe some really good contributions are made with LLM assistance. But if most of the time wasting is caused by LLM contributions, I guess it makes sense to ban them…
EDIT: or until a better approach to discriminate contribution is devised (for example reputation based like @mitchellh implemented for ghostty)
The point is that when we see a new PR for the first time, we don’t know what’s the case, and LLM usage at the very least correlates with a higher probability that the contributor will not be able to become trusted in the future.
Given that we don’t have enough resources to look after each and every single PR, it makes no sense for us to do the extra work required to understand what’s going on with an LLM PR when there’s a huge pool of non-LLM PRs that are waiting.
That if we suspect that you are using LLMs for generating code and/or for arguing about the problem, your PR is going to be closed and you will be banned from the repository.
In practice, if you’re a mature enough engineer, interacting with an LLM as part of your process to explore a problem space won’t instantly taint your reasoning, but going into a discussion and presenting LLM output as an authoritative source of truth, as advice worth following or, worse, as your own opinion, is an instant ban.
So while you can do whatever you want as you think a problem though, the best way of going at it is to just not use LLMs when contributing to Zig. Additionally, LLMs are inherently tools for offloading the work of thinking a problem through and, as Johnny pointed out, their usage tends to weaken your ability to gain insight on a problem space, which in turn makes it harder to build trust with you over time, which is another problem from the perspective of contributor poker (whose main goal is to build long-term trust with prolific contributors).
So while in theory somebody could be an amazing contributor who just happens to use LLMs, we don’t have the luxury to go and discover that while other more promising bets are piling up.
Lastly, if the situation were to change, I’m sure that there would still be issues to be ironed out WRT what we would want to allow or not. AI is controversial in a variety of ways. But we haven’t discussed this in detail yet because in any case we have a much more pressing reason that makes even considering accepting AI contributions a bad idea.
One thing I’m happy to acknowledge is that people who would otherwise be incapable of producing something themselves are now inundating a lot of projects with LLM-produced PRs. I’m definitely not dismissing the pain that maintainers are feeling as a result.
That’s fair, and often times it’s obvious. But sometimes it gets you get into a weird place where you’re suspicious of… certain punctuation being used? Tests that seem bit too exhaustive? Comments that are a little too articulate? Instead of just judging the contribution on its merits, you end up interrogating vaguely suspicious details. Seems exhausting.
I fundamentally disagree with this premise. They can certainly be used in this manner, but it’s not inherent. It’s like saying “Using stackoverflow inherently means you’re copy-pasting solutions.” Copy-pasing code is a real problem! But it’s not inherent to using stackoverflow.
Anyway, your clarifications were helpful, even if I disagree with some of the premises underlying them.
We’ve had discussions about having some form of invite tree (which mitchell’s vouch system essentially is, at least as first approximation), but that wouldn’t change the fact that we still would have a reason to want to prioritize non-LLM PRs.
Introducing an invite system would lower the amount of PRs we would get, but I suspect that we would still be in the situation where we wouldn’t be able to give full attention to every PR, so even if, say we were to allow LLM contributions, it would still be irrational to prioritize an LLM PR over a non-LLM one.
Forgive the analogy here but I just thought of it and I couldn’t help but sharing and I think there’s a point being missed here in some of the discussion here and in other threads; and that’s the one of trust versus being able to absolutely verify community behavior 100% of the time.
Said analogy is the one of esports, like let’s say CS:GO or other similar shooters. Cheaters get caught showing their asses all the time. On stream, at tournaments, pretty much everywhere where it causes maximum embarrassment. Or speedrunners getting caught splicing replays, etc.
These are people that have decided to take part in communities built on trust under the premise that they will respect the rules, and subsequently violate that trust. They thought they could hide their behavior but eventually slip up, get caught, and suffer the consequences. I don’t think that LLM use would be different in this scenario, and I’d hope nobody in the Zig community would ever want to be this person.
Plenty of people vibe stuff based off of Zig, but I’d hope that if you’ve chosen to use Zig, you respect community enough to understand the reasons why the core team has chosen to disallow LLM use, and respect those rules should you wish to participate in core contribution.
As the only person in this thread to, I guess, “challenge” the original post (for lack of a better term), I can’t help but think this is directed at me, in which case I want to be clear: I don’t think people should try to skirt the rules, or that skirting the rules is okay as long as you don’t get caught. If that’s the takeaway you got from my responses, I would ask that you re-read them more carefully.
Don’t worry @wbrian, I don’t think anybody here has assumed that was your intention.
WRT “cheaters”, we have indeed seen plenty of examples of people that lied about their usage of AI in the past, which is something that is pretty annoying. It’s generally rude when people give you LLM output to read, but it’s worse when they lie about it when you ask them not to do it.
These were obviously people that were more interested in fucking around with AI than to make actually meaningful contributions to Zig, but in my opinion it would be a bad sign if the Zig project stopped being open to newcomers and tried to rely entirely on contributors that we already know are trustworthy.
There have been several threads regarding this topic on Ziggit now, and more broadly, this is a common argument used against those that wish to limit or ban the use of LLMs in the projects that they steward, for as far as I’m concerned more than valid reasons, be them social or practical. I have not exhaustively checked every post to get the exact numbers of folks who have made similar arguments, nor am I really interested in doing so, so no, this was not a call-out at you specifically.
Yeah…. I guess… since people do eventually die….
Amazing how trustworthiness and rapport keeps finding itself at the center. This was one of the most interesting ingredients in the XZ storyline.
Contributing can be far more than contributing code (PRs) — something that many people desiring to contribute miss. Providing excellent bug reports are highly valuable for a project, but probably not going to get you resume fodder or bragging rights, which is unfortunate.
Now that you’ve found this here, I bet there’s a good chance you’ll see that trustworthiness and rapport are truly everywhere in this life.
Oh absolutely! The XZ heroes are certainly heroes, but such heroes are everywhere. There are, of course, the XZ villain(s); though they may be few, and lurk in the shadows, they’re serious threats. And there are many flavors of slop and crap in the middle. So zig team’s balanced attention to trustworthiness and rapport, especially in the face of this AI era, is very appreciated. (Likewise, ziggit mods’ balanced attention is very appreciated.)
Makes me think of a recent Cory Doctorow article about process knowledge, the small bits of things you learn everyday and must understand to be effective. Usually nobody writes it down and it has to be learned from other people and from experience. (Coincidentally, it’s the kind of stuff that probably won’t make it into an AI training data set)
Output is easy to measure (and easy to game), but process knowledge is a lot more intangible.
I sympathize with the rationale laid out in this article, but it’s also true that a blanket AI ban would deny Zig of a big talent pool of seasoned developers who make responsible use of AI tools.
I wonder what you guys think of this idea: we divide contributors into two groups:
- Regular contributors are subject to the AI ban just like today.
- Trusted contributors are not subject to the AI ban.
Contributors start as regular contributors; Zig maintainers may promote a regular contributor to a trusted contributor once they’ve proven themselves. Of course, Zig maintainers may also demote a trusted contributor to a regular contributor upon evidence of AI abuse (if not banned outright).
This idea would keep the bar high for first-time contributions, but give trusted people the freedom to use whatever tools that make them productive. It also gives people some extra motivation to write really good code in order to earn the “trusted contributor” badge – a bit of gamification if you will.