Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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).
by zzzeek - 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.
by debarshri - 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.by abustamam
- I agree with this assessment but even among us seniors with accumulated knowledge it has the dangerous potential of getting out from under your feet and produce large amounts of code that you don't have full comprehension of.
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.
- 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.
by ghosty141 - 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".by julenx
- They're banning all AI though, so it looks pretty much anti-AI to me.by kennykartman
- 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
by jameson - > do not cite its usage really need to stop doing it
It's a completely unenforceable virtue signal.
by potsandpans - > 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.
- 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.
by kangs - 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.
by dack - I agree but I dont see a better way to achieve it.
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.
by protocolture - 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.
by brokencode - 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.
by PeterStuer - > 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.
by jart - I think this ignores the amount of work needed to make LLM contributions be of high quality. It's much less work than making pure human contribution, but it's definitely not zero.
So centralizing that common work is a benefit of open-source just as much with LLMs as it was before.
by vga1 - > The same argument applies to open source itself. Why use someone's project when you can just have the robot write your own
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
by dgellow - I've been seeing a drop in PRs against my repositories. I have a couple of repositories with around a hundred stars. Nothing spectacular but they were getting occasional PRs until last year. This year I've had almost none so far. My theory is that LLMs prefer sticking to mainstream projects. And since lots of developers are now leaning heavily on LLMs, they are biased to ignoring most of what I provide.
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.
- Most people don’t have the ability to read code well enough to determine if an LLM output is good or not. And most people don’t have subscriptions to models that can develop non-trivial programs…
Maybe this will be a real problem in a couple years though.
by bee_rider - LLM access is not yet universally available. There are those who can't exactly afford it. And there are also those with access but there are occasional or perennial issues, like Claude outages and general degraded performance over time. For example couple of months ago when I just started using Claude, I was easily making good progress on multiple projects within a week. Nowadays I'm hardly getting through much of anything as most of the time Claude is just showing spinners, and it also feels like the code quality has taken a nosedive.by skeledrew
- >> Whereas earlier you had to use something that was mass produced to be satisfactory for everyone
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.
- 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.
by gausswho - > Why use someone's project when you can just have the robot write your own?
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.
by simonw - > 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)
by dgellow - 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.by dnautics
- 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.
by grokys - This reminds me of the critique of certain kinds of art.
"It's so easy, I could have done that myself"
Well yeah, but you didn't.
by eddd-ddde - > If an AI improves developer productivity so much,
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?
- I'm finding that AI, when successful, gives me 2-3x speedup. It's not the kind of thing I can give high-level instructions to like I can to a human.
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.
by gwbas1c