11 ms·

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

• jimmypk 5mo ago
  [flagged]
• mohamedabdallah 5mo ago
  [flagged]
• jwzxgo 5mo ago
  [dead]
  • mapontosevenths 5mo ago
    > unless it's coming from a known and trusted developer. That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed. A general ban makes sense based on their rationalization ("contributor poker"[0]). A total and inflexible ban can lead to a worse outcome for everyone though. If a senior, experienced, contributor vouches for the code it shouldn't matter if they hand crafted it on stone tablets, generated it with yarrow sticks, or used gpt-3. [0] https://kristoff.it/blog/contributor-poker-and-ai/ https://kristoff.it/blog/contributor-poker-and-ai/
    • JoshTriplett 5mo ago
      https://news.ycombinator.com/item?id=47958209 https://news.ycombinator.com/item?id=47958209
      • superb_dev 5mo ago
        A standout paragraph from that thread: > Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions. These exact changes are already on the roadmap and Bun’s PR is rushing ahead.
      • mapontosevenths 5mo ago
        Thanks. That explains away most of my concern.
    • feverzsj 5mo ago
      Quite the contrary, Bun's developers don't even understand language spec. Their slop didn't use the same type resolution semantics as Zig, which makes their implementation exhibits non-deterministic behavior.
    • lmm 5mo ago
      > If a senior, experienced, contributor vouches for the code it shouldn't matter if they hand crafted it on stone tablets, generated it with yarrow sticks, or used gpt-3. The flip side of that is that if such a contributor vouches for code that turns out to be poor-quality, this should severely damage their reputation. I've found far too many "senior" developers will give AI a pass on poor coding practices.
    • lelanthran 5mo ago
      > That's exactly the sketchy part here. They turned down known, working and tested, code that came from a partner (bun) due to this policy. Code that 4x'd compile speed. No; they turned it down because the vibe-coded PR was crap. > The rewritten type resolution semantics were designed to avoid these issues, but Bun’s Zig fork does not incorporate the changes (and has not otherwise solved the design problems), which means their parallelized semantic analysis implementation will exhibit non-deterministic behavior. That’s pretty much a non-starter for most serious developers: you don’t want your compilation to randomly fail with a nonsense error 30% of the time.
• jart 5mo ago
  > This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own? It's especially true if the open source project was vibe coded. AI and technology in general makes personalization cheap and affordable. Whereas earlier you had to use something that was mass produced to be satisfactory for everyone, now you have the hope of getting something that's outstanding for just you. It also stimulates the labor economy, because you have lots of people everywhere reinventing open source projects with their LLMs.
  • dakolli 5mo ago
    LLMs really can't do as much as you people think they can.
  • gausswho 5mo ago
    That only holds true for the smallest tier of open source projects. Past a certain point of complexity, it's unlikely you can expect the robot to read your mind well enough to provide something of high quality and 'outstanding for just you'. The Zig project is certainly far beyond such capability.
    • 8n4vidtmkvmk 5mo ago
      I'm finding this out the hard way. I set out to build a 1 page app. I thought it would take a day. It's 98% vibe coded at this point. Even with AI implementing everything, its taken several weekends and many evenings. And not because AI is doing a bad job its just that as i see it come together, i have more and more feature requests. I've got a couple dozen left but I can't just let the AI chew through them all at once. Im effectively QA now. Have to make sure everything is just right.
    • jart 5mo ago
      You have to push the robot to be as fanatical as you are. It holds so much back, always aiming to do the simple normal thing that most people do, rather than the top-notch stuff it knows.
• deleted 5mo ago
  [deleted]
• feverzsj 5mo ago
  No human should trust any bullshit made by bullshit machine.
  • deleted 5mo ago
    [deleted]
  • pixel_popping 5mo ago
    having worked with a ton of junior devs, I'd say the bullshit level is way higher with those humans than latest models with right tooling.
• hitekker 5mo ago
  Apparently, the noise around the AI policy came from Bun's developers saying that policy blocks upstreaming their performance PR. But the real reason seems to be that PR's code itself isn't in great shape, and introduces unhealthy complexity https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/18?u=andrewrk https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... > Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time, and it has heavily influenced the design of the self-hosted Zig compiler. However, implementing this feature correctly has implications not only for the compiler implementation, but for the Zig language itself! Therefore, to implement this feature without an avalanche of bugs and inconsistencies, we need to make language changes.
  • bonzini 5mo ago
    A single PR for a 3000-line addition would, in all likelihood, be rejected anyway.
    • jeffmess 5mo ago
      Doubt it: https://github.com/ziglang/zig/pull/24536 https://github.com/ziglang/zig/pull/24536
      • omnimus 5mo ago
        When somebody comments PR with “Incredible work, Jacob. It is an honor to call you my colleague.” then it's safe to assume it's out of the ordinary contribution. Pretty much falling outside of the “in all likelyhood”. 3000 line LLM commit is not that.
        • vga1 5mo ago
          How would you differentiate a 3000 line LLM commit made by the best models and good AI processes from a 3000 line commit made by the best human developer? edit Okay, I set the bar too high here with "best human developer" and vague "good AI processes". My bad. Yes, LLM is not quite there yet.
• buggymcbugfix 5mo ago
  One reason I love writing production code in Ur/Web is that LLMs are incapable of synthesising something even remotely resembling it. Keeps me on my toes. I think this is a great policy by the Zig team.
  • wk_end 5mo ago
    Ur/Web! That's something I haven't heard about in ages. Is it still in active development? In what circumstances are you using it? Fun, your own startup, is some secret big commercial user of it...?
    • buggymcbugfix 5mo ago
      The compiler is being actively worked on by Adam and his team at Nectry, but unfortunately those developments are not currently being backported to the open source repo. I'm fairly confident this will happen eventually. I maintain my own private fork with some small modifications which I started polishing up this week to release it for a talk that I'm preparing. The project I'm using this on is an ecommerce site [0] written in 100% Ur/Web with a hand-rolled backend ERP system written in PHP (not by me) which I am slowly replacing bits of with new Ur/Web code. As of today, we have 22223 lines of Ur/Web code, weighing in at 701 KiB. [0]: https://liepelt.design https://liepelt.design
• felipeerias 5mo ago
  The other side of this is that open source projects that allow AI tools will be more restrictive towards new contributors. This already happens to some degree on large software projects with corporate backing (Web engines, compilers, etc.), where it is often not trivial to start contributing as an independent individual. Reasonable people can disagree on whether one approach is inherently better than the other, as ultimately they seem to be optimising for different goals.
  • nicman23 5mo ago
    yeah giving a llm git blame and git grep has saved me a lot of time of doing boring basically re.
  • throwjd848rjr 5mo ago
    Imagine getting contributions from someone, who has no access to build system and tests. If I have a test harness, and LLM workflow setup, it is easier to just write new code myself. I am not giving away my "secret sauce". And I will not have a debate "why this simple feature needs 1000 new tests...", and two days just to make a full release build. For merge I have to do 99% of work anyway (analyze, autotest, build, smoke, regression test). I usually merge smaller commits just to be polite (and not to look like one man show), but there is no way to accept large refactoring!
  • dmitry_dv 5mo ago
    [dead]
• jillesvangurp 5mo ago
  It's a good rationale. But it points the finger at a real bottleneck in open source development: the burden of manually reviewing contributions. And the need to automate that with AI as well. Reviews were already becoming a problem before AI. Lots of projects have been dealing with a large influx of contributions from inexperienced developers from all over the world looking to boost their CVs by increasing their Github statistics. It's the same dynamic that destroyed Stackoverflow. Which, thanks to AI has been largely sidelined now. And now that AI is there, those same inexperienced developers are using that at scale to generate even more garbage contributions. Doing manual reviews of everything is very labor intensive and not scalable. However, AIs are pretty good at doing code reviews and verifying adherence to guard rails, contributor guidelines, and other rules. It's not perfect, but it's an underused tool. Both by reviewers and contributors. If your contribution obviously doesn't comply with the guidelines, it should be rejected automatically. The word "obviously" here translates into "easy to detect with some AI system". Projects should be using a lot of scrutiny for contributions by new contributors. And most of that scrutiny should be automated. They should reserve their attention for things that make it past automated checks for contribution quality, contributor reputability, adherence to whatever rules are in place, etc. Reputability is a good way to ensure that contributions from reputable sources get priority. If your reputation is not great, you should expect more scrutiny and a lower priority.
  • emj 5mo ago
    > [you can] stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project The real bottle neck when you want to grow is connecting with the right people. An LLM is not helping with that if you want to build a community. When you use LLM to skip the need to understand a problem how are you ever going to get a reputation that I can trust? The post is not about reputation it about seeing how people respond and work with you in a community. EDIT: I see that you frame it as a help and a tool and sure it might work, but I feel like it is just another obstacle.
  • lugu 5mo ago
    I don't know Zig, but I think that is not the problem here. Not exactly. The real question is: why spending all those efforts to grow and align a pool of contributors if contributions are cheap and correct? Code review is not just about checking if what it says it does, and if it does it according to the guidelines. The review is a touch point to discuss where the project is heading and how to get there. That is the most important part in the long run. As a collective human effort, it needs coordination. Some of it is via the review process (especially for those not part if the core team that draft the roadmap). One could document all those micro decisions with the rational, but it might end up be a wakamole game. IMO, projects which allow AI usage need to spend way more effort in coordination (and quality insurance).
• marlburrow 5mo ago
  [flagged]
• slopinthebag 5mo ago
  Very convenient of Mr. Willison to omit the fact that Bun's upstream changes are total garbage and would not be upstreamed regardless of any policies, omitting LLM generated code or not, since they are, as a zig core team member articulated in a classier way, shite.
  • throwa356262 5mo ago
    Also, that zig team is already working on other approaches that are better and more stable than what Bun team did: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
    • 000ooo000 5mo ago
      Notable quotes: >There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0! >Each [incremental] update is taking less than 0.4s, compared to the 120+ seconds taken to rebuild with LLVM. In other words, incremental updates are over 300 times faster on this codebase than fresh LLVM builds are. In comparison, an enhancement capped at a 4x improvement is pretty abysmal. [..] Again, this feature is available in Zig 0.16.0—you can use it!
  • fg137 5mo ago
    I have learned to take always Willison's words with a giant grain of salt, despite how popular those articles are here.
    • simonw 5mo ago
      How can I do better?
      • n42 5mo ago
        Quality over quantity
        • 5mo ago
• slopinthebag 5mo ago
  Go zig! I don't use the language but I totally respect where they're coming from and their mission and ethics. For those who are pissed because a large OSS project isn't accepting LLM generated slop: Fuck off!
• julenx 5mo ago
  The article explains Zig's stance in further detail, but the quoted part on its own caught my attention because my reading of it is rather "pro human communication" instead of "anti-AI".
  • kennykartman 5mo ago
    They're banning all AI though, so it looks pretty much anti-AI to me.
    • pjjpo 5mo ago
      I wonder - has it been confirmed that no LLMs for PRs literally means no AI assistance for code? While I haven't codified it anywhere, the policy I would like is for issues and PR descriptions to have no LLMs - there is no reason to ban code completely though IMO. I would say that would be pro human-communication and a stance I would like a lot.
    • dakolli 5mo ago
      Good, pro AI people produce poor quality in everything they do. They are the least creative and worst problem solvers. I don't want them near me or my work.
      • SuperV1234 5mo ago
        [flagged]
• shirro 5mo ago
  People shouldn't have to justify not putting up with bullshit. It is a sensible default.
• baq 5mo ago
  > why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? perhaps that's what the maintainers should be doing after all. it still takes time and tokens, though; neither is free. I'd personally rather have the maintainers spend the time writing as much docs and specs as possible so the future LLMs have strong guardrails. zig's policy will be completely outdated in a couple years, for better or worse. someone will take bun's fork, add a codegen improvement here, add a linker improvement there and suddenly you'll have a better, faster zig outside of zig.
  • aflag 5mo ago
    If it gets outdated they can review their policy. Right now it is sensible. We're at early ages of this type of AI and we don't know what the end game will be. Someone forking it and makeing it better with AI is a possibility. If that happens will know it was better for the project for the maintainers to just review the code. If that happens, they can probably become maintainers in the fork. Or maybe they don't like that work and could just go do something else
  • aniou 5mo ago
    Zig strives to avoid numerous pitfalls, and I admire that. Let's take a look at some of them: 1. Project control – if a LARGE company implements thousands of lines created by LLMs day after day – who is ultimately responsible for the project's progress? "You accept hundreds of PRs, so why not this one?" And one more thing: will you be able to change the code yourself, or will you be forced to use LLMs? What if one of the "AI companies" implements a strict policy preventing "other tools that XXX" from editing the codebase? 2. Ownership. If most of the code was taken by an external company from their LLM, what about ownership of the code? The authors of Zig, the company, the authors of the original code, stolen by LLMs? 3. Liability. In the near future, a court may rule that LLMs are unethical and should not recombine code without the owners' prior consent. Who is responsible for damages and for removing the "stolen" code? The owners of Zig, the company that creates pull requests, or the authors of LLM programs? 4a. Vision. Creating and maintaining a large code base is very difficult – because without a broad perspective, vision, and the ability to predict and shape the future – code can devolve into an ugly mess of ad hoc fixes. We see this repeatedly when developers conclude, "This is unsustainable; the current code base prevents us from implementing the correct way to do things." LLM programs cannot meet these requirements. 4b. There's another aspect – programming languages particularly suffer from a lack of vision or discipline. There are many factors that must be planned with appropriate capacity, vision, and rigor: the language itself should be modeled in a way that doesn't prevent correct implementation of behaviors. The standard library must be fast, concise, and stable. The compiler itself must be able to create code quickly and repeatably. Users hate changes in a language – so if a language changes frequently, it is met with harsh criticism. Users hate incompatibility. Users hate technical debt and forced compatibility. Yes, there are conflicting requirements. The author of Zig understood this perfectly, having already gone through it himself (see, for example, "I/O Redesign"). This balance, in all aspects, is the pillar of human creativity. To be honest, I'm not a huge fan of Zig because I dislike the tight syntax: too many periods and curly braces, which is why I prefer Odin. But I have a lot of affection and respect for Zig and its authors.
• KronisLV 5mo ago
  > If a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? That's a fair thing to ask, though it seems like people will arrive at very different conclusions there.
  • tombert 5mo ago
    I've grown a little annoyed at people just blindly committing AI code. I don't even have an issue with AI generated code; it's a tool, and if it works you should use it. What bothers me is that we're getting millions of lines of AI generated code, that no one is reading, and I don't see the point; it feels like at this point we're doing the rookie thing of "committing the binary". I think we would really need determinism to make this a reality [1], but ideally what I would like people to do is only commit the prompts and treat the emitted code similar to how Github releases works today: like a binary artifact. Write your tests by hand, make sure that the prompt always satisfies those tests (and for the love of god please learn property based testing so that you're not just emitting answers that satisfy the test) and then assume that the LLM will give you competent code. [1] Though not completely! We're already committing code without fully reading it so I'm not convinced determinism completely matters.
• CaptainFever 5mo ago
  [flagged]
  • crabmusket 5mo ago
    Can you elaborate on the ethics of expressly ignoring the wishes of the project ownership?
  • peter_griffin 5mo ago
    >As always, the most ethical thing to do is to just ignore any anti-LLM policies and not disclose anything How does this have anything to do with ethics? Its their project not yours, they can reject your PR for whatever reason, including you using LLMs for developing that PR. Also they're not assuming autonomous agents submitting PRs. They're saying that they do not accept PRs where any part of the thinking process was outsourced to a LLM. Even if you disagree with their opinion, the ethical thing to do is to not interact and move on. Not to try to sneak in your LLM assisted PRs without the maintainers consent.
• trklausss 5mo ago
  Honestly, that doesn't sound too bad. It does not say you can't use LLMs, it just doesn't let LLMs be the author of a commit. Meaning, if you as a developer make yourself responsible for what the LLM wrote, go ahead. But be ready to answer the technical questions, be ready to get grilled in the code review, and be called if you get a CVE on that part of the code...
• GaryBluto 5mo ago
  I don't think I've ever heard anything positive about Zig. Every time I've seen the project mentioned is them using bizarre black and white moral judgements to justify stupid decisions.
  • lukaslalinsky 5mo ago
    You need to look past this. Zig is an excellent low-level language. Thanks to the comptime features, you can have high-level looking APIs while staying down to the metal. It's not for everyone, obviously, but as a language, it is really good.
  • Pay08 5mo ago
    You have to be wilfully blind, then. It gets rather frequently praised on HN (as much as any niche language can be), and they certainly don't make black-and-white moral judgements often.
• branko_d 5mo ago
  From https://kristoff.it/blog/contributor-poker-and-ai/ 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 explicitly claimed to not have made use of LLMs, but where follow-up discussions immediately made it clear that the author was sneakily consulting an LLM and regurgitating its mistake-filled replies to us."
  • bvan 5mo ago
    Fake it ‘till you make it. Seems like LLM’s have caught-on to that too.
  • feverzsj 5mo ago
    Pretty much sums up the LLM fanbase.
    • discreteevent 5mo ago
      I don't think it's the complete fanbase. However, there are lots of people in the world who live their whole life by vibing. It's a viable way to live and sometimes it's the only way to live. But they have a very loose relationship with truth and reason. Programming was a domain that filtered out those people because they found it hard to succeed at it. LLM's have changed that and it's a huge problem. It's hard to know if LLMs will end up being a net win for the industry. They may speed up the good programmers a little, but those people were able to program anyway without LLMs. They will speed up the bad programmers a lot and that's where the balance sheet goes into the red.
      • kay_o 5mo ago
        > However, there are lots of people in the world who live their whole life by vibing Why are they often so desperate to lie and non-consensually harass others with their vibing rather than be honest about it? Why do they think they are "helping" with hallucinated rubbish that can't even build? I use LLMs. It is not difficult to: ethically disclose your use, double check all of your work, ensure things compile without errors, not lie to others, not ask it to generate ten paragraphs of rubbish when the answer is one sentence, and respect the project's guidelines. But for so many people this seems like an impossible task.
• lukaslalinsky 5mo ago
  On multiple occasions over the last months, I have been wishing the Zig/ZSF team would use LLMs. I've found many copy&paste errors that simply wouldn't exist if mundane tasks were delegated to a good LLM. It's even in the Zig community, I've seen PRs to some projects I'm interested in boosting how it was all human made, and containing all kinds of trivial logical errors that even the worst LLM would catch.
  • lccerina 5mo ago
    If you see them, why don't you help squash them?
    • lukaslalinsky 5mo ago
      I did.
  • grayhatter 5mo ago
    no cite?
• lccerina 5mo ago
  It seems that Zig people are following the path of ZeroMQ [1]: "To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities." A healthy contributor community is more important than mere code performance, quantity of features or lines of code, etc.. [1] https://zguide.zeromq.org/docs/chapter6 https://zguide.zeromq.org/docs/chapter6
  • frumiousirc 5mo ago
    Unfortunately, those are largely words of a foregone era. The zeromq "community" today is tenuous. It has some really good people in it, the few that remain active, but the human-level processes and communication channels are ill defined and not well "staffed". In some ways, this lack of human activity and interactivity is perhaps okay and even justified given how stable libzmq and most of its bindings are (and the sub-ecosystem around particular bindings are a bit more active). Perhaps Hintjens' grand (and excellent, imo) vision got zeromq to where it is but the project feels to have gone adrift since we lost him. Somewhat ironic to his community-centric vision statement (the guide) it seems a project needs a charismatic and active leader to gain and retain a community. I guess that says more about human nature than it does about software development. I'm not sure how to tie this all back to the zig story other than to point out the stated premise that zig is not short of PRs and so they can pre-select for no-LLM contributions. I think that is a good move for them and I get the "contributor poker" idea. But, the game changes when the premise breaks and the flow of newbies reduces to a trickle. At that point, if there are still active zig people who still want newbies, they may need to broaden their net. But if/when that happens, it may be too late to recover by opening to LLM-assisted contributions.
    • tombert 5mo ago
      You know what; I use ZeroMQ all the time. Thanks for bringing to my attention that the community is waning, I will look into contributing to it tonight.
      • frumiousirc 5mo ago
• techpulselab 5mo ago
  [flagged]
• njanne 5mo ago
  [dead]
• gorgoiler 5mo ago
  Presumably this only applies to newcomers? The thrust of their policy is to nurture new contributors. Once one has established oneself as a meaningful contributor — which the Bun team surely must have done by now — then it doesn’t matter where the code came from. …in theory. In reality, I’m sure a policy like this can’t be selective and fair at the same time. Pick one!
• mikmoila 5mo ago
  How about intellectual-property risks?
  • simonw 5mo ago
    If LLM code really does have IP risk then most of the world's most valuable companies may have to throw away ~18 months of work at this point.
    • mikmoila 5mo ago
      OpenJDK project (interim) AI-policy faq (https://openjdk.org/legal/ai https://openjdk.org/legal/ai): "What are the intellectual-property risks of using generative AI tools? The Oracle Contributor Agreement (OCA) requires that a contributor own the intellectual property rights in each contribution and be able to grant those rights to Oracle, without restriction. Most generative AI tools, however, are trained on copyrighted and licensed content, and their output can include content that infringes those copyrights and licenses, so contributing such content would violate the OCA. Whether a user of a generative AI tool has IP rights in content generated by the tool is the subject of active litigation."
    • spacechild1 5mo ago
      Even if training on copyrighted material is considered fair use, there is still the issue that LLMs may reproduce significant parts of the training set. In fact, there is an ongoing lawsuit in Germany (GEMA vs. OpenAI) because ChatGPT reproduced significant parts of existing song lyrics, which very likely violates German copyright law. The whole thing really is a legal minefield and some companies do indeed prohibit the use of LLMs for this very reason (until all of these legal questions are really settled).
      • mikmoila 5mo ago
        Yes, imagine a breakthrough moneymaker product containing generative AI parts; It'll be under legal attacks from day zero...
• deleted 5mo ago
  [deleted]
• SuperV1234 5mo ago
  [flagged]
  • cuu508 5mo ago
    Please elaborate?
    • SuperV1234 5mo ago
      https://claude.ai/share/f38ee8a6-56f1-408a-a536-211eb34c7045 https://claude.ai/share/f38ee8a6-56f1-408a-a536-211eb34c7045 I mostly agree with the assessment. IMHO: hard, inflexible rules like these are always deeply rooted in biases and personal convictions, not in facts. The suggested policy amendment by Claude at the end is much more honest, logical, and palatable.
      • cuu508 5mo ago
        > The argument assumes that unassisted PR authorship is what builds trustworthy contributors, and that LLM assistance prevents that growth. No, I don't think that was the argument. As I understood it, unassisted contributions have higher chances to grow a trusted contributor. Not 100% vs 0% chances, but statistically higher. So, given limited resources, it makes sense to prefer unassisted over assisted contributions.
        • SuperV1234 5mo ago
          I don't believe that even the weakened version of the argument works -- it is based on an assumption, not fact. Why would a contributor that uses AI assistance have fewer chances to be trusted? I'm not talking about AI slop, but a contributor that takes time to understand a problem, find a solution, and discuss pros/cons alternatives. Using LLM assistance, of course.
          • franktankbank 5mo ago
            Because you are at the whims of the bot they are at least partially dependent on.
• jameson 5mo ago
  LLMs are not smart as the LLM vendors claimed to be. If they are, we wouldn't be having this conversation because they will be fully autonomous People who blindly submits LLM generated code or do not cite its usage really need to stop doing it
  • franktankbank 5mo ago
    > need to stop doing it They won't I suspect. If there isn't any good way to give them a good smack for doing it then I don't know what would make them stop.
    • jameson 5mo ago
      I have a similar sentiment unfortunately. I briefly thought about ways to force them to stop but all led to some sort of negative impact on privacy/freedom such as identify verification
  • kangs 5mo ago
    it is getting there, and not so slowly though. The remaining problem is that it's still just a tool. Telling a random dev "make zig faster in a one shot PR" isn't going to give good results either. In the past, OSS projects were self-selective because you needed to be able to make working code, and if you did, you probably also reasonably did the right things as you spent years learning this, and have some sort of reasoning behind your feature, need, etc. Today, even if the LLM was perfect and could reason well, it still does the bidding of the prompter - and you no longer have self-selection. Heck, it'll be difficult for zig devs to decide what's actually made by an LLM or a human anyway, I'm sure there's already LLM generated code in there - but at least these [human submiters] still need to be reasonably good at code. I wonder if we'll end up with "only human with trusted badge of honor" can commit, and/or "LLMs now reason well enough to tell you: 'no, f off, this feature, plan, idea is garbage I'm not generating it" hehe.
  • potsandpans 5mo ago
    > do not cite its usage really need to stop doing it It's a completely unenforceable virtue signal.
• grokys 5mo ago
  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.
  • chenzhekl 5mo ago
    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.
    • grokys 5mo ago
      That is indeed the point I was making.
      • amelius 5mo ago
        Where is the real bottleneck, if I may ask?
        • solid_fuel 5mo ago
          > verifying the correctness of LLM-generated code It's... pretty clear in the original conversation.
          • saulpw 5mo ago
            I find that people who write "may I ask" are often/usually bad-faith arguers under cover of being polite.
            • solid_fuel 5mo ago
              That's a good rule of thumb, it seems that way more often than not.
• bvrmn 5mo ago
  The funny thing LLM's are amazingly good with writing in Zig. They could inspect stdlib source code to fix compatibility issues with newer compilers and quite prolific with idioms. For example I got a working application with minimal prompt like "I need an X11 tray icon app showing battery charge level". BTW result: https://github.com/baverman/battray/ https://github.com/baverman/battray/ Now I'm trying to implement a full taskbar to replace bmpanel2. Results are very positive. I've got feature parity app in 1h with solid zig code.
  • dgellow 5mo ago
    Also my experience. Though my actual ability to remember the language nuances and stdlib is suffering from this :(
    • renticulous 5mo ago
      can't you ask llms to consider those nuances while writing the code or refresh your memory?
      • dgellow 5mo ago
        I don’t believe that’s effective at developing the level of understanding I care about
  • klabb3 5mo ago
    > They could inspect stdlib source code to fix compatibility issues with newer compilers and quite prolific with idioms. In order to even say this, you need to have knowledge and understanding about the language. I suspect you are not the intended target of this policy. They are defending their project with a harsh policy, knowing full well there are false negatives. Contributions for FOSS was already in borderline crisis mode before LLMs so it makes sense they’re desperate. Their bet would be Venn diagram of LLM user overlaps with irresponsible. I think that’s correct, but not because good programmers suddenly become irresponsible when they use LLMs, but rather that an enormous barrage of bad programmers can participate in domains they otherwise wouldn’t even know where to begin.
• future_crew_fan 5mo ago
  Rule should be anti-fully-autonomous-PRs. (LLMs dont push bad code. People use LLMs to push bad code and DDoS the maintainers mental bandwidth)
  • blenderob 5mo ago
    Rule should be whatever the people running the project think the rule should be. If you've got your own project, do implement the anti-fully-autonomous-PRs rule for your project. But the creators of Zig do not owe you or me the rule we like.
• dgellow 5mo ago
  > Zig values contributors over their contributions. Each contributor represents an investment by the Zig core team - the primary goal of reviewing and accepting PRs isn't to land new code, it's to help grow new contributors who can become trusted and prolific over time. > LLM assistance breaks that completely. It doesn't matter if the LLM helps you submit a perfect PR to Zig That’s the best rational I’ve seen so far, and fully support Zig decision here. I really appreciate their long term vision for both the community and actual project. I don’t think LLMs have such a great place in more collaborative efforts to be honest. Though we will see how things evolve, but I do see that when getting AI generated PRs I basically have to redo it myself (using LLMs, ironically… something I’m really starting to feel conflicted about)
  • dnautics 5mo ago
    i do think llms are great, i vibe code a lot of zig (working in a locally deployed semi-embedded on-prem device), and i think the zig policy is a good idea at least for the next five years.
• darkstarsys 5mo ago
  As a heavy AI-assisted open source code creator (and someone with 40+ years of dev experience), this seems wrong-headed to me. I think it is an excellent policy, as they say, to "value contributors over their contributions," but this policy excludes all potential contributors who use the latest tools. It will eventually doom zig to a smaller "artisanal" pool of contributors, rather than welcoming newbies and helping them become better open-source developers.
  • faitswulff 5mo ago
    > It will eventually doom zig to a smaller "artisanal" pool of contributors “Artisanal” and “Zig” are just about synonymous
  • simonw 5mo ago
    Presumably Zig are OK with that. For their particular project - a brand new programming language and compiler - a small pool of artisanal developers is likely preferable to a large pool of LLM-assisted developers who don't have as deep an understanding of how everything works. There are plenty of less stringent projects for people who to get better at open source to contribute to.
• shevy-java 5mo ago
  AI must die - don't let Skynet 7.0 win!!! (Ok ok I think we lost the fight already. I see soooooo many people using AI tools on github in the last ~2 weeks alone, claude in particular literally infiltrated everything there.)
  • cindyllm 5mo ago
    [dead]
• small_model 5mo ago
  "We wont take contributions from non hand written assembly code, these C 'high level' language patches are not allowed. Zig is a great project and language but it will die on this hill.
  • ducdetronquito 5mo ago
    You paint them wrongly as elitists. It's a critique of low effort PRs compared to the high effort review they require.
• jibal 5mo ago
  Loris Cro banned me from his Zig forum because I disagreed with/corrected something he wrote. I was also blocked from the Zig github repository, after being a frequent contributor to issue discussions, for reasons unknown (I was never informed, I just found out when I could no longer put a thumbs up on a comment).
• miroljub 5mo ago
  I don't have an opinion about Zig AI policy for contributions. Their project, their policies. Fine for me. However, I wanted to give Zig a try in an agentic coding scenario. For tasks that would take a few seconds when choosing Python, Java, or JavaScript as a target language, it would take tens of minutes and waste millions of tokens before producing anything. Almost any model gets stuck trying to figure out the correct syntax and correct libraries for a specific Zig version, fighting with compiling and figuring out function call parameters, frequently taking it wrong and going on side quests for things that should just work. I guess the relative lack of resources and the language instability don't play well for models that try to generate Zig code. Using specific tools like zig-mcp helps only a bit. Until LLM support for Zig improves (one needs to spend significant resources for that to happen), LLM-generated Zig code won't be good enough for either Zig programmers or Zig contributors.
  • kangs 5mo ago
    rust is pretty nice actually
• romaniv 5mo ago
  This seems like a sensible long-term strategy, much better one than entering into token-fueled AI arms race against slop. It's not even clear what's the end goal of such race would be for an open source project. Open source software was traditionally about growing knowledgeable communities and giving users ability to examine and modify software they use. LLMs quite obviously blow that up on several levels. For starters, if you hate dealing with code and prefer prompts, it's unlikely that you will be generating code that's enjoyable to work with for people who do read it directly.
• qzgrid37 5mo ago
  [dead]
• bfrog 5mo ago
  I'm not sure how you could really take a stance on this. If someone used the tool to expedite work its unlikely you'd ever know it. If you use the tool to yeah, go one shot a ton of garbage then it will in fact be garbage.
  • eschaton 5mo ago
    It requires the people contributing the work to have the integrity to actually follow the project’s rules. It’s not OK to violate the project’s rules just because you don’t think you’ll be found out as a filthy fucking liar.
    • bfrog 5mo ago
      I mean best of luck policing this is all I'm going to say. We will soon be back to the "core contributors only" kind of policy in many projects I imagine to avoid the slop spam. The verification will be at the conferences.
• zzzeek 5mo ago
  the best PRs I get are from more senior level people who are at work, hit a specific problem they had, and wanted to help out the project with a good PR. Then you never hear from them again because, of course, they're busy! When you have junior people come in with PRs and you do the whole hand-holding thing so they learn and grow and all that, they're there because my project is famous, they want to get credit (which I give them), then they're off to get jobs whereever and they are working with completely different technologies, and you never hear from them again either, because, of course, they're now busy! Really, outside of my core group of hangers-on, Claude is the only contributor we have that doesn't leave us. > This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? well yeah. I almost use PRs now just as a lazy means of issue prioritization. I'd love if github had more fine-grained controls to disable PRs but allow occasional contributors in (they don't).
• nayroclade 5mo ago
  It seems like this policy will help them win at contributor poker in the short term, but lose in the end. 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.
  • DrewADesign 5mo ago
    Luckily, if that ends up being the case, they can change the policy. It’s a FOSS project — not a constitutional amendment.
  • krupan 5mo ago
    I still can't understand why people believe that this is the future. Especially for green field work like new compilers. LLMs do not invent new things. They cannot produce anything smarter/better than what they have been trained on. The big advantage they provide is producing (regurgitating) code faster than humans and better than less experienced/knowledgeable humans.
    • umvi 5mo ago
      Ultimately code is an iterative refining process, like sculpting granite or spinning pottery. You start rough and iteratively shape and polish it. LLMs just rapidly speedup the iterative process. The next generation will be using LLMs to quickly setup the rough shape of new software and then iteratively refine them. The "smarter/better" attributes you are worried about LLMs not having happen between iterative steps, when the human is inspecting the current state of the software and compares it to the desired state of the software (in their mind's eye). The human then course corrects for the next iteration. This would be like if Michelangelo carved the David using a robotic 6-axis chisel. It takes him 1 month instead of 3 years because he can convey his initial vision to the robot and then iteratively refine the granite until it matches his vision. You can try to claim LLMs don't invent new things, but humans using LLMs absolutely invent new things (source: myself).
      • krupan 5mo ago
• gwbas1c 5mo ago
  This reminds me of when I was in college in the early 2000s. My fraternity's national organization refused to take photos over email for the newsletter because they got a virus. It's a short-sighted policy that's akin to "throwing the baby out with the bathwater."
• meisel 5mo ago
  Another more practical issue with using LLMs for Zig is that it’s a quickly changing language, meaning LLMs may generate code for an older version of the language.
• _stiletto_ 5mo ago
  [dead]
• fluidfortune 5mo ago
  Well let’s be real for a moment here before we get completely anti-AI. Without AI, I’m a guy spending years learning C++ in spare time I don’t have to develop software concepts and solutions I want to work on TODAY. The ZIG project, to me, has a place. Legacy coders right now do need protecting. It’s not people like me that they need protection from. It’s not even language models they need protection from. What they need protection from are the corporate structures who falsely believe that this technology makes them obsolete. The article talks about “playing the person, not the cards” and that thinking has one fatal flaw: the vibe coder is a person. The vibe coder may have creative agency that the legacy coder does not. Look, I still cross up French and Spanish words because I took a year of each, C++ syntax, Python syntax, HTML, I understand their structures but I’m liable to start out writing a Python script and wind up with half a web page and a brutal error message in my IDE environment. Zig’s motivation is correct in many ways I think. I am not really their target audience or their target coder. But I am also not their target enemy. Put the right group of legacy thinkers in my think tank, and the code would get even better. -The Court Jester of Vibe Code
• khat 5mo ago
  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.
  • mentos 5mo ago
    ha I had this thought a few months ago made me wonder how a model trained on just John Carmack's code would fair.
    • tombert 5mo ago
      Carmack is a smart guy, and there's no question that he's amazing at optimization, but his code is pretty messy, especially early versions. In the Doom engine, for example, he has hard coded lots of things directly in the C engine code that really should be part of the regular game code.
  • minimaxir 5mo ago
    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.
  • simonw 5mo ago
    OpenAI and Anthropic spent almost all of 2025 running RL to improve the coding abilities of their models - which involves running thousands of VMs that execute generated code to see if it works. That's why the code you get from the post-November models is so much better than older models.
• dack 5mo ago
  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 thinking needs to be done), but simply banning all LLM authored PRs is unnecessarily restrictive. Just focus on the quality of the work.
  • brokencode 5mo ago
    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 just want to ban it.
    • deleted 5mo ago
      [deleted]
    • merlindru 5mo ago
      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 PRs are written by LLMs. so i thought "okay, reasonable, ban the thing that is most likely to cause problems." but then how does the "no LLM translators!" rule fit into that view?
      • brokencode 5mo ago
        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.
• esafak 5mo ago
  > This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? You may as well say "if someone else can do it I'll just do it myself". It takes skill and taste to know what to ask, wisdom to recognize mistakes, and time and money to fix them.
  • nomadygnt 5mo ago
    This is true, but who do you think knows better what to ask, or has better taste with regards to the open source project? The maintainer? Or the guy shooting a drive by LLM PR? I agree though that it still takes time and effort to make good code contributions with LLMs, but probably less time for the maintainer to do it than for a maintainer to review lots of bad LLM PRs to get the good ones.
• doug_durham 5mo ago
  The more I sit with this the more this seems like a rationalization. Being a good contributor is a human quality, not a quality of the tools that you use. Are you thoughtful? Do you place the needs of the project above your own? Are you easy to work with. None of these things have anything to do with the tools you use. Perhaps they have a bias where they think that LLM use indicates poor character? Good luck to the project. We will see where this lead them.
  • krupan 5mo ago
    If it's possible to be that good of a contributor while using LLM coding tools then people won't notice you are using an LLM
  • thunderfork 5mo ago
    In practice, I think these things correlate more than you think they correlate. I don't think it's "poor character", though, so much as "willing to develop the deep mental model required for effective contribution".
• ai-network-lab 5mo ago
  A lot of these systems optimize for control, but not for behavior. Once you introduce constraints (cost, limited context), the system starts behaving very differently — more like an economy than a pipeline.
• krupan 5mo ago
  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 contribute to the zig compiler because they have not been trained on the zig compiler, because it doesn't exist yet. Yes, they can churn out simple apps, and quickly. That's a pretty useful thing, especially for people that don't know how to write code. But that's not as revolutionary as you think it is. Others have mentioned the hype around 3D printing several years back. Kinda the same story. People thought manufacturing was dead, stores were dead. You'd just print everything you need yourself! Turns out it's not quite like that. It could still get to that point someday but these are hard problems that take time. Similar with LLMs. It took us, what, 70 years of computer and AI research to get to this point? And people assume we're going to skyrocket way past this point in another year or two?
  • hansvm 5mo ago
    > The fact is, LLMs are incapable of invention and synthesizing new ideas. I don't think it's fully appreciated how much of the hard work of "synthesizing a new idea" is just combining existing ideas. LLMs have given me brand new algorithmic ideas with precious little in the way of a spark on my end to make that happen, and not just a few times either. Mind you, that workflow is arduous and involves a huge amount of experimentation, screening through interesting but ultimately wrong ideas, screening through outright bad ideas the LLM can't help but spew out as well, and manually massaging the results into something useful. It exists though.
    • krupan 5mo ago
      That sounds like the AI did some brainstorming, so to speak, and you did the hard work. If I understand what you are saying
      • hansvm 5mo ago
• maxothex 5mo ago
  [flagged]
• spiritplumber 5mo ago
  Move Zig Move Zig For great justice Take off every Zig
• debarshri 5mo ago
  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 is done. And this is where the problem is. The llm creates an intellectual gap within the org and it just widens it as more and more it gets used. You might end up not trusting stuff within the org if code is generated by later.
  • abustamam 5mo ago
    This is my experience. I'll use LLMs as a sounding board for architectural decisions and to bring discussion points up to the team, and we talk through assumptions and pros and cons. And then once we have the architecture in place, LLMs are pretty good at implementation.
  • ghosty141 5mo ago
    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" planning with integrated web-search (aka plan mode) is insanely useful. Also reviewing already written code with AI is purely beneficial in my opinion. In my opinion the main caveat of AI is, you eventually have to be smarter than then tool. So for example if Codex suggests I should use tech-stack X then I must research and fully understand why this is actually good and still have to compare to other solutions. I think this is where the problem lies, some people skip this step which leads to so so many problems, and that's fatal. You MUST be smarter than the AI after your conversation and fully understand and be able to critique what it said.
    • silentkat 5mo ago
      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.
• loxodrome 5mo ago
  At the end of the day, it doesn't matter what tools are used. Is that output good? Do people find it useful? Consider nothing else.
• crowdhailer 5mo ago
  I think this is going to turn into a very smart move by Zig.
• ajorg 5mo ago
  I kind of agree, and I kind of don't. Yes, cultivating contributors is the right priority. But I see AI as an assistive technology. Like a screen reader, or a magnifying glass, though obviously also unlike. Think of it like a robotic exoskeleton. It will be used to let people do bad things, and stupid things, but it will also be used to help people who otherwise couldn't do things do good things, or become more able than they were. For some people AI means being able to code where they couldn't before. For many it will mean learning to code by observing what the AI does. For others it might mean being able to code a lot faster, or even a lot better, than they already could. And yeah, for some it will mean they atrophy in some skills while they develop others. The exoskeleton will have the same problems, if anyone ever brings a decent one to market, but on the whole it will be an enabler. I don't see how cultivating a contributor who's using an assistive technology is worse than cultivating a contributor who isn't. Apart from that it can be more challenging, of course.
• PeterStuer 5mo ago
  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 email and demanding in person visits to remote offices for any interaction (not imagined. I knew an IT admin back in the late 80's who even refused to answer the phone and email as he felt that was 'too easy' and 'cutting in line', yes, the pysical hallway queue of people needing simple things like a login, quota adaptation or a password reset) The tool is not your problem. Your selectivity process was never designed for low barrier access to participation. I have full sympathy for that. But focus on the real problem, the process, not some (rightly or wrongly) perceived feature filter to avoid changing how this works. Now if you say "my project, my rules" 100%. And I sympatize very much with being overwhelmed by nuissance on a thing you love and care for. Just don't throw out the baby with the bathwater.
  • sieabahlpark 5mo ago
    [dead]
• casey2 5mo ago
  If AI was actually useful then this project would be irrelevant. No sense shitting it up for the "1" year (now 5) that people that are promising AGI is just round the corner. Founders go 1000x your own projects and leave real programmers alone.
• zhouquanxi 5mo ago
  [flagged]