Debian is the latest in an ever-growing list of projects to wrestle (again) with the question o [...]
Debian is the latest in an ever-growing list of projects to wrestle (again) with the question of LLM-generated contributions; the latest debate stared in mid-February, after Lucas Nussbaum opened a discussion with a draft general resolution (GR) on whether Debian should accept AI-assisted contributions. It seems to have, mostly, subsided without a GR being put forward or any decisions being made, but the conversation was illuminating nonetheless.
Nussbaum said that Debian probably needed to have a
discussion "to understand where we stand regarding AI-assisted contributions to
Debian
" based on some recent discussions, though it was not clear
what discussions he was referring to. Whatever the spark was, Nussbaum
put forward the draft GR to clarify Debian's stance on allowing
AI-assisted contributions. He said that he would wait a couple of days
to collect feedback before formally submitting the GR.
The staff here at LWN.net really appreciate the subscribers who make our work possible. Is there a chance we could interest you in becoming one of them?
His proposal would allow "AI-assisted contributions (partially
or fully generated by an LLM)
" if a number of conditions were
met. For example, it would require explicit disclosure if "a
significant portion of the contribution is taken from a tool without
manual modification
", and labeling of such contributions with
"a clear disclaimer or a machine-readable tag like
'[AI-Generated]'
." It also spells out that contributors should
"fully understand
" their submissions and would be accountable
for the contributions, "including vouching for the technical merit,
security, license compliance, and utility of their
submissions
". The GR would also prohibit using generative-AI tools
with non-public or sensitive project information, including private
mailing lists or embargoed security reports.
AI is a marketing term
It is fair to say that it is difficult to have an effective conversation about a technology when pinning down accurate terminology is like trying to nail Jell-O to a tree. AI is the catch-all term, but much (not all) of the technology in question is actually tooling around large language models (LLMs). When participants have differing ideas of what is being discussed, deciding whether the thing should be allowed may pose something of a problem.
Russ Allbery asked for people to
be more precise in their descriptions of the technologies that their proposals might
affect. He asserted that it has become common for AI, as a term, "to be so
amorphously and sloppily defined that it could encompass every physical object in the
universe
". If the project is going to make policy, he said, it needed to be very
specific about what it was making policy about:
An LLM has some level of defined meaning, although even there it would be nice if people were specific. Reinforcement learning is a specific technique with some interesting implications, such as the existence of labeled test data used to train the algorithm. "AI" just means whatever the person writing a given message wants it to mean and often changes meaning from one message to the next, which makes it not useful for writing any sort of durable policy.
Gunnar Wolf agreed with Allbery, but Nussbaum claimed that the specific technology did not matter. The proposal boiled down to the use of automated tools for code analysis and generation:
I see the problem we face as similar to the historical questions surrounding the use of BitKeeper by Linux (except that the choice of BitKeeper imposed its use by other contributors). It is also similar to the discussions about proprietary security analysis tools: since those tools are proprietary, should we ignore the vulnerability reports they issue?
If we were to adopt a hard-line "anti-tools" stance, I would find it very hard to draw a clear line.
Drawing clear lines, however, is something that a number of Debian developers felt
was important. Sean Whitton proposed that
the GR should not only say "LLM" rather than "AI", but it should also
distinguish between the uses of LLMs, such as code review, generating
prototypes, or generating production code. He envisioned ballot options that could
allow some, but not all, of those uses. Distinguishing between the various
so-called AI technologies would help in that regard. He urged
Nussbaum "not to argue too hard for something that is more general than LLMs
because that might alienate the people you want to agree to disagree with
."
Andrea Pappacoda said that
the specific technology mattered a lot; he wanted the proposal to have clear
boundaries and avoid broad terms like AI. He was uncomfortable with the idea of
banning LLMs, and not sure where to draw the line. "What I can confidently say,
though, is that a project like Claude's C
Compiler should not have a place in Debian.
"
Beyond terminology
The conversation did not focus solely on the terminology, of course. Simon Richter had questions about the implications of allowing AI-driven contributions from the standpoint of onboarding new contributors to Debian. An AI agent, he said, could take the place of a junior developer. Both could perform basic tasks under guidance, but the AI agent would not learn anything from the exchange; the project resources spent in guiding such a tool do not result in long-lasting knowledge transfer.
AI use presents us (and the commercial software world as well) with a similar problem: there is a massive skill gap between "gets some results" and "consistently and sustainably delivers results", bridging that gap essentially requires starting from scratch, but is required to achieve independence from the operators of the AI service, and this gap is disrupting the pipeline of new entrants.
He called that the onboarding problem, and said that an AI policy
needed to solve that problem; he did not want to discourage people by rejecting
contributions or expend resources on mentoring people who did not want to be
mentored. Accepting AI-assisted drive-by contributions is harmful because it is a
missed opportunity to onboard a new contributor. "The best-case outcome is that a
trivial problem got solved without actually onboarding a new contributor, and the
worst-case outcome is that the new contributor is just proxying between an AI and the
maintainer
". He also expressed concerns around the costs associated with such
tools, and speculated it might discourage contribution from users who could not
afford to use for-pay tools.
Nussbaum agreed that the
cost could be a problem in the future. For now, he said, it is not an issue because
there are vendors providing access for free, but that could change. He disagreed that
Debian was likely to run out of tasks suitable for new contributors, even if it does
accept AI-driven contributions, and suggested that it may make harder tasks more
accessible. He pointed to a study
written by an Anthropic employee and a person participating in the company's fellows
program, about how the use of AI impacts skill formation: "A takeaway is that
there are very different ways to interact with AI, that produce very different
results both in terms of speed and of understanding
". He did not seem to be
persuaded that use of AI tools would be a net negative in onboarding new
contributors.
Ted Ts'o argued against the idea that AI would have a negative impact:
Some anti-AI voices are concerned that use of AI will decrease the ability to gain seasoned contributors, with the implied concern that this is self-defeating because it restricts the ability to gain new members in the future. And you are now saying we should gate keep contributors that might be using AI as being unworthy of contributing to Debian? I'd say that is even more self-defeating.
Matthew Vernon said that
the proposed GR minimized the ethical dimension of using generative AI. The
organizations that are developing and marketing tools like ChatGPT and Claude are
behaving unethically, he said, by systematically damaging the wider commons in the
form of automated scraping and doing as they like with others' intellectual
property. "They hoover up content as hard as they possibly can, with scant if any
regard to its copyright or licensing
". He also cited environmental concerns and
other harms that are attributed to generative AI tools, "from non-consensual
nudification to the flooding of free software projects with bogus security
reports
". He felt that Debian should take a clear stand against those tools and
encourage other projects to do the same:
At its best, Debian is a group of people who come together to make the world a better place through free software. I think we should be centering the appalling behaviour of the organisations who are pushing genAI on everyone, and the real harms they are causing; and we should be pushing back on the idea that genAI is either a social good or inevitable.
There was also debate around the question of copyright, both in terms of the licenses of material used to train models, as well as the output of LLM tools. Jonathan Dowland thought that it might be better to forbid some contributions now, since some see risks in accepting such contributions, and then relax the project's position later on when the legal situation is clearer.
Thorsten Glaser took a
particularly harsh stance against LLM-driven contributions, going so far as to
suggest that some upstream projects should be forced out of Debian's main
archive into non-free
unless "the maintainers revert known slop commits
". Ansgar Burchardt pointed
out that would have the effect of banning the Linux kernel, Python, LLVM, and
others. Glaser's proposal did not seem particularly popular. He had taken a similar
stance on AI models in 2025; he argued most should be outside the main archive, when the project discussed a GR about AI
models and the Debian Free Software Guidelines (DFSG). That GR never came to a vote,
in part because it was unclear whether the language would forbid anti-spam
technologies because one could not include the corpus of spam used as training data
along with filters.
Allbery did not want to touch on copyright issues but had a few words to
say about the quality of AI-assisted code. It is common for people to object to code
generated by LLMs on quality grounds, but he said that argument does not make
sense. Humans are capable of producing better code than LLMs, but they are also
capable of producing worse code too. "Writing meaningless slop requires no
creativity; writing really bad code requires human ingenuity.
"
Bdale Garbee seconded
that notion, and said that he was reluctant to take a hard stance one way or the
other. "I see it as just another evolutionary stage we don't really understand the
longer term positive and negative impacts of yet.
" He wanted to focus on
long-term implications and questions such as "what is the preferred form of
modification for code written by issuing chat prompts?
" Nussbaum answered that
would be "the input to the tool, not the generated source code
".
That may not be an entirely satisfying answer, however, given that LLM output is not deterministic and the various providers of LLM tools retire models with some frequency. A user may have the prompt and other materials fed to an LLM to generate a result at a specific point in time, but it might generate a much different result later on, even if one has access to the same vendor's tools or models to run locally.
Debian isn't ready
It is clear from the discussion that Debian developers are not of one mind on the question of accepting AI-generated contributions; the developers have not yet even converged on a shared definition of what constitutes an AI-generated contribution.
What many do seem to agree on is that Debian is not quite ready to vote on a
GR about AI-generated contributions. On March 3, Nussbaum said
that he had proposed the GR "in response to various attacks against people using
AI in the context of Debian
"; he felt then it was something that needed to be dealt
with urgently. However, the GR discussion had been civil and interesting. As
long as the discussions around AI remained calm and productive, the project could
just continue exploring the topic in mailing-list discussions. He guessed that,
if there were a GR, "the winning option would probably be very nuanced, allowing
AI but with a set of safeguards
".
The questions of what to do about AI models in the archive, how to handle upstream code generated with LLMs, and LLM-generated contributions written specifically for Debian remain unanswered. For now, it seems, they will continue to be handled on a case-by-case basis by applying Debian's existing policies. Given the complexity of the questions, diverse opinions, and rapid rate of change of technologies lumped in under the "AI" umbrella, that may be the best possible, and least disruptive, outcome for now.
Read the original article
Comments
My two cents: I've been coding practically my entire life, but a few years back I sustained a pretty significant and lasting injury to my wrists. As such, I have very little tolerance for typing. It's been quite a problem and made full time work impossible.
With the advent of LLMs, AI-autocomplete, and agent-based development workflows, my ability to deliver reliable, high-quality code is restored and (arguably) better. Personally, I love the "hallucinations" as they help me fine-tune my prompts, base instructions, and reinforce intentionality; e.g. is that >really< the right solution/suggestion to accept? It's like peer programming without a battle of ego.
When analyzing problems, I think you have to look at both upsides and downsides. Folks have done well to debate the many, many downsides of AI and this tends to dominate the conversation. Probably thats a good thing.
But, on the flip side, I personally advocate hard for AI from the point-of-view on accessibility. I know (more-or-less) exactly what output I'm aiming for and control that obsessively, but it's AI and my voice at the helm instead of my fingertips.
I also think it incorrect to look at it from a perspective of "does the good outweigh the bad?". Relevant, yes, but utilitarian arguments often lead to counter-intuitive results and end up amplifying the problems they seek to solve.
I'd MUCH rather see a holistic embrace and integration of these tools into our ecosystems. Telling people "no AI!" (even if very well defined on what that means) is toothless against people with little regard for making the world (or just one specific repo) a better place.
> I'd MUCH rather see a holistic embrace and integration of these tools into our ecosystems. Telling people "no AI!" (even if very well defined on what that means) is toothless against people with little regard for making the world (or just one specific repo) a better place.
That doesn't address the controversy because you are a reasonable person assuming that other people using AI are reasonable like you, and know how to use AI correctly.
The rumors we hear have to do with projects inundated with more pull requests that they can review, the pull requests are obviously low quality, and the contributors' motives are selfish. IE, the PRs are to get credit for their Github profile. In this case, the pull requests aren't opened with the same good faith that you're putting into your work.
In general, a good policy towards AI submission really has to primarily address the "good faith" issue; and then explain how much tolerance the project has for vibecoding.
>other people are reasonable like you
No AI needed. Spam on the internet is a great example of the amount of unreasonable people on the internet. And for this I'll define unreasonable as "committing an action they would not want committed back at them".
AI here is the final nail in the coffin that many sysadmins have been dealing with for decades. And that is that unreasonable actors are a type of asymmetric warfare on the internet, specifically the global internet, because with some of these actors you have zero recourse. AI moved this from moderately drowning in crap to being crushed under an ocean of it.
Going to be interesting to see how human systems deal with this.
Every order of magnitude of difference constitutes a categorical difference.
The ability to create spam instantly, fitted perfectly to any situation, and doing that 24/7, everywhere, is very different from before. Before, spam was annoying but generally different enough to tell apart. It was also (in general) never too much as to make an entire platform useless.
With AI, the entire internet IS spam. No matter what you google or look at, there's a very high chance it's AI spam. The internet is super duper extra dead.
By pocksuppet 2026-03-113:36 And the incentive to spam. AI pull request writers feel like they're helping the project, not hurting it, so they do it a lot more.
By PunchyHamster 2026-03-117:411 reply And even if you figure out a reliable way to detect AI, guess what, USERS USE IT TOO for legitimate content, so you can't even use system like this. It's horrid
By Two_hands 2026-03-1114:30 I tried to build something: https://github.com/YM2132/PR_guard which aims to help in these cases. It's not perfect but with stronger AI detection tools (Pangram) it could be improved although the issue of cost then arises and who pays for it.
By esseph 2026-03-1116:31 "The internet is super duper extra dead."
I get unreasonably angry when I read this statement, or similar ones.
If you mean "portions of the web I go to or my email inbox", you may be right.
But for the rest of us that hang out in one or multiple private spaces, sometimes with connections between them, the internet is better connected and easier to find people, groups, information, and interests than ever before.
By shevy-java 2026-03-1018:591 reply > Spam on the internet is a great example of the amount of unreasonable people on the internet.
AI also generates spam though, so this is a much bigger problem than merely "unreasonable" people alone.
By pixl97 2026-03-1020:11 I mean, AI generates spam at the behest of unreasonable people currently, and we can just think of it as a powerful automated extension of other technologies. We could say it's a new problem in quantity but the same old problem in kind.
Now, with that said I don't think we're very far from automated agents causing problems all on their own.
By mschuster91 2026-03-1021:081 reply > Going to be interesting to see how human systems deal with this.
At least a bunch of lawyers already got hit when their court filings cited hallucinated cases. If this trend continues, I'll not be surprised when some end up disbarred.
By beachy 2026-03-115:21 This seems self-correcting. Every lawyer, and maybe court, will use AI to review the other party's filings for such things. AI overseeing what is true and what is not - nothing disturbing about that distopian future.
By johnmaguire 2026-03-1021:35 > AI here is the final nail in the coffin
so far*
By aleph_minus_one 2026-03-1023:231 reply > The rumors we hear have to do with projects inundated with more pull requests that they can review, the pull requests are obviously low quality, and the contributors' motives are selfish. IE, the PRs are to get credit for their Github profile. In this case, the pull requests aren't opened with the same good faith that you're putting into your work.
"Open source" does not mean "open contribution", i.e. just because the software is open source does not imply that your contribution (or in particular a not-high-effort contribution) is welcome.
A well-known application that is open source in the strictest sense, but not open contribution is SQLite.
By throwaway2037 2026-03-1112:541 reply Google Guava Java library is very similar -- open source, but almost never accepts outside contributions. Is the golang base library similar?
By ncruces 2026-03-1117:32 Not so far. All my contributions where welcomed.
By nextaccountic 2026-03-114:12 > The rumors we hear have to do with projects inundated with more pull requests that they can review, the pull requests are obviously low quality, and the contributors' motives are selfish.
There's a way to handle this: put an automatic AI review of every PR from new contributors. Fight fire with fire.
(Actually, this was the solution for spam even before LLMs. See "A plan for SPAM" by Paul Graham. Basically, if you have a cheap but accurate filter (specially, a filter you can train for your own patterns), it should be enabled as a first line of defense. Anything the filter doesn't catch and the user had to manually mark as spam should become data to improve the filter)
Moreover, if the review detects LLM-generated content but the user didn't disclose it, maybe there should be consequences
I see the solution as only engaging with reasonable persons and ignore the rest.
And the problem is filtering them out. That is real work that can be draining and demoralizing as unreasonable persons usually have their sad story why they are the way they are, but you cannot do therapy or coaching for random strangers while trying to get a project going.
So if people contribute good things, engage with them. If they contribute slob (AI generated or not) - you say no to them.
There must be a mechanism to rate the person submitting the PR. Anyone that wants to submit code to a well-known repo would first need to build a demonstrable history of making high-quality contributions to lesser known projects. I'm not very familiar with the open source scene but I'd find it very surprising if such a mechanism was not already in place. Seems like an obvious solution to the problem of vibe coders submitting slop.
By happymellon 2026-03-118:481 reply > build a demonstrable history of making high-quality contributions to lesser known projects.
> Seems like an obvious solution
I'm not sure how you would rank quality of submissions for grading contributors like this. Just because a project accepted your PR doesnt make it high quality, the best we can hope for is that it was better than no accepting it?
By rwmj 2026-03-1110:39 I think we need one of those solution to spam checklists[1], but for AI slop.
By lukan 2026-03-118:17 Oh it is a obvious solution, but not trivial to implement in a robust way.
How is an AI policy going to help prevent bad faith actors, though?
People who are doing those harmful things with AI aren’t going to stop because of a policy. They are just going to lie and not admit their submissions are AI generated.
At that point, you will still have to review the code and reject it if it is bad quality, just like you had to without an AI policy. The policy doesn’t make it any easier to filter out the bad faith AI submissions.
In fact, if we DO develop an efficient way to weed out the bad faith PRs that lie about using AI, then why do we need the policy at all? Just use that same system to weed out the bad submissions, and just skip the policy completely.
By robinsonb5 2026-03-1110:17 The point of a policy is to make a decision and then communicate that decision, so that you don't end up in a lengthy argument (or make inconsistent decisions) each time a particular situation arises.
You're right that it won't stop anyone doing harmful things with AI - all it does is codify what is and isn't considered acceptable by a project, and make it easier to justify rejections.
If a project wants to continue evaluating submissions on a case-by-base basis (and has the manpower to do it without the support of a policy) then that's entirely their choice, of course.
By Serenacula 2026-03-116:25 Some of them will lie. Plenty of people do just follow the rules or are acting in good faith though, so at the very least it can help cut it down.
By izacus 2026-03-1111:23 Policies protect people on the project by making rejection of bad faith actors easier on them (less energy spent, less work needed).
They're also a statement of organizational's support for people who reject slop PRs and help when the AI using author generates a smear blog post against the reviewer like we've seen before.
By PunchyHamster 2026-03-117:42 If the policy will make them at least double check AI didn't put its nonsense in, that's already a win
By utopiah 2026-03-118:26 Right, I was going to ask what "rumors"? The whole thing is documented in numerous projects, so much so that typically the inevitable AI guideline discussion is directly the result of a flood of low quality "contributions" that can't be handled by people managing the project.
It's not a rumor, it's a pattern.
By oliver_dr 2026-03-1018:41 [dead]
> But, on the flip side, I personally advocate hard for AI from the point-of-view on accessibility. I know (more-or-less) exactly what output I'm aiming for and control that obsessively, but it's AI and my voice at the helm instead of my fingertips.
This is the technique I've picked up and got the most from over the past few months. I don't give it hard, high-level problems and then review a giant set of changes to figure it out. I give it the technical solution I was already going to implement anyway, and then have it generate the code I otherwise would have written.
It cuts back dramatically on the review fatigue because I already know exactly what I'm expecting to see, so my reviews are primarily focused on the deviations from that.
By ok_dad 2026-03-1017:21 The only issue to beat in mind is that visual inspection is only about 85% accurate at its limit. I was responsible for incoming inspection at a medical device factory and visual inspection was the least reliable test for components that couldn’t be inspected for anything else. We always preferred to use machines (likes big CMM) where possible.
I also use LLM assistance, and I love it because it helps my ADHD brain get stuff done, but I definitely miss stuff that I wouldn’t miss by myself. It’s usually fairly simple mistakes to fix later but I still miss them initially.
I’ve been having luck with LLM reviewers though.
By distances 2026-03-1017:20 This, and I curate a tree of MD docs per topic to define the expected structure. It is supposed to output code that looks exactly like my code. If not, I manually edit it and perhaps update the docs.
This is how I've found myself to be productive with the tools, or since productivity is hard to measure, at least it's still a fun way to work. I do not need to type everything but I want a very exact outcome nonetheless.
Similar story, albeit not so extreme. I have similar ergonomic issues that crop up from time to time. My programming is not so impacted (spend more time thinking than typing, etc), but things like email, documentation, etc can be brutal (a lot more computer usage vs programming).
My simple solution: I use Whisper to transcribe my text, and feed the output to an LLM for cleanup (custom prompt). It's fantastic. Way better than stuff like Dragon. Now I get frustrated with transcribing using Google's default mechanism on Android - so inaccurate!
But the ability to take notes, dictate emails, etc using Whisper + LLM is invaluable. I likely would refuse to work for a company that won't let me put IP into an LLM.
Similarly, I take a lot of notes on paper, and would have to type them up. Tedious and painful. I switched to reading my notes aloud and use the above system to transcribe. Still painful. I recently realized Gemini will do a great job just reading my notes. So now I simply convert my notes to a photo and send to Gemini.
I categorize all my expenses. I have receipts from grocery stores where I highlight items into categories. You can imagine it's painful to enter that into a financial SW. I'm going to play with getting Gemini to look at the photo of the receipt and categorize and add up the categories for me.
All of these are cool applications on their own, but when you realize they're also improving your health ... clear win.
By mr-wendel 2026-03-1021:24 > I'm going to play with getting Gemini to look at the photo of the receipt and categorize and add up the categories for me.
FWIW, I have a pet project for a family recipe book. I normalize all recipes to a steps/instructions/ingredients JSON object. A webapp lets me snap photos of my old recipes and AI reliably yields perfectly structured objects back. The only thing I've had to fix is odd punctuation. For production, use is low, so `gemini-2.5-flash` works great and the low rate limits are fine. For development the `gemma-3-27b-it` model has MUCH higher limits and still does suprisingly well.
I'd bet you can pull this off and be very happy with the result.
By nunez 2026-03-112:50 I maintain expense tracking software that I wrote a while ago (before ChatGPT) that sends receipts and some metadata about them into Google Sheets (previously Expensify). A few months ago, I used Claude to add a feature that does exactly what you describe, but using the data types and framework I built for receipt parsing. It works really well.
Honestly, you can probably build what I built entirely with Gemini or Claude, probably with a nice frontend to boot.
By VorpalWay 2026-03-1017:31 I'm in a very similar situation: I have RSI and smarter-autocomplete style AI is a godsend. Unlike you I haven't found more complex AI (agent mode) particularly useful though for what I do (hard realtime C++ and Rust). So I avoid that. Plus it takes away the fun part of coding for me. (The journey matters more than the destination.)
The accessibility angle is really important here. What we need is a way to stop people who make contributions they don't understand and/or can not vouch they are the author for (the license question is very murky still, and no what the US supreme court said doesn't matter here in EU). This is difficult though.
By ivan_gammel 2026-03-1018:003 reply If you sign off the code and put your expertise and reputation behind it, AI becomes just an advanced autocomplete tool and, as such, should not count in “no AI” rules. It’s ok to use it, if that enables you to work.
this sounds reasonable, but in practice people will simply sign off on anything without having thoroughly reviewed it.
I agree with you that there's a huge distinction between code that a person understands as thoroughly as if they wrote it, and vibecoded stuff that no person actually understands. but actually doing something practical with that distinction is a difficult problem to solve.
By ivan_gammel 2026-03-1018:31 Unless the code is explicitly signed by AI as auto-commit, you cannot really tell if it was reviewed by human. So it essentially becomes a task of detecting specific AI code smell, which is barely noticeable in code reviewed by an experienced engineer. Very subjective, probably does not make sense at all.
By heavyset_go 2026-03-1019:213 reply > If you sign off the code and put your expertise and reputation behind it, AI becomes just an advanced autocomplete tool and, as such, should not count in “no AI” rules.
No, it's not that simple. AI generated code isn't owned by anyone, it can't be copyrighted, so it cannot be licensed.
This matters for open source projects that care about licensing. It should also matter for proprietary code bases, as anyone can copy and distribute "their" AI generated code for any purpose, including to compete with the "owner".
Care to explain? I see that statement in this thread, but I am not sure where this is grounded in fact.
This is very interesting, because there must be a line here that AI is crossing, and the line is not clearly determined yet.
Is linting code crossing the line?
Is re-factoring code with automated tools like bicycle repair man crossing the line ?
Is AI doing a code review and suggesting the code crossing the line ?
Is writing code with a specific prompt and sample code crossing the line?
Is producing a high level spec and let the AI design details and code the whole thing crossing the line ?
So, where exactly is this line ?
The next interesting question is how this could even be enforced. It's going to be hard to prove AI use when using strictly local models. Maybe they could embed some watermark like thing, but I am not sure this can't be circumvented.
Would really like to see some legal opinions on this ( unlikely to happen :)
The best I found is here: https://copyrightlately.com/thaler-is-dead-ai-copyright-ques...
By heavyset_go 2026-03-110:361 reply Here's what a Red Hat/IBM IP lawyer said about the chardet situation: https://github.com/chardet/chardet/issues/334#issuecomment-4...
Here's what the US Copyright Office says: https://newsroom.loc.gov/news/copyright-office-releases-part...
By golem14 2026-03-115:16 Yeah, that's what the link I posted also discusses (but then goes into much detail, but then offers no actual resolution).
I guess we will have to wait for cases to be brought and resolved at the courts. Not a great recipe to be the leader in AI, it must be said.
An updated copyright bill from legislature, or even positive regulatory action from the executive branch would speed things up and give much planning certainty to actors here in the US.
The rest of the world won't be waiting though -- maybe Europe, but Europe sadly doesn't really matter that much anymore :(
By ivan_gammel 2026-03-1021:471 reply > No, it's not that simple. AI generated code isn't owned by anyone, it can't be copyrighted, so it cannot be licensed.
There is no way to reliably identify code as AI-generated, unless it is explicitly labelled so. Good code produced by AI is not different from the good code produced by software engineer, so copyright is the last thing I would be worried about. Especially given the fact that reviewing all pull requests is substantial curation work on the side of maintainers: even if submitted code is not copyrightable, the final product is.
By heavyset_go 2026-03-1022:312 reply At least with LLM providers, they have your prompts and output, and if they wanted to, they could identify what code was AI generated or not.
Maybe they can be subpoenaed, maybe they can sell the data to parties who care like legal teams, maybe they can make it service anyone can plug a GitHub repo into, etc.
By BoredomIsFun 2026-03-119:59 Jokes on you - I run LLMs only locally, and besides the most widely deployed code generating tool AFAIR is JetBrain tiny ~200M LLM, builtin into their IDE.
By ivan_gammel 2026-03-113:49 Do you really think anyone is ready to spend money on legal to prove that some piece of code is public domain/has no author? That’s an expensive bet with uncertain outcome. And of course you can recover some information only if logs exist, which might not be the case, especially if local inference was used.
By fc417fc802 2026-03-113:582 reply > AI generated code isn't owned by anyone, it can't be copyrighted, so it cannot be licensed.
Translation: AI generated code is in the public domain in the US (until and unless something changes).
You can freely incorporate public domain code into any other codebase. You can relicense it as you see fit. Public domain material is not viral the way the GPL is.
Furthermore, if you make changes to public domain code the derivative product is subject to copyright.
By heavyset_go 2026-03-120:05 You can "relicense" it as you see fit, but anyone can just copy it and ignore your license and its terms entirely, it's not your property to put a license on.
See also Red Hat IP lawyer's opinion on trying to license the chardet "rewrite": https://github.com/chardet/chardet/issues/334#issuecomment-4...
By duskdozer 2026-03-115:32 Big tech employees better be quick then!
By Groxx 2026-03-1019:07 this is equivalent to claiming that automation has no negative side effects at all.
we do often choose automation when possible (especially in computer realms), but there are endless examples in programing and other fields of not-so-surprising-in-retrospect failures due to how automation affects human behavior.
so it's clearly not true. what we're debating is the amount of harm, not if there is any.
By heavyset_go 2026-03-1019:172 reply For projects, it's also a licensing issue. You don't own the copyright on AI generated code, no one does, so it can't be licensed.
By badsectoracula 2026-03-1019:231 reply This isn't an issue of "nobody can use this" but an "everyone can use this", i.e. projects can use AI generated code just fine and they own the copyright to any modifications they do to it.
Think of it like random noise in an image editor: you do own the random pixels since they're generated by the computer, but you can still use them as part of making your art - you do not lose copyright to your art because you used a random noise filter.
By shakna 2026-03-1019:30 Only if the generated text has no inherited copyright from the source data.
Which it might. And needs to be judged on a case-by-case basis, under current copyright law.
By charcircuit 2026-03-110:00 That is only true for trivial projects that require no human creativity. For such simple projects not having copyright for it is not a big deal.
By PunchyHamster 2026-03-117:40 > I'd MUCH rather see a holistic embrace and integration of these tools into our ecosystems. Telling people "no AI!" (even if very well defined on what that means) is toothless against people with little regard for making the world (or just one specific repo) a better place.
If it makes them go thru AI contributions to make sure there is no AI nonsense in them, that's already massive win.
The AI on itself is not a problem
> But, on the flip side, I personally advocate hard for AI from the point-of-view on accessibility. I know (more-or-less) exactly what output I'm aiming for and control that obsessively, but it's AI and my voice at the helm instead of my fingertips.
and you are the 1% (assuming your claims are true and not hallucinated gains, which are common in AI world too), vast majority of AI contributions are peak lazy, or at best goal-seeking with no regard of the target, consequences or quality
THAT is what people complain about. If AI was just used to shortcut the boring, augument the knowledge and produce better quality code, there would be very little arugments against AI-driven contributions. But that is not the case, the AI pundits will purposefully not check the AI output just because that would require time and knowledge and that looks bad on "how faster AI makes you" KPI
By veunes 2026-03-1018:22 Accessibility is an angle that rarely comes up in these debates and it's a strong one
>Personally, I love the "hallucinations" as they help me fine-tune my prompts, base instructions, and reinforce intentionality
This reads almost like satire of an AI power user. Why would you like it when an LLM makes things up? Because you get to write more prompts? Wouldn't it be better if it just didn't do that?
It's like saying "I love getting stuck in traffic because I get to drive longer!"
Sorry but that one sentence really stuck out to me
By tpmoney 2026-03-1114:49 I can’t say what the OP finds specifically useful but as an example if you’re aiming to make sure you’ve accurately and clearly documented / explained your intent, the misunderstandings and tangents AIs can go down are useful in the same way that putting your theoretically perfect UI into the hands of real users is also useful. It helps you want places where you assumed knowledge or understanding that someone else might not have.
Building up style guidelines for AI tools has been an eye opening experience in realizing how many stylistic choices we make that aren’t embedded in the linter, and aren’t documented anywhere else either. The resulting files have actually been a really good resource not just for the AI but for new developers on the project too.
It all depends on what your specific goal is.
By walthamstow 2026-03-1017:39 You worked with people before haven't you? Sometimes they make stuff up, or misremember stuff. Sometimes people who do this are brilliant and you end up learning a lot from them.
By mr-wendel 2026-03-1017:36 I appreciate the feedback.
I like it because I have no expectation of perfection-- out of others, myself, and especially not AI. I expect "good enough" and work upwards from there, and with (most) things, I find AI to be better than good enough.
By lawn 2026-03-1018:00 Yeah, if RSI is an issue why would you want to be forced to type more?
By brightball 2026-03-1018:35 Fwiw, I try to make sure we have an accessibility focused talk every year (if possible) at the Carolina Code Conference. Call for Speakers is open right now if you'd be interested in submitting something on your story.
By poulpy123 2026-03-1111:32 On the code side of the issue, I would say that AI completion and chat are ok because people are still forced to interact with the generated code. When coding with agents people have to go out of their way to do it
By raptor99 2026-03-1111:11 lol You are actually trying to argue and say "Oh actually, I love how AI fucks up, it makes me keep on my toes."
That's like saying I love hiring fuck ups that randomly do out of context and out of ruleset work for me when I ask them to perform tasks.
I would also argue to you that "folks" have done more well to debate the upsides of AI. It is pretty much all I ever see when I come to this website any more the last couple of years. Oh, and by coincidence, the operator/owner of the website just happens to be at the helm of ChatGPT. How convenient.
By petterroea 2026-03-114:021 reply As someone who got a pretty severe case of carpal tunnel in his youth that can still blow up today, I have to admit I have worried about my ability to work. "Will I have to become a manager?" Etc.
I think you have a good point
for some reason that hasn't happned to me yet. im only in my 50ies, but I have been on a split keyboard for a long time...
By petterroea 2026-03-115:48 I think a good routine matters a lot. I played a lot of video games in my youth and got carpal tunnel from there, and haven't been able to recover 100% since.
By yodsanklai 2026-03-112:121 reply > without a battle of ego.
This resonates. Recently, I've started to consider Claude as a partner. I like how he's willing to accept he's wrong when you provide evidence. It can be more pleasant than working with humans.
By MarsIronPI 2026-03-1113:362 reply Please don't anthropomorphize LLMs even further by assigning them gendered pronouns. LLMs are always "it"s. They're not alive, they're just really complicated linear algebra expressions. Prematurely anthropomorphizing them, even subtly like this, will come back to bite us if we keep doing it.
By cowboylowrez 2026-03-1118:44 I just think that if I treat my AI GF like that she'll just pout and end up giving me the silent treatment and I'll have to reboot her.
By ssk42 2026-03-1114:07 Can you defend that though? Does living mean needing cells? Does it mean possessing the ability to think and reason? Is Claude thinking and reasoning?
Putting aside the specifics for a second, I'm sorry to hear about your injury and glad you've found workarounds. I also think high-quality voice transcription might end up being a big thing for my health (there's no way typing as much as I do, in the positions I do, is good).
Much appreciated. I find is that referencing code in conversation is hard -- e.g. "underscore foo bar" vs `_fooBar`, "this dot Ls" vs `this.els`, etc happens often. Lower-powered models especially struggle with this, and make some frustrating assumptions. Premium models do way better, and at times are shockingly good. They just aren't remotely economically viable for me.
My solution so far is to use my instructions to call out the fact that my comments are transcribed and full of errors. I also focus more on "plan + apply" flows that guide agents to search out and identify code changes before anything is edited to ensure the relevant context (and any tricky references) are clearly established in the chat context.
It's kinda like learning vim (or emacs, if you prefer). First it was all about learning shortcuts and best practices to make efficient use of the tool. Then it was about creating a good .vimrc file to further reduce the overhead of coding sessions. Then it was about distributing that .vimrc across machines (and I did a LOT of ssh-based work) for consistency. Once that was done, it became unimaginable to code any other way.
It has been even more true here: agent-based workflows are useless without significant investment in creating and maintaining good project documentation, agent instructions, and finding ways to replicate that across repos (more microservice hell! :D) for consistency. There is also some conflict, especially in corporate environments, with where this information needs to live to be properly maintained.
Best of luck!
By duskdozer 2026-03-115:29 maybe you've done this already, but my first thought would be to make a preparser script that would take your likely voice inputs like "underscore foo bar" and translate to "_fooBar" which you would then pass on as input. i do something similar for a local TTS generator which often stumbles on certain words or weird characters
By hickelpickle 2026-03-110:43 Glad to see this response, I was wondering the other day how the affected accessibility. I remember reading a thread a few years back of visually challenged developers and their work flow and was kinda surprised there has been such little discussion around developer accessibility with the advent of ai agents and coding routines.
By hatmike 2026-03-110:06 >I love the "hallucinations"
Sorry, the rest of your comment could have the recipe for fat free deep fried blowjobs that cure cancer and I wouldn't read past that.
This is a bit of a straw man. The harms of AI in OSS are not from people needing accessibility tooling.
I disagree. I've done nothing to argue that the harm isn't real, downplayed it, nor misrepresented it.
I do agree that at large, the theoretical upsides of accessibility are almost certainly completely overshadowed by obvious downsides of AI. At least, for now anyway. Accessibility is a single instance of the general argument that "of course there are major upsides to using AI", and there a good chance the future only gets brighter.
My point, essentially, is that I think this is (yet another) area in life where you can't solve the problem by saying "don't do it", and enforcing it is cost-prohibitive. Saying "no AI!" isn't going to stop PR spam. It's not going to stop slop code. What is it going to stop (see edit)? "Bad" people won't care, and "good" people (who use/depend-on AI) will contribute less.
Thus I think we need to focus on developing robust systems around integrating AI. Certainly I'd love to see people adopt responsible disclosure policies as a starting point.
--
[edit] -- To answer some of my own question, there are obvious legal concerns that frequently come up. I have my opinions, but as in many legal matters, especially around IP, the water is murky and opinions are strongly held at both extremes and all to often having to fight a legal battle at all* is immediately a loss regardless of outcome.
By johnnyanmac 2026-03-1017:502 reply > I've done nothing to argue that the harm isn't real, downplayed it, nor misrepresented it.
You're literally saying that the upsides of hallucinanigenic gifts are worth the downside of collapsing society. I'd say that that is downplaying and misrepreting the issue. You even go so far to say
>Telling people "no AI!" (even if very well defined on what that means) is toothless against people with little regard for making the world (or just one specific repo) a better place.
These aren't balanced arguments taking both sides into considerations. It's a decision that your mindset is the only right one and anyone else is a opposing progress.
>You're literally saying that the upsides of hallucinanigenic gifts are worth the downside of collapsing society.
No, literally, he didn't.
By johnnyanmac 2026-03-1020:061 reply Yes, I literally quoted it.
By brewdad 2026-03-1116:28 You quoted him and then put words into his mouth based on your own strongly held beliefs. Words he neither said nor implied.
> are worth the downside of collapsing society.
At least in the US, society has been well on it's way to collapse before the LLM came out. "Fake news" is a great example of this.
>It's a decision that your mindset is the only right one and anyone else is a opposing progress.
So pretty much every religious group that's ever existed for any amount of time. Fundamentalism is totally unproblematic, right?
By heavyset_go 2026-03-1019:301 reply > At least in the US, society has been well on it's way to collapse before the LLM came out. "Fake news" is a great example of this.
IMO you can blame this on ML and the ability to microtarget[1] constituencies with propaganda that's been optimized, workshopped, focus grouped, etc to death.
Proto-AI got us there, LLMs are an accelerator in the same direction.
By duskdozer 2026-03-115:39 welp, flip another one from the "they definitely could do this and might be" pile to the "they've already been doing this for a long time" pile
By johnnyanmac 2026-03-1018:38 Sure. I always said Ai was a catalyst. It could have made society build up faster and accelerate progress, definitely.
But as modern society is, it is simply accelerating the low trust factors of it and collapsing jobs (even if it can't do them yet), because that's what was already happening. But hey, assets also accelerated up. For now.
>So pretty much every religious group that's ever existed for any amount of time. Fundamentalism is totally unproblematic, right?
Religion is a very interesting factor. I have many thoughts on it, but for now I'll just say that a good 95% of religious devouts utterly fail at following what their relevant scriptures say to do. We can extrapolate the meaning of that in so many ways from there.
By DonsDiscountGas 2026-03-1017:171 reply It's absolutely not a straw man, because OP and people like OP will be affected by any policy which limits or bans LLMs. Whether or not the policy writer intended it. So he deserves a voice.
By johnnyanmac 2026-03-1017:501 reply He doesn't think others deserve a voice, so why should I consider his?
The fact that you are engaging in this thread shows me you have considered my opinions, even if you reject them. I think thats great, even in the face of being told I advocate for the collapse of civilization and that I want others to shut up and not be heard.
It is a bit insulting, but I get that these issues are important and people feel like the stakes are sky-high: job loss, misallocation of resources, enshitification, increased social stratification, abrogation of personal responsibility, runaway corporate irresponsibility, amplification of bad actors, and just maybe that `p(doom)` is way higher than AI-optimists are willing to consider. Especially as AI makes advances into warfare, justice, and surveillance.
Even if you think AI is great, it's easy to acknowledge that all it may take is zealotry and the rot within politics to turn it into a disaster. You're absolutely right to identify that there are some eerie similarities to the "gun's don't kill people, people kill people" line of thinking.
There IS a lot to grapple with. However, I disagree with these conclusions (so far) and especially that AI is a unique danger to humanity. I also disagree that AI in any form is our salvation and going to elevate humanity to unfathomable heights (or anything close to that).
But, to bring it back to this specific topic, I think OSS projects stand to benefit (increasingly so as improvements continue) from AI and should avoid taking hardline stances against it.
By johnnyanmac 2026-03-1021:57 Sure. I don't necessarily think your opinion is radical. But it's also important to consider biases within oneself, especially when making use of text as a medium where the nuance of body language is lost.
The main thing that put me off on the comment was the outright dismissal of other opinions. That's rarely a recipe for a productive conversation.
>However, I disagree with these conclusions (so far) and especially that AI is a unique danger to humanity. I
I don't think it's unique. It's simply a catalyst. In good times with a system that looks out for its people, AI could do great things and accelerate productivity. It could even create jobs. None of that is out of reach, in theory.
But part of understanding the negative sentiment is understanding that we aren't in that high trust society with systems working for the citizen. So any bouts of productivity will only be used to accelerate that distrust. Looking at the marketing of AI these past few years confirms this. So why would anyone trust it this time?
Rampant layoffs, vague hand waves of "UBI will help" despite no structures in place for that, more than a dozen high profile kerfuffles that can only be described as a grift that made millions anyway, and persistent lobbying to try and make it illegal to regulate AI. These aren't the actions of people who have the best interests of the public masses in mind. It's modern day robber barons.
>I think OSS projects stand to benefit (increasingly so as improvements continue) from AI and should avoid taking hardline stances against it.
I don't have a hard line stance on how organizations handle AI. But from my end I hear that Ai has mostly lead to being a stressor on contributors trying to weed out the flood of low quality submissions. Ai or not (again, Ai is a catalyst. Not the root cause), that's a problem for what's ultimately a volunteer position that requires highly specialized skills.
If the choice comes between banning Ai submissions, restricting submissions altogether with a different system, or burning out talent trying to review all this slop: I don't think most orgs will choose the latter.
By martin-t 2026-03-1022:24 It's great that LLMs helped you but do you recognize that they are trained on thousands, perhaps millions of lifetimes of human work without the consent of the original authors and often quite explicitly against their will and their chosen license?
These people (myself included) made their work available free of charge under some very friendly conditions such as being credited or sharing work built upon theirs under the same license. Now we are being shit on because obscenely rich people think we are no longer relevant and that they can get away with it.
What happens to you if, say 2 years down the line, "AI" or AI has absorbed all your knowledge and can do all of your work instead of you better and faster? Do you imagine you'll keep paying for AI and having it work for you or can you also imagine a future where AI companies decide to cut out the middle-man (you) and take over your customers directly?
By shevy-java 2026-03-1018:581 reply > I'd MUCH rather see a holistic embrace and integration of these tools into our ecosystems.
I understand that your use case is different, so AI may help handicapped people. Nothing wrong with that.
The problem is that the term AI encompasses many things, and a lot of AI led to quality decay. There is a reason why Microsoft is now called Microslop. Personally I'd much prefer for AI to go away. It won't go away, of course, but I still would like to see it gone, even if I agree that the use case you described is objectively useful and better for you (and others who are handicapped).
> I also think it incorrect to look at it from a perspective of "does the good outweigh the bad?". Relevant, yes, but utilitarian arguments often lead to counter-intuitive results and end up amplifying the problems they seek to solve.
That is the same for every technology though. You always have a trade-off. So I don't think the question is incorrect at all - it applies the same just as it is for any other technology, too. I also disagree that utilitarian arguments by their intrinsic nature lead to counter-intuitive results. Which result would be counter-intuitive when you analyse a technology for its pros and cons?
> There is a reason why Microsoft is now called Microslop.
Because young people repeat things they see on social media?
By cruffle_duffle 2026-03-1023:45 You mean Micro$lop or the classic M$?
By QuercusMax 2026-03-1017:22 A few years ago I was in a place where I couldn't type on a computer keyboard for more than a few minutes without significant pain, and I fortunately had shifted into a role where I could oversee a bunch of junior engineers mostly via text chat (phone keyboard didn't hurt my hands as much) and occasional video/voice chat.
I'm much better now after tons of rehab work (no surgery, thankfully), but I don't have the stamina to type as much as I used to. I was always a heavy IDE user and a very fast coder, but I've moved platforms too many times and lost my muscle memory. A year ago I found the AI tools to be basically time-wasters, but now I can be as productive as before without incurring significant pain.
Fantastic point. I do think there was a bit of an over correction toward AI hostility because capitalism, and for good reason, but it did almost make it taboo to talk about legitimate use cases that are not related to bad AI use cases like instigating nuclear wars in war game simulations.
I think the ugly unspoken truth whether Mozilla or Debian or someone else, is that there are going to be plausible and valuable use cases and that AI as a paradigm is going to be a hard problem the same way that presiding over, say, a justice system is a hard problem (stay with me). What I mean is it can have a legitimate purpose but be prone to abuse and it's a matter of building in institutional safeguards and winning people's trust while never fully being able to eliminate risk.
It's easy for someone to roll their eyes at the idea that there's utility but accessibility is perfect and clear-eyed use case, that makes it harder to simply default to hedonic skepticism against any and all AI applications. I actually think it could have huge implications for leveling the playing field in the browser wars for my particular pet issue.
By LtWorf 2026-03-1018:41 I think generating slop and having others review it is bad even if you are disabled. I say this as a disabled person myself.
By Joel_Mckay 2026-03-1017:29 The premise LLM are "AI" is false, but are good at problems like context search, and isomorphic plagiarism.
Given the liabilities of relying on public and chat users markdown data to sell to other users without compensation raises a number of issues:
1. Copyright: LLM generated content can't be assigned copyright (USA), and thus may contaminate licensing agreements. It is likely public-domain, but also may conflict with GPL/LGPL when stolen IP bleeds through weak obfuscation. The risk has zero precedent cases so far (the Disney case slightly differs), but is likely a legal liability waiting to surface eventually.
2. Workmanship: All software is terrible, but some of it is useful. People that don't care about black-box obfuscated generated content, are also a maintenance and security liability. Seriously, folks should just retire if they can't be arsed to improve readable source tree structure.
3. Repeatability: As the models started consuming other LLM content, the behavioral vectors often also change the content output. Humans know when they don't know something, but an LLM will inject utter random nonsense every time. More importantly, the energy cost to get that error rate lower balloons exponentially.
4. Psychology: People do not think critically when something seems right 80% of the time. The LLM accuracy depends mostly on stealing content, but it stops working when there is nothing left to commit theft of service on. The web is now >53% slop and growing. Only the human user chat data is worth stealing now.
5. Manipulation: The frequency of bad bots AstroTurf forums with poisoned discourse is biasing the delusional. Some react emotionally instead of engaging the community in good faith, or shill hard for their cult of choice.
6. Sustainability: FOSS like all ecosystems is vulnerable to peer review exhaustion like the recent xz CVE fiasco. The LLM hidden hostile agent problem is currently impossible to solve, and thus cannot be trusted in hostile environments.
7. Ethics: Every LLM ruined town economic simulations, nuked humanity 94% of the time in every war game, and encouraged the delusional to kill IRL
While I am all for assistive technologies like better voice recognition, TTS, and individuals computer-user interfaces. Most will draw a line at slop code, and branch to a less chaotic source tree to work on.
I think it is hilarious some LLM proponents immediately assume everyone also has no clue how these models are implemented. =3
"A Day in the Life of an Ensh*ttificator "
Very reasonable stance. I see reviewing and accepting a PR is a question of trust - you trust the submitter to have done the most he can for the PR to be correct and useful.
Something might be required now as some people might think that just asking an LLM is "the most he can done", but it's not about using AI it's about being aware and responsible about using it.
By rustyhancock 2026-03-1015:402 reply Important though we generally assume few bad actors.
But like the XZ attack, we kind of have to assume that advanced perissitant threats are a reality for FOSS too.
I can envisage a Sybil attack where several seemingly disaparate contributors are actually one actor building a backdoor.
Right now we have a disparity in that many contributors can use LLMs but the recieving projects aren't able to review them as effectively with LLMs.
LLM generated content often (perhaps by definition) seems acceptable to LLMs. This is the critical issue.
If we had means of effectively assessing PRs objectively that would make this moot.
I wonder if those is a whole new class of issue. Is judging a PR harder than making one? It seems so right now
> Is judging a PR harder than making one?
Depends on the assumptions. If you assume good intent of the submitter and you spend time to explain what he should improve, why something is not good, etc, than it's a lot of effort. If you assume bad intent, you can just reject with something like "too large review from unproven user, please contribute something smaller first".
Yes, we might need to take things a bit slower, and build relations to the people you collaborate with in order to have some trust (this can also be attacked, but this was already possible).
By PowerfulWizard 2026-03-1017:26 On judging vs. making, also someone has to take time away from development to do code review. If the code being reviewed is written by someone who is involved and interested then at least there's a benefit to training and consensus building in discussing the code and the project in the review phase. The time and energy of developers who are qualified to review is quite possibly the bottleneck on development speed too so wasting review time will slow down development.
For AI generated code if previous PRs aren't loaded into context then there's no lasting benefit from the time taken to review and it's blank slate each time. I think ultimately it can be solved with workflow changes (i.e. AI written code should be attributed to the AI in VCS, the full trace and manual edits should be visible for review, all human input prompts to the AI should be browsable during review without having scroll 10k lines of AI reasoning.)
By nokcha 2026-03-1114:38 > LLM generated content often (perhaps by definition) seems acceptable to LLMs.
In my experience (albeit with non-coding questions), ChatGPT 5.2 is often quite eager to critique snippets of its own replies from previous conversations. And reasoning models can definitely find flaws in LLM-written code.
> I see reviewing and accepting a PR is a question of trust
I think that's backwards, at least as far as accepting a PR. Better that all code is reviewed as if it is probably a carefully thought out Trojan horse from a dedicated enemy until proven otherwise.
By bigfishrunning 2026-03-1021:37 I think this is actually a healthy stance. If you want to maintain patches against a project, just maintain a fork the project and if I want to pull in your changes I will. No direct submissions accepted is not the worst policy I think
By veunes 2026-03-1018:24 I think framing it as a trust question is exactly right
By jajuuka 2026-03-1016:40 That's the key part in all this. Reviewing PR needs to be a rock solid process that can catch errors. Human or AI generated.
Concerns about the wasting of maintainer’s time, onboarding, or copyright, are of great interest to me from a policy perspective. But I find some of the debate around the quality of AI contributions to be odd.
Quality should always be the responsibility of the person submitting changes. Whether a person used LLMs should not be a large concern if someone is acting in good-faith. If they submitted bad code, having used AI is not a valid excuse.
Policies restricting AI-use might hurt good contributors while bad contributors ignore the restrictions. That said, restrictions for non-quality reasons, like copyright concerns, might still make sense.
> If they submitted bad code...
The core issue is that it takes a large amount of effort to even assess this, because LLM generated code looks good superficially.
It is said that static FP languages make it hard to implement something if you don't really understand what you are implementing. Dynamically typed languages makes it easier to implement something when you don't fully understand what you are implementing.
LLMs takes this to another level when it enables one to implement something with zero understanding of what they are implementing.
The people likely to submit low-effort contributions are also the people most likely to ignore policies restricting AI usage.
The people following the policies are the most likely to use AI responsibly and not submit low-effort contributions.
I’m more interested in how we might allow people to build trust so that reviewers can positively spend time on their contributions, whilst avoiding wasting reviewers time on drive-by contributors. This seems like a hard problem.
I wonder if the right call wouldn't be impose a LOC limit on contributions (sensibly chosen for the combination of language/framework/toolset).
By sothatsit 2026-03-1017:51 I quite like this direction. Limit new contributors to small contributions, and then relax restrictions as more of their contributions are accepted.
By qsera 2026-03-117:01 I think The best place where AI can help in software development is helping with reviews, not doing development.
But AI marketing would not like to promote it, may because it is less dramatic and does not involve a paradigm shift or something...
By mort96 2026-03-1020:42 The people who write the most shitty AI code seem to be the proudest of their use of AI.
By alexey-pelykh 2026-03-1113:18 The distinction that matters is whether the contributor can defend their work in review, not what tool produced it.
I maintain a 300-commit fork built with heavy AI assistance. The AI writes a lot of the code. I review every line and can explain every choice. The test: can they respond to feedback, explain why they chose this approach over the simpler one, iterate on edge cases? That works regardless of how the code was produced.
Debian's problem isn't AI. It's distinguishing "used a tool well" from "dumped output." Code review already does this. Tighter process for new contributors (smaller patches, demonstrated understanding through review conversation) filters on engagement quality, not tool choice.
The real invariant is responsibility: if you submit a patch, you own it. You should understand it, be able to defend the design choices, and maintain it if needed
By serial_dev 2026-03-1019:30 Ownership and responsibility are useless when a YouTuber tells it to their million followers that GitHub contributions are valued by companies and this is how you can create a pull request with AI in three minutes, and you get hundred low value noise PRs opened by university students from the other side of the globe. It’s Hacktoberfest on steroids.
By tdeck 2026-03-116:33 "You committed it, you own it" can't even be enforced effectively at large companies, given employee turnover and changes in team priorities and recorgs. It's hard to see how this could be done effectively in open source projects. Once the code is in there, end users will rely on it. Other code will rely on it. If the original author goes radio silent it still can't be ripped out.
By pixl97 2026-03-1018:34 Great for large patches, great way to kill very small but important patches.
It should be the responsibility of the person submitting changes. The problem is AI apparently makes it easy for people to shirk that responsibility.
Trusted contributors using LLMs do not cause this problem though. It is the larger volume of low-effort contributions causing this problem, and those contributors are the most likely to ignore the policies.
Therefore, policies restricting AI-use on the basis of avoiding low-quality contributions are probably hurting more than they’re helping.
I'm not sure I agree. If you have a blanket "you must disclose how you use AI" policy it's socially very easy to say "can you disclose how you used AI", and then if they say Claude code wrote it, you can just ignore it, guilt-free.
Without that policy it feels rude to ask, and rude to ignore in case they didn't use AI.
By sothatsit 2026-03-1020:08 I’d argue this social angle is not very nuanced or effective. Not all people who used Claude Code will be submitting low-effort patches, and bad-faith actors will just lie about their AI-use.
For example, someone might have done a lot of investigation to find the root cause of an issue, followed by getting Claude Code to implement the fix, which they then tested. That has a good chance of being a good contribution.
I think tackling this from the trust side is likely to be a better solution. One approach would be to only allow new contributors to make small patches. Once those are accepted, then allow them to make larger contributions. That would help with the real problem, which is higher volumes of low-effort contributions overwhelming maintainers.
> people to shirk that responsibility.
Actually not shrink, but just transfer it to reviewers.
