I think this is a reasonable decision (although maybe increasingly insufficient).
It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers.
In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly generate PRs that might look superficially correct. Effort can still have been out into those PRs, but there is no way to tell without spending time reviewing in more detail.
Policies like this help decrease that review burden, by outright rejecting what can be identified as LLM-generated code at a glance. That is probably a fair bit today, but it might get harder over time, though, so I suspect eventually we will see a shift towards more trust-based models, where you cannot submit PRs if you haven't been approved in advance somehow.
Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.
For well-intended open source contributions using GenAI, my current rules of thumb are:
* Prefer an issue over a PR (after iterating on the issue, either you or the maintainer can use it as a prompt)
* Only open a PR if the review effort is less than the implementation effort.
Whether the latter is feasible depends on the project, but in one of the projects I'm involved in it's fairly obvious: it's a package manager where the work is typically verifying dependencies and constraints; links to upstream commits etc are a great shortcut for reviewers.
Unfortunately, LLMs generate useless word salad and nonsense even when working on issues text, you absolutely have to reword the writing from scratch otherwise it's just an annoyance and a complete waste of time. Even a good prompt doesn't help this all that much since it's just how the tool works under the hood: it doesn't have a goal of saying anything specific in the clearest possible way and inwardly rewording it until it does, it just writes stuff out that will hopefully end up seeming at least half-coherent. And their code is orders of magnitude worse than even their terrible English prose.
The problem was already there with lazy bug reports and inflammatory feature requests. Now there is a lazy (or inflammatory) accompanying code.
But there were also well-written bug reports with no code attached due to lack of time/skills that now can potentially become useful PRs if handled with application and engineering knowledge and good faith and will.
> Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons
Wait but under that assumption - LLMs being good enough - wouldn't the maintainer also be able to leverage LLMs to speed up the review?
Often feels to me like the current stance of arguments is missing something.
> Wait but under that assumption - LLMs being good enough - wouldn't the maintainer also be able to leverage LLMs to speed up the review?
This assumes that AI capable of writing passable code is also capable of a passable review. It also assumes that you save any time by trusting that review, if it missed something wrong then it's often actually more effort to go back and fix than it would've been to just read it yourself the first time.
It was maybe not quite clear enough in my comment, but this is more of a hypothetical future scenario - not at all where I assess LLMs are today or will get to in the foreseable future.
So it becomes a bit theoretical, but I guess if we had a future where LLMs could consistently write perfect code, it would not be too far fetched to also think it could perfectly review code, true enough. But either way the maintainer would still spend some time ensuring a contribution aligns with their vision and so forth, and there would still be close to zero incentive to allow outside contributors in that scenario. No matter what, that scenario is a bit of a fairytale at this point.
You can not trust the code or reviews it generates. You still have to review it manually.
I use Claude Code a lot, I generate a ton of changes, and I have to review it all because it makes stupid mistakes. And during reviews it misses stupid things. This review part is now the biggest bottleneck that can't yet be skipped.
An in an open source project many people can generate a lot more code than a few people can review.
This is not even about capabilities but responsibility. In an open source context where the maintainers take no responsibility for the code, it's perhaps easier. In a professional context, ultimately it's the human who is responsible, and the human has to make the call whether they trust the LLM enough.
Imagine someone vibe codes the code for a radiotherapy machine and it fries a patient (humans have made these errors). The developer won't be able to point to OpenAI and blame them for this, the developer is personally responsible for this (well, their employer is most likely). Ergo, in any setting where there is significant monetary or health risk at stake, humans have to review the code at least to show that they've done their due diligence.
I'm sure we are going to have some epic cases around someone messing up this way.
> Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.
Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.
Yes, I agree. It was just me playing with a hypothetical (but in my view not imminent) future where vibe-coding without review would somehow be good enough.
Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one.
That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance. To simply ban this is ... a choice, I guess. But it's not reasonable, in my book. It's like saying we won't use ci/cd, because it's automated stuff, we're purely manual here.
I think a lot of projects will find ways to adapt. Create good guidelines, help the community to use the best tools for the best tasks, and use automation wherever it makes sense.
At the end of the day slop is slop. You can always refuse to even look at something if you don't like the presentation. Or if the code is a mess. Or if it doesn't follow conventions. Or if a PR is +203323 lines, and so on. But attaching "LLMs aka AI" to the reasoning only invites drama, if anything it makes the effort of distinguishing good content from good looking content even harder, and so on. In the long run it won't be viable. If there's a good way to optimise a piece of code, it won't matter where that optimisation came from, as long as it can be proved it's good.
tl;dr; focus on better verification instead of better identification; prove that a change is good instead of focusing where it came from; test, learn and adapt. Dogma was never good.
At the moment verification at scale is an unsolved problem, though. As mentioned, I think this will act as a rough filter for now, but probably not work forever - and denying contributions from non-vetted contributors will likely end up being the new default.
Once outside contributions are rejected by default, the maintainers can of course choose whether or not to use LLMs or not.
I do think that it is a misconception that OSS software needs to "viable". OSS maintainers can have many motivations to build something, and just shipping a product might not be at the top of that list at all, and they certainly don't have that obligation. Personally, I use OSS as a way to build and design software with a level of gold plating that is not possible in most work settings, for the feeling that _I_ built something, and the pure joy of coding - using LLMs to write code would work directly against those goals. Whether LLMs are essential in more competitive environments is also something that there are mixed opinions on, but in those cases being dogmatic is certainly more risky.
> Or if the code is a mess. Or if it doesn't follow conventions.
In my experience these things are very easily fixable by ai, I just ask it to follow the patterns found and conventions used in the code and it does that pretty well.
Licensing is dependent on IPR, primarily copyright.
It is very unclear whether the output of an AI tool is subject to copyright.
So if someone uses AI to refactor some code, that refactored code isn't considered a derivative work which means that the refactored source is no longer covered by the copyright, or the license that depends on that.
Your analogy with CI/CD is flawed because while not all were convinced of the merits of CI/CD, it's also not technology built on vast energy use and copyright violation at a scale unseen in all of history, which has upended the hardware market, shaken the idea of job security for developers to its very foundation and done it while offering no really obvious benefits to groups wishing to produce really solid software. Maybe that comes eventually, but not at this level of maturity.
But you're right it's probably unenforceable. They will probably end up accepting PRs which were written with LLM assistance, but if they do it will be because it's well-written code that the contributor can explain in a way that doesn't sound to the maintainers like an LLM is answering their questions. And maybe at that point the community as a whole would have less to worry about - if we're still assuming that we're not setting ourselves up for horrible licence violation problems in the future when it turns out an LLM spat out something verbatim from a GPLed project.
> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable.
To outright accept LLM contributions would be as much "pure vibes" as banning it.
The thing is, those that maintain open source projects have to make a decision where they want to spend their time. It's open source, they are not being paid for it, they should and will decide what it acceptable and what is not.
If you dislike it, you are free to fork it and make a "LLM's welcome" fork. If, as you imply, the LLM contributions are invaluable, your fork should eventually become the better choice.
Or you can complain to the void that open source maintainers don't want to deal with low effort vibe coded bullshit PRs.
> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable.
The response to a large enough amount of data is always vibes. You cannot analyze it all so you offload it to your intuition.
> It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance.
What’s stopping the maintainers themselves from doing just that? Nothing.
Producing it through their own pipeline means they don’t have to guess at the intentions of someone else.
Maintainers just doing it themselves is just the logical conclusion. Why go through the process of vetting the contribution of some random person who says that they’ve used AI “a little” to check if it was maybe really 90%, whether they have ulterior motives... just do it yourself.
I feel like the pattern here is donate compute, not code. If agents are writing most of the software anyway, why deal with the overhead of reviewing other people's PRs? You're basically reviewing someone else's agent output when you could just run your own.
Maintainers could just accept feature requests, point their own agents at them using donated compute, and skip the whole review dance. You get code that actually matches the project's style and conventions, and nobody has to spend time cleaning up after a stranger's slightly-off take on how things should work.
Well, it's not quite that easy because someone still has to test the agent's output and make sure it works as expected, which it often doesn't. In many cases, they still need to read the code and make sure that it does what it's supposed to do. Or they may need to spend time coming up with an effective prompt, which can be harder than it sounds for complicated projects where models will fail if you ask them to implement a feature without giving them detailed guidance on how to do so.
Or even more efficient: the model we already have. Donate money and let the maintainer decide whether to convert it into tokens or mash the keys themself.
If you're curious to see what everyone else is doing, I did a survey of over 100 major source available projects and four of them banned AI assisted commits (NetBSD, GIMP, Zig, and qemu).
On the other hand projects with AI assisted commits you can easily find include Linux, curl, io_uring, MariaDB, DuckDB, Elasticsearch, and so on. Of the 112 projects surveyed, 70 of them had AI assisted commits already.
Thanks. Now I know which software to avoid: the ones that ban legitimate tool use. I have no respect for this protectionist prohibition. These people would insist on driving horse carriages 125 years ago because people were still getting used to driving automobiles.
Everyone is starting to make AI a moral question one way or another. So your moral view is progress must march on unimpeded by private actors?
I find that pretty original. I think progress will march largely unimpeded. I would be wary of unhinged government intervention, but I wouldn’t begrudge private actors for not getting on with the ticket.
I think you'll find the luddites to be a more informative historical analogy. A new tool arrives in an industry staffed by craftsmen, providing capital a lever to raise profits at the expense of quality. Is it surprising that worker co-ops would choose not to pull that lever?
I think we will be getting into an interesting situation soon, where project maintainers use LLMs because they truly are useful in many cases, but will ban contributors for doing so, because they can't review how well did the user guide the LLM.
* modelling a solution that is consistent with the existing modelling/architecture of the software and moves modelling and architecture in the right direction
* verifying that the the implementation of the solution is not introducing accidental complexity
These are the things LLMs can't do well yet. That's where contributions will be most appreciated. Producing code won't be it, maintainers have their own LLM subscriptions.
I still think there is value in external contributors solving problems using LLMs, assuming they do the research and know what they are doing. Getting a well written and tested solution from LLM is not as easy as writing a good prompt, it's a much longer/iterative process.
If an author of a PR just generated code with an LLM, the GitHub PR becomes an incredibly inefficient interface between a repository owner and the LLM. A much better use of the owner time would be to interact with LLM directly instead of responding to LLM generated PR, waiting for updates, responding again, etc.
As a project maintainer, I don't want to interact with someone's LLM. If a person submits a PR, using LLM or not, the person is responsible for any problems with it. How they respond to review is a good indicator if they actually understand the code. And if they used a bot to submit the PR, I'd simply consider it a spam.
Yep, the indirection through the PR author is almost always inefficient and error-prone unless the author is really knowledgable about the code (many aren't).
And in general a lot more people want to use LLMs to generate things than want to consume the things LLMs generate. Some of the more bullish people should think harder about this pretty clear trend.
that's already happening tbh. the real issue isn't hypocrisy though, it's that maintainers reviewing their own LLM output have full context on what they asked for and can verify it against their mental model of the codebase. a random contributor's LLM output is basically unverifiable, you don't know what prompt produced it or whether the person even understood the code they're submitting.
How is that different than before LLMs? You have no idea how the person came up with it, or whether they really understood.
We are inventing problems here. Fact is, an LLM writes better code than 95% of developers out there today. Yes, yes this is Lake Wobegone, everyone here is in the 1%. But for the world at large, I bet code quality goes up.
Maybe a future direction will be the submission of detailed research, specifications and change plans for feature requests. Something that can be assessed by a human and turned into working code by both slides.
I wonder if that is an opportunity to build an Open-Source platform focused on this, replacing GitHub as the collaboration platform of a time where code was valuable.
Some sort of LLM audit trail is needed (containing prompts used, model identifier and marking all code written by LLM). It could be even signed by LLM providers (but that wouldn't work with local models). Append only standard format that is required to be included in PR. It wouldn't be perfect (e.g. deleting the log completely), but it might help with code reviews.
This would probably be more useful to help you see what (and how) was written by LLMs. Not really to catch bad actors trying to hide LLM use.
This would be a useful feature to bake into the commits generated by agents. Heck you don’t even need to wait — just change your prompt to tell it to include more context in its commit messages and to sign them as Claude rather than yourself…
The GPL talks about "the preferred form for modification of the software", and I'm starting to think that anything which involves any kind of LLM agent should be including all the text that the user gave to it as well. Prompts, etc.
Of course, even then it's not reproducible and requires proprietary software!
Except the GPL is dependent on the author having copyright over the original software but the output of an LLM may not be covered by copyright as a derivative work.
some projects (I came across Mastodon's policy[0] which they say was inspired by ghostty and others) which have a more relaxed policy of basically "LLMs are ok so long as you understand what they did, and you own it".
But I think different projects have different needs.
The "interesting situation" is that maintainers are unable to cheaply distinguish slop from good contributions so they will simply stop accepting outside contributions.
This will cut off one of the genuine entry points to the industry where all you really needed was raw talent.
> any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed
Note the word "clearly". Weirdly, as a native English speaker this term makes the policy less strict. What about submarine LLM submissions?
I have no beef with Redox OS. I wish them well. This feels like the newest form of OSS virtue signaling.
That would constitute an attempt to circumvent their policy, with the consequence of being banned from the project. In other words, it makes not clearly labeling any LLM use a bannable offense.
Don't ask don't tell looks like a reasonable policy. If no one can tell that your code was written by an LLM and you claim authorship, then whether you have actually written it is a matter of your conscience.
As a native English speaker I read this as two parts. If it's obvious, the response is immediate and not up for debate. If it's not obvious then it falls in the second part - "any attempt to bypass this policy will result in a ban from the project".
A submarine submission, if discovered, will result in a ban.
Using the phrase "virtual signaling" long ago became a meaningless term other than to indicate one's views in a culture war. 10 years ago David Shariatmadari wrote "The very act of accusing someone of virtue signalling is an act of virtue signalling in itself", https://www.theguardian.com/commentisfree/2016/jan/20/virtue... .
Somewhat off topic, but I can’t believe someone got paid to write that article, what a load of crap. It’s like saying that fallacies don’t exist because sometimes people incorrectly claim the other side is arguing fallaciously.
If you go by the literal definition in the article, it’s very clear what OP meant when he said the AI policy is virtue-signaling, and it has absolutely nothing to do with the culture war.
The LLM ban is unenforceable, they must know this. Is it to scare off the most obvious stuff and have a way to kick people off easily in case of incomplete evidence?
It is enforceable, I think you mean to say that it cannot be prevented since people can attempt to hide their usage? Most rules and laws are like that, you proscribe some behavior but that doesn't prevent people from doing it. Therefore you typically need to also define punishments:
> This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project.
You can slap on any punishment clause you want but verifying LLM-origin content without some kind of confession is shaky at best outside obvious cases like ChatGPT meta-fingerprints or copy-paste gaffes. Realistically, it boils down to vibes and suspicion unless you force everyone to record their keystrokes while coding which only works if you want surveillance. If the project ever matters at scale people will start discussing how enforceability degrades as outputs get more human-like.
What happens when the PR is clear, reasonable, short, checked by a human, and clearly fixes, implements, or otherwise improves the code base and has no alternative implementation that is reasonably different from the initially presented version?
I think the bigger point about enforcement is not whether you're able to detect "content submitted that is clearly labelled as LLM-generated", but that banning presumes you can identify the origin. Ie.: any individual contributor must be known to have (at most) one identity.
Once identity is guaranteed, privileges basically come down to reputation — which in this case is a binary "you're okay until we detect content that is clearly labelled as LLM-generated".
[Added]
Note that identity (especially avoiding duplicate identity) is not easily solved.
I suspect this is for now just a rough filter to remove the lowest effort PRs. It likely will not be enough for long, though, so I suspect we will see default deny policies soon enough, and various different approaches to screening potential contributors.
Any sufficiently advanced LLM-slop will be indistinguishable from regular human-slop. But that’s what they are after.
This heuristic lets the project flag problematic slop with minimal investment avoiding the cost issues with reviewing low-quality low-effort high-volume contributions, which should be near ideal.
Much like banning pornography on an artistic photo site, the perfect application on the borderline of the rule is far less important than filtering power “I know it when I see it” provides to the standard case. Plus, smut peddlers aren’t likely to set an OpenClaw bot-agent swarm loose arguing the point with you for days then posting blogs and medium articles attacking you personally for “discrimination”.
A sign to point at when you get someone is posting "I asked AI to fix this and got this". You can stop reading and any arguments right there. Saving lot of time and effort.
Just require that the CLA/Certificate of Origin statement be printed out, signed, and mailed with an envelope and stamp, where besides attesting that they appropriately license their contributions ((A)GPL, BSD, MIT, or whatever) and have the authority to do so, that they also attest that they haven't used any LLMs for their contributions. This will strongly deter direct LLM usage. Indirect usage, where people whip up LLM-generated PoCs that they then rewrite, will still probably go on, and go on without detection, but that's less objectionable morally (and legally) than trying to directly commit LLM code.
As an aside, I've noticed a huge drop off in license literacy amongst developers, as well as respect for the license choices of other developers/projects. I can't tell if LLMs caused this, but there's a noticeable difference from the way things were 10 years ago.
> As an aside, I've noticed a huge drop off in license literacy amongst developers
What do you mean by this? I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses. I typically had a "fuck it" attitude when it came to the license, and I assume quite a lot of other people shared that sentiment. The code is the fun bit.
Sarcasm? Nobody will be contributing with a complexe signing process like that, and it doesn't guarantee anything in the end, it's like a high tech pinky swear
Yep, that’s why my forks of all their libraries with bugs fixed such as https://github.com/pmarreck/zigimg/commit/52c4b9a557d38fe1e1... will never ever go back to upstream, just because an LLM did it. Lame, but oh well- their loss. Also, this is dumb because anyone who wants fixes like this will have to find a fork like mine with them, which is an increased maintenance burden.
Hugely unpopular opinion on HN, but I'd rather use code that is flawed while written by a human, versus code that has been generated by a LLM, even if it fixes bugs.
I'd gladly take a bug report, sure, but then I'd fix the issues myself. I'd never allow LLM code to be merged.
If you rely on llms, you're simply not going to make it. The person who showed their work on the math test is 9/10 times is doing better in life than the person that only knew how to use a calculator. Now how do we think things are going to turn out for the person that doesn't even think they need to learn how to use a calculator.
Just like when people started losing their ability to navigate without a GPS/Maps app, you will lose your ability to write solid code, solve problems, hell maybe even read well.
I want my brain to be strong in old age, and I actually love to write code unlike 99% in software apparently (like why did you people even start doing this career.. makes no sense to me).
I'm going to keep writing the code myself! Stop paying Billionaires for their thinking machines, its not going to work out well for you.
I went into software because I like building things and coming up with solid solutions to business problems that are of use to society. I would not describe myself with "love to code". It's a means to an end to pay bills and have a meaningful career. I think of myself more like a carpenter or craftsman.
I used a coding agent for the majority of my current project and I still got the "build stuff" itch scratched because Engineers are still responsible for the output and they are needed to interface between technical teams, UX, business people etc
> The person who showed their work on the math test is 9/10 times is doing better in life than the person that only knew how to use a calculator
Sure but once you learn long multiplication/division algorithms by hand there's not much point in using them. By high school everyone is using a calculator.
> Just like when people started losing their ability to navigate without a GPS/Maps app
Are you suggesting people shouldn't use Google Maps? Seems kind of nuts. Similar to calculators, the lesson here is that progress works by obviating the need to think about some thing. Paper maps and compasses work the same way, they render some older skill obsolete. The written word made memorization infinitely less valuable (and writing had its critics).
I don't think "LLMs making us dumber" is a real concern. Yes, people will lose some skills. Before calculators, adults were probably way better at doing arithmetic. But this isn't something worth prioritizing.
However, it is worth teaching people to code by hand, just like we still teach arithmetic and times tables. But ultimately, once we've learned these things, we're going to use tools that supercede them. There's nothig new or scary about this, and it will be a significant net win.
>I want my brain to be strong in old age, and I actually love to write code unlike 99% in software apparently (like why did you people even start doing this career.. makes no sense to me).
I am old now, and the unfortunate truth is that my brain isn't working as fast or as precise as when I was young. LLMs help me maintain some of my coding abilities.
It's like having a non-judgemental co-coder sitting at your side, you can discuss about the code you wrote and it will point out things you didn't think of.
Or I can tap into the immense knowledge about APIs LLMs have to keep up with change. I wouldn't be able to still read that much documentation and keep all of this.
I agree but only in the very long term. I think short-medium term, it's not going to matter as the MBA types get so caught up in the mania that results matter even less than they normally do.
One doesn't exclude the other. I still program myself; I actually have more time to do so because the LLM I pay some billionaire for is taking care of the mundane stuff. Before I had to do the mundane stuff myself. What I pay the billionaire is a laughable fraction compared to the time and energy I now have extra to spend on meaningful innovation.
Dangerous that all these projects keep going MIT. We wouldn't have an open source community if it weren't for protections against modification without sharing. Almost all software today would be proprietary, as it was before.
No. People shared code because they wanted to. Open standards are great tools against emerging monopolies. So the losing side used that. IBM lost OS/2 vs NT war. They propped up Linux. Intel wanted to have a second option to Microsoft in server space. AMD wants to gain some developers against Nvidia Cuda monopoly. That's the reason they contribute. Even Linux's own leadership decided against extra freedoms for users; they rejected GPLv3 to keep company contributions going. That's why LLVM gets the first implementations of certain optimizations and architectures, yet being permissive licensed.
Quite a bit of the Linux userspace is already permissively licensed. Nobody has built a full-fledged open source alternative yet. Because it is hard to build an ecosystem, it is hard to test thousands of different pieces of hardware. None of that would happen without well-paid engineers contributing.
You pay taxes to a government using it to wage wars bombing children schools.
Will you now live in hut a on the forest because you don't consent to it?
Readit News
It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers.
In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly generate PRs that might look superficially correct. Effort can still have been out into those PRs, but there is no way to tell without spending time reviewing in more detail.
Policies like this help decrease that review burden, by outright rejecting what can be identified as LLM-generated code at a glance. That is probably a fair bit today, but it might get harder over time, though, so I suspect eventually we will see a shift towards more trust-based models, where you cannot submit PRs if you haven't been approved in advance somehow.
Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.
* Prefer an issue over a PR (after iterating on the issue, either you or the maintainer can use it as a prompt)
* Only open a PR if the review effort is less than the implementation effort.
Whether the latter is feasible depends on the project, but in one of the projects I'm involved in it's fairly obvious: it's a package manager where the work is typically verifying dependencies and constraints; links to upstream commits etc are a great shortcut for reviewers.
The open source world has already been ripped off by AI the last thing they need is for AI to pollute the pedigree of the codebase.
Prompts from issue text makes a lot of sense.
Wait but under that assumption - LLMs being good enough - wouldn't the maintainer also be able to leverage LLMs to speed up the review?
Often feels to me like the current stance of arguments is missing something.
This assumes that AI capable of writing passable code is also capable of a passable review. It also assumes that you save any time by trusting that review, if it missed something wrong then it's often actually more effort to go back and fix than it would've been to just read it yourself the first time.
So it becomes a bit theoretical, but I guess if we had a future where LLMs could consistently write perfect code, it would not be too far fetched to also think it could perfectly review code, true enough. But either way the maintainer would still spend some time ensuring a contribution aligns with their vision and so forth, and there would still be close to zero incentive to allow outside contributors in that scenario. No matter what, that scenario is a bit of a fairytale at this point.
I use Claude Code a lot, I generate a ton of changes, and I have to review it all because it makes stupid mistakes. And during reviews it misses stupid things. This review part is now the biggest bottleneck that can't yet be skipped.
An in an open source project many people can generate a lot more code than a few people can review.
Imagine someone vibe codes the code for a radiotherapy machine and it fries a patient (humans have made these errors). The developer won't be able to point to OpenAI and blame them for this, the developer is personally responsible for this (well, their employer is most likely). Ergo, in any setting where there is significant monetary or health risk at stake, humans have to review the code at least to show that they've done their due diligence.
I'm sure we are going to have some epic cases around someone messing up this way.
Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.
That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance. To simply ban this is ... a choice, I guess. But it's not reasonable, in my book. It's like saying we won't use ci/cd, because it's automated stuff, we're purely manual here.
I think a lot of projects will find ways to adapt. Create good guidelines, help the community to use the best tools for the best tasks, and use automation wherever it makes sense.
At the end of the day slop is slop. You can always refuse to even look at something if you don't like the presentation. Or if the code is a mess. Or if it doesn't follow conventions. Or if a PR is +203323 lines, and so on. But attaching "LLMs aka AI" to the reasoning only invites drama, if anything it makes the effort of distinguishing good content from good looking content even harder, and so on. In the long run it won't be viable. If there's a good way to optimise a piece of code, it won't matter where that optimisation came from, as long as it can be proved it's good.
tl;dr; focus on better verification instead of better identification; prove that a change is good instead of focusing where it came from; test, learn and adapt. Dogma was never good.
Once outside contributions are rejected by default, the maintainers can of course choose whether or not to use LLMs or not.
I do think that it is a misconception that OSS software needs to "viable". OSS maintainers can have many motivations to build something, and just shipping a product might not be at the top of that list at all, and they certainly don't have that obligation. Personally, I use OSS as a way to build and design software with a level of gold plating that is not possible in most work settings, for the feeling that _I_ built something, and the pure joy of coding - using LLMs to write code would work directly against those goals. Whether LLMs are essential in more competitive environments is also something that there are mixed opinions on, but in those cases being dogmatic is certainly more risky.
In my experience these things are very easily fixable by ai, I just ask it to follow the patterns found and conventions used in the code and it does that pretty well.
Licensing is dependent on IPR, primarily copyright.
It is very unclear whether the output of an AI tool is subject to copyright.
So if someone uses AI to refactor some code, that refactored code isn't considered a derivative work which means that the refactored source is no longer covered by the copyright, or the license that depends on that.
But you're right it's probably unenforceable. They will probably end up accepting PRs which were written with LLM assistance, but if they do it will be because it's well-written code that the contributor can explain in a way that doesn't sound to the maintainers like an LLM is answering their questions. And maybe at that point the community as a whole would have less to worry about - if we're still assuming that we're not setting ourselves up for horrible licence violation problems in the future when it turns out an LLM spat out something verbatim from a GPLed project.
To outright accept LLM contributions would be as much "pure vibes" as banning it.
The thing is, those that maintain open source projects have to make a decision where they want to spend their time. It's open source, they are not being paid for it, they should and will decide what it acceptable and what is not.
If you dislike it, you are free to fork it and make a "LLM's welcome" fork. If, as you imply, the LLM contributions are invaluable, your fork should eventually become the better choice.
Or you can complain to the void that open source maintainers don't want to deal with low effort vibe coded bullshit PRs.
The response to a large enough amount of data is always vibes. You cannot analyze it all so you offload it to your intuition.
> It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance.
What’s stopping the maintainers themselves from doing just that? Nothing.
Producing it through their own pipeline means they don’t have to guess at the intentions of someone else.
Maintainers just doing it themselves is just the logical conclusion. Why go through the process of vetting the contribution of some random person who says that they’ve used AI “a little” to check if it was maybe really 90%, whether they have ulterior motives... just do it yourself.
Dead Comment
Dead Comment
But the maintainers can use AI too, for their reviewing.
Maintainers could just accept feature requests, point their own agents at them using donated compute, and skip the whole review dance. You get code that actually matches the project's style and conventions, and nobody has to spend time cleaning up after a stranger's slightly-off take on how things should work.
Dead Comment
On the other hand projects with AI assisted commits you can easily find include Linux, curl, io_uring, MariaDB, DuckDB, Elasticsearch, and so on. Of the 112 projects surveyed, 70 of them had AI assisted commits already.
https://theconsensus.dev/p/2026/03/02/source-available-proje...
I find that pretty original. I think progress will march largely unimpeded. I would be wary of unhinged government intervention, but I wouldn’t begrudge private actors for not getting on with the ticket.
Deleted Comment
Dead Comment
* understanding the problem
* modelling a solution that is consistent with the existing modelling/architecture of the software and moves modelling and architecture in the right direction
* verifying that the the implementation of the solution is not introducing accidental complexity
These are the things LLMs can't do well yet. That's where contributions will be most appreciated. Producing code won't be it, maintainers have their own LLM subscriptions.
Dead Comment
We are inventing problems here. Fact is, an LLM writes better code than 95% of developers out there today. Yes, yes this is Lake Wobegone, everyone here is in the 1%. But for the world at large, I bet code quality goes up.
This would probably be more useful to help you see what (and how) was written by LLMs. Not really to catch bad actors trying to hide LLM use.
Of course, even then it's not reproducible and requires proprietary software!
That breaks "copyleft" entirely.
But I think different projects have different needs.
[0] https://github.com/mastodon/.github/blob/main/AI_POLICY.md
This will cut off one of the genuine entry points to the industry where all you really needed was raw talent.
I have no beef with Redox OS. I wish them well. This feels like the newest form of OSS virtue signaling.
That would constitute an attempt to circumvent their policy, with the consequence of being banned from the project. In other words, it makes not clearly labeling any LLM use a bannable offense.
Deleted Comment
A submarine submission, if discovered, will result in a ban.
Using the phrase "virtual signaling" long ago became a meaningless term other than to indicate one's views in a culture war. 10 years ago David Shariatmadari wrote "The very act of accusing someone of virtue signalling is an act of virtue signalling in itself", https://www.theguardian.com/commentisfree/2016/jan/20/virtue... .
If you go by the literal definition in the article, it’s very clear what OP meant when he said the AI policy is virtue-signaling, and it has absolutely nothing to do with the culture war.
> This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project.
Once identity is guaranteed, privileges basically come down to reputation — which in this case is a binary "you're okay until we detect content that is clearly labelled as LLM-generated".
[Added]
Note that identity (especially avoiding duplicate identity) is not easily solved.
This heuristic lets the project flag problematic slop with minimal investment avoiding the cost issues with reviewing low-quality low-effort high-volume contributions, which should be near ideal.
Much like banning pornography on an artistic photo site, the perfect application on the borderline of the rule is far less important than filtering power “I know it when I see it” provides to the standard case. Plus, smut peddlers aren’t likely to set an OpenClaw bot-agent swarm loose arguing the point with you for days then posting blogs and medium articles attacking you personally for “discrimination”.
Deleted Comment
Just require that the CLA/Certificate of Origin statement be printed out, signed, and mailed with an envelope and stamp, where besides attesting that they appropriately license their contributions ((A)GPL, BSD, MIT, or whatever) and have the authority to do so, that they also attest that they haven't used any LLMs for their contributions. This will strongly deter direct LLM usage. Indirect usage, where people whip up LLM-generated PoCs that they then rewrite, will still probably go on, and go on without detection, but that's less objectionable morally (and legally) than trying to directly commit LLM code.
As an aside, I've noticed a huge drop off in license literacy amongst developers, as well as respect for the license choices of other developers/projects. I can't tell if LLMs caused this, but there's a noticeable difference from the way things were 10 years ago.
What do you mean by this? I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses. I typically had a "fuck it" attitude when it came to the license, and I assume quite a lot of other people shared that sentiment. The code is the fun bit.
https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy
https://github.com/zigimg/zigimg/pull/313
Or a human will provide the fix?
I'd gladly take a bug report, sure, but then I'd fix the issues myself. I'd never allow LLM code to be merged.
Just like when people started losing their ability to navigate without a GPS/Maps app, you will lose your ability to write solid code, solve problems, hell maybe even read well.
I want my brain to be strong in old age, and I actually love to write code unlike 99% in software apparently (like why did you people even start doing this career.. makes no sense to me).
I'm going to keep writing the code myself! Stop paying Billionaires for their thinking machines, its not going to work out well for you.
I used a coding agent for the majority of my current project and I still got the "build stuff" itch scratched because Engineers are still responsible for the output and they are needed to interface between technical teams, UX, business people etc
Sure but once you learn long multiplication/division algorithms by hand there's not much point in using them. By high school everyone is using a calculator.
> Just like when people started losing their ability to navigate without a GPS/Maps app
Are you suggesting people shouldn't use Google Maps? Seems kind of nuts. Similar to calculators, the lesson here is that progress works by obviating the need to think about some thing. Paper maps and compasses work the same way, they render some older skill obsolete. The written word made memorization infinitely less valuable (and writing had its critics).
I don't think "LLMs making us dumber" is a real concern. Yes, people will lose some skills. Before calculators, adults were probably way better at doing arithmetic. But this isn't something worth prioritizing.
However, it is worth teaching people to code by hand, just like we still teach arithmetic and times tables. But ultimately, once we've learned these things, we're going to use tools that supercede them. There's nothig new or scary about this, and it will be a significant net win.
I am old now, and the unfortunate truth is that my brain isn't working as fast or as precise as when I was young. LLMs help me maintain some of my coding abilities.
It's like having a non-judgemental co-coder sitting at your side, you can discuss about the code you wrote and it will point out things you didn't think of.
Or I can tap into the immense knowledge about APIs LLMs have to keep up with change. I wouldn't be able to still read that much documentation and keep all of this.
Quite a bit of the Linux userspace is already permissively licensed. Nobody has built a full-fledged open source alternative yet. Because it is hard to build an ecosystem, it is hard to test thousands of different pieces of hardware. None of that would happen without well-paid engineers contributing.
You pay taxes to a government using it to wage wars bombing children schools. Will you now live in hut a on the forest because you don't consent to it?