ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
61% Positive
Analyzed from 11975 words in the discussion.
Trending Topics
#code#llm#llms#zig#project#don#more#why#prs#need
Discussion (454 Comments)Read Original on HackerNews
"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."
I don't think this is realistic. I'm a good programmer, and it speeds up my work a lot, from "make sense of this 10 repo project I haven't worked on recently" to "for this next step I need a vpn multiplexer written in a language I don't use" to, yeah, "this 10k line patch lets me see parts of design space we never could have explored before." I think it's all about understanding the blast radius. Sonetimes a lot of code is helpful, sometimes more like a lot of help proving a fact about one line of code.
Like Simon says, if I'm driving by someone else's project, I don't send the generated pull request, I just file the bug report / repro that would generate it.
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.
I was a food delivery driver back in the mid 00's to the mid teens. Early on, GPS was rare and expensive, so to do deliveries and do them effectively, you had to be able to read a map and mentally plan out efficient routes from the stochastic flow of orders coming out.
This acted as a natural filter, and "delivery driver" tended to be an interesting class of people, landing somewhere in the neighborhood of "lazy genius". Higher than average intelligence, lower than average motivation.
Then when smartphones exploded in the early 10's, the bar for delivering fell through the floor, and the job became swamped with people who would be best identified as "lazy unintelligent". Anyone who had a smartphone and not much life motivation was now looking to drive around delivering food for easy money.
Not saying the job was ever particularly glamorous, but it did have a natural mental barrier that tech tore down, and the result was exactly as one would predict. That being said, I'm not sure end users noticed much difference.
Management, unsurprisingly deemed those precious. They could email them out anytime, working weekend to fix problems their kind were the cause. Sure sir.
They excel at communication. Perfecting the art.
Now LLMs are there to accelerate the trend.
If you will forgive an appeal to authority:
The hard thing about building software is deciding what one wants to say, not saying it. No facilitation of expression can give more than marginal gains.
- Fred Brooks, 1986
True, regardless of that, for sure with LLM we are borrowing Technical debt like never before.
This response 1000% was crafted with input from an LLM, or the user spends too much time reading output from llms.
I think this is a very rosy view of programmers, not borne out by history. The people leading the vibe coding charge are programmers, rather than an external group.
I know it's popular to divide the world into the technically-literate and the credulous, but in this case the technical camp is also the one going all in.
I'm not saying that I'm no longer dealing with code at all though. The way I work is interactively with the LLM and pretty much tell it exactly what to do and how to do it. Sometimes all the way down to "don't copy the reference like that, grab a deep copy of the object instead". Just like with any other type of programming, the only way to achieve valuable and correct results is by knowing exactly what you want and express that exactly and without ambiguity.
But I no longer need to remember most of the syntax for the language I happen to work with at the moment, and can instead spend time thinking about the high level architecture. To make sure each involved component does one thing and one thing well, with its complexities hidden behind clear interfaces.
Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.
But it absolutely has to be combined with verification/testing at the same speed as code production.
Any examples how you see some engineers being left behind?
It would be an honor to be “left behind” by people who practice their craft with such carelessness.
(Frankly, I should probably stop replying to self-professed LLM boosters entirely since there’s a good chance I’m just chatting with an LLM.)
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.
- Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
This might be my bias showing, but these are items I would consider table-stakes for a project of a certain size / level of popularity.
It feels like a lot of the "AI is shit at contributing" problems could be addressed in part by better automated checks and balances.
I do believe, however, that it would have a meaningful impact on the "drive-by" PRs that keep being used as examples; the thoughtless, throw-spaghetti-at-the-wall PRs that do not have malignant intent behind them.
Many large OSS projects would have the resources to eat that cost with Donors, Sponsors, and OSS hand-outs. That's why I clarified in my original post because I know this is not a general solution.
Git supports pre-receive hooks. But big multitenant forges like GitHub.com don't allow you to configure them because they're difficult to secure well. (Some of their commercial features are likely based on them, though.)
If you self-host a forge, though, you can configure arbitrary pre-receive hooks for it in order to do things like prevent pushes from succeeding if they contain verifiably working secrets, for example. You could extend that to do whatever you want (at your own risk).
It is quite strange that a large project like Zig would not have such a thing. I'm sure it's not trivial but it seems important to invest time into.
In my mind the commit (let alone the push to a publicly accesible server) should be done after, and only if, the automated tests are successfully executed. And there's no easy way to implement this, other than having a dirty branch that you discard after rebasing onto a more long lived one.
https://codeberg.org/ziglang/zig/src/branch/master/.forgejo/...
It's just bad/wrong/context lacking decisions and mental models it introduces, that if not carefull will just create a massive mess of a codebase. (I know, because I've tried, and had to deal with it)
And if someone vibecodes a PR and it works, why dont they just share the prompt so a repo owner could vibecode it themselves?
Imagine there's no AI, but for some reason you have people hiring armies of cheap overseas devs and using them to produce mediocre quality drive-by PRs. The effect would be the same.
AI can be used to make quality code, but that requires careful use of the tool... like any other tool. This isn't careful contributions made by someone who knows the project and its goals and is good at using the tool. This is spam.
To reject submissions where the dev "consulted ai" is like rejecting iron ore that was mined by a machine rather than a human. The quality of the ore is what should be measured, not how it was obtained.
For some personal projects I still stick to the basics and write everything by hand though. It’s kinda nice and grounding; and almost feels like a detox.
For any new software engineer, I’m a strong advocate of zero LLM use (except maybe as a stack overflow alternative) for your first few months.
I would love to see a model trained to behave way more like a tool instead of auto-completing from Reddit language patterns…
> 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.
Bun's fork will exhibit indeterministic behavior.
3000 line LLM commit is not that.
Because the pro-group are whining that the policy is preventing the merge, when in actual fact even if the policy did not exist, the PR is crap anyway.
It's a bit like saying speed limits don't apply on private property, therefore you can't have any traffic rules on your private racetrack.
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
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.
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.
In any REAL, workload, with good processes, code review makes speed of code generated a moot point. You still move as fast as you can review the code, and no, I won't debate that you can rely on LLMs, a deterministic language predictor, to determine the correctness of code; in the context of the business, and technical implications.
Having someone else be the AI-middlemen, just introduces additional complexity and confusion.
Something like using the AI to get an initial bad version, make some tweaks to the prompt, make some manual fixes, ask the AI to fox something else, noticing some new related feature and asking the AI to add it, making some benchmarks and deciding to remove a small feature, or perhaps deciding between two similar implementations, add a few more manual fixes here and there, run the extended version of the automatic test and find a weird bug in the unusual setup, make a few fixes with the AI and manually. So after 20 hours of work, the final version has only 50 lines that have been rewriten like 5 times each. Now the mantainer can review only the final version in 1 hour or so.
This is very different to spending 5 minutes asking the AI to write a patch, that has 1000 lines that does not even compile and sending it to the maintainer without looking at it.
I suspect the people who claim that AI works by only giving it high-level instructions are mostly working on "mindless" projects where a developer in the weeds wouldn't need to think very much.
"It's so easy, I could have done that myself"
Well yeah, but you didn't.
You're not suggesting the only metric of productivity is lines of code are you? And that the only benefit of using LLMs is for generating code you're too lazy to type yourself?
> 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)
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.
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.
I've been thinking about this a bunch recently, and I've realized that the thing I value most in software now isn't robust tests or thorough documentation - an LLM can spit those out in a few minutes. It's usage. I want to use software which other people have used before me. I want them to have encountered the bugs and sharp edges and sanded them down.
The sanding down you refer to is what generates those tests and documentation.
Are you suggesting that LLM's can't test for people who use screen readers? Keyboard only users? Slow network requests?
You're acting like the issues an app faces are so bespoke to the actual app itself (and have absolutely no relation to existing problems in this space) that an LLM couldn't possibly cover it. And it's just patently wrong.
So it's just the fact that others have already gone through the motions before I did. That's it really. I suppose in commercial settings, this is even more true and perhaps extends to compliance.
I regularly do both when trying to use library, especially unfamiliar to me.
sooo uhh how do _you_ learn how to use a new library? just throw random shit at the wall until something sticks?
Can it if we stop defining "robust tests" as "a lot of test code lines" and "good documentation" as "lengthy documentation"?
I didn't use the word good.
It may be able to spit out text that purports to be that, in a few minutes. But for most software, an LLM will not be able to spit out robust tests - let alone useful documentation. (And documentation which just replicates the parameter names and types is thorough...ly useless.)
Lolz! I haven’t encountered “code that institutions had been keeping to themselves” that got even remotely close to OSS in quality.
The whole point of having a civilization is that most things in life can be made someone else's problem and you can focus on doing one thing well. If I'm a dentist or if I run a muffler shop, there are only so many hours in a day, so I'd probably rather pay a SaaS vendor than learn vibecoding and then be stuck supervising a weird, high-maintenance underling that may or may not build me the app with the features I need (and that I might not be able to articulate clearly). There are exceptions, but they're just that, exceptions. If a vendor is reasonable and makes a competent product, I'll gladly pay.
The same goes for open source... even if an LLM could reliably create a brand new operating system from scratch, would I really want it to? I don't want to maintain an OS. I don't want to be in charge of someone who maintains an OS. I don't necessarily trust myself to have a coherent vision for an OS in the first place!
The Zig project is certainly far beyond such capability.
As someone who recently started using OpenSCAD for a project I find this attitude quite irritating. You certainly did not "have to" use popular tools.
The OpenSCAD example is particularly illuminating because it's fussy and frustrating and clearly tuned towards a few specific maintainers; there's a ton of things I'd like changed. But I would never trust an LLM to do it! "Oh the output looks fine, cool" is not enough for a CAD program. "Oh, there are a lot of tests, cool" great, I have no idea what a thorough CAD test suite looks like. I would be a reckless idiot if I asked Claude to make me a custom SCAD program... unless I put in a counterproductive amount of work. So I'm fine with OpenSCAD.
I am also sincerely baffled as to how this stimulates the "labor economy." The most obvious objection is that Anthropic seems to be the only party here getting any form of economic benefit: the open-source maintainers are just plain screwed unless they compromise quality for productivity, and the LLM users are trading high-quality tooling built by people who understand the problem for shitty tooling built by a robot, in exchange for uncompensated labor. It only stimulates the "labor economy" in a Bizarro Keynesian sense, digging up glass bottles that someone forgot to put the money in.
I have seen at least 4 completely busted vibe-coded Rust SQLite clones in the last three months, happily used by people who think they don't need to worry their pretty little heads with routine matters like database design. It's a solved problem and Claude is on the case! In fact unlike those stooopid human SQLIte developers, Claude made it multithreaded! So fucking depressing.
You definitely need to have a strong sense of code design though. The AIs are not up to writing clean code at project scale on their own, yet.
Not trying to denigrate the work here, as such. But this certainly didn't convince me that using AI to replace OpenSCAD (or any other major open-source project) is a good idea. The LLMs still aren't even close to being able to pull it off.
Civilization isn't monotonic. People keep solving the same problems over and over again, telling the same stories with a different twist. For example in 1964 having a GUI work environment with a light pen as your mouse was a solved problem on IBM System/360. They had tools similar to CAD. So why don't we all just use that rather than make the same mistakes again. Each time a new way of doing things comes out, people get an opportunity to rewrite everything.
Maybe this will be a real problem in a couple years though.
And you indeed get a lot of wheel reinvention by LLMs because that is now cheap to do. So rather than using some obscure thing on Github (like my stuff), it's easier to just generate what you need. I've noticed this with my own choices in dependencies as well. I tend to just go with what the LLM suggests unless I have a very good reason not to.
Because it takes hours/months/years of accumulated design decisions to get a great open source project. Something an AI agent can only approximate the surface of, unless you’re ready to spend a lot of time on it
So centralizing that common work is a benefit of open-source just as much with LLMs as it was before.
Iff it is doable, then it would be worth considering it as alternative.
> It also stimulates the labor economy, because you have lots of people everywhere reinventing open source projects with their LLMs.
not sure what you mean by that
This is only a valid strategy if you either
a) understand the problem domain well enough to make a judgement call on what the LLM shits out.
or b) don't care about the correctness of the project.
Obviously, many software devs feel comfortable enough with CS problems to validate the LLM solution, but a flower shop owner does NOT know enough about accounting to vibe code a bookkeeping project, so for a shop owner an open source option - with many human contributors and actual production use elsewhere - would be a much better choice.
Because it is incredibly expensive to write a replacement for semi-complex software? Good luck asking frontier models to write a replacement for Zig, Docker, VSCode, etc.
It's not that the project maintainer can use a LLM to generate a PR, it's that they choose not to.
To relate it closer to your argument. As a someone involved in a project that does X, I would find little value in collaborating with the "author" of another project built with AI to do X. Where as a project doing X were the authors actually wrote, understand the code, and thus the problem space better would be extremely valuable peers.
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.
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.
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?
I think LLM dev needs to take a better spec driven approach. The vibing is getting to be annoying.
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.
Because getting an LLM to do it yourself still takes time and attention bandwidth and tokens.
Look at it this way. If a human has interpreted their LLM use so well that they can submit to zig and not get caught, then the LLM use is acceptable.
What they are doing in practice is filtering off all the submissions from lazy people who dont sit between the LLM and the PR.
If you cant be bothered to cover your tracks enough to make the LLM output into a good PR, thats no longer the maintainers problem.
In a decade all of these anti AI policies will go away as the costs go up, and LLMs become less detectable. In the mean time it seems very efficient.
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.
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.
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.
I can generally make it produce excellent well-tested code. Far better than I could do in the same time on my own. But it's a challenge to keep on top of knowledge about everything it made.
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.
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
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.
It's a completely unenforceable virtue signal.
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.
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).
LLMs are a powerful tool like we've never had before. You don't expect a chainsaw to cut down a tree by itself and carve the wood into a statue or a new compiler. LLMs aren't mind-reading autonomous creators, they're more like a mech suit that can increase your capabilities. They have flaws, but until something better comes along, it sure seems like they're the future.
That's a fair thing to ask, though it seems like people will arrive at very different conclusions there.
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.
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/
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.
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.
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.
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.
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
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.
I think this is a great policy by the Zig team.
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
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.
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!
…in theory. In reality, I’m sure a policy like this can’t be selective and fair at the same time. Pick one!
"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."
It's also why model collapse is not a thing despite everyone wanting it to be.
That's why the code you get from the post-November models is so much better than older models.
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.
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?
Is the barrier to entry really that you must be able to perfectly recreate the project from scratch before you can possibly have anything to contribute?
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.
Once you introduce constraints (cost, limited context), the system starts behaving very differently — more like an economy than a pipeline.
I don't think it's "poor character", though, so much as "willing to develop the deep mental model required for effective contribution".
Founders go 1000x your own projects and leave real programmers alone.
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).
https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
>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!
What were you trying to imply by "very convenient"?
If you use the tool to yeah, go one shot a ton of garbage then it will in fact be garbage.
For those who are pissed because a large OSS project isn't accepting LLM generated slop: Fuck off!
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.
(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.)
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).
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.
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."
It's a critique of low effort PRs compared to the high effort review they require.
There are plenty of less stringent projects for people who to get better at open source to contribute to.
“Artisanal” and “Zig” are just about synonymous
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.
Until the contributions are cheap and correct, you need valuable contributors more than you need the contributions.
You point would be valid when we get to a point of contributions all being both correct and cheap. Right now they are only cheap.
It takes like 5 minutes to spot garbage PRs manually. LLM can flood you with a wall of text where only half of the stuff make sense. Also, they can't really spot bad architecture. It's a compiler in an unpopular language, don't forget that.
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.
I suggest we also automate the distribution and the use of software with AI as well, and then just all go to the beach and sip on some cocktails or something.
Or in other words: Good luck with that.
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