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.
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.
> 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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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 :)
> 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.
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.
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.
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?
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.
>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
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.
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.
> 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?
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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
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.
If it works, it's not wrong.
Wasting any time or energy on determining whether or not the source is AI is stupid. If all the requirements are met, in terms of style guide, documentation, functionality, thorough testing and correctness, then it's good. Doesn't matter if AI wrote it, or if it's artisanal hand-crafted bytecode lovingly prepared by a native of Computronistan.
The trick is to define what works - set the bar high enough that you're driving away raw human contributors, annoying high value humans, or arbitrarily barring AI users out of dogma or politics or whatever. A hierarchy of maintainers, with people willing to volunteer to sift through submissions, each handing up a much reduced list to the next level, is probably where big projects will have to go.
At some point it won't matter; while it does, look for enthusiastic volunteers and make good, sensible, functional rules that get the best results.
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.
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).
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.)
> 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.
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
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.
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.
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
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.
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.
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.
I think the reality is going to be if you are just like "YOLO HERES THE CODE FIX" vs "Hey, I used AI, BUT I did everything I possibly could to validate the change" the latter is more acceptable.
My question on AI generated contributions and content in general: on a long enough timeline, with ever improving advancements in AI, how can people reliably tell the difference between human and AI generated efforts?
Sure now it is easy, but in 3-10 years AI will get significantly better. It is a lot like the audio quality of an MP3 recording. It is not perfect (lossless audio is better), but for the majority of users it is "good enough".
At a certain point AI generated content, PR's, etc will be good enough for humans to accept it as "human". What happens then, when even the best checks and balances are fooled?
> My question on AI generated contributions and content in general: on a long enough timeline, with ever improving advancements in AI, how can people reliably tell the difference between human and AI generated efforts?
Can you reliably tell that the contributor is truly the author of the patch and that they aren't working for a company that asserts copyright on that code? No, but it's probably still a good idea to have a policy that says "you can't do that", and you should be on the lookout for obvious violations.
It's the same story here. If you do nothing, you invite problems. If you do something, you won't stop every instance, but you're on stronger footing if it ever blows up.
Of course, the next question is whether AI-generated code that matches or surpasses human quality is even a problem. But right now, it's academic: most of the AI submissions received by open source projects are low quality. And if it improves, some projects might still have issues with it on legal (copyright) or ideological grounds, and that's their prerogative.
Precisely. “AI” contributions should be seen as an extension of the individual. If anything, they could ask that the account belong to a person and not be a second bot only account. Basically, a person’s own reputation should be on the line.
Reputation isn't very relevant here. Yes, for established well known FOSS developers, their reputation will tank if they put out sloppy PRs and people will just ignore them.
But the projects aren't drowning under PRs from reputable people. They're drowning in drive-by PRs from people with no reputation to speak of. Even if you outright ban their account, they'll just spin up a new one and try again.
Blocking AI submissions serves as a heuristic to reduce this flood of PRs, because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.
And AI cannot be the solution here, because open source projects have no funds. Asking maintainers to fork over $200/month for "AI code reviews" just kills the project.
> because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.
Hmmm, no? That's actually very common in open source. Maybe "banning" isn't the right word, but lots of projects don't accept random drive-by submissions and never have. Debian is a perfect example, you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer, or commit to the process of building trust to become a maintainer yourself.
I have seen high profile GitHub projects that summarily close PRs if you didn't raise the bug/feature as an issue or join their discord first.
Setting aside "make an issue first" because those too are flooded with LLMs.
> you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer
I did mean the "trivial" patches as well, as often it's a lot of these small little fixes to single issues that improve software quality overall.
But yes, it's true that it's not uncommon for projects to refuse outside PRs.
This already causes massive amounts of friction and contributes (heh) heavily to what makes Open Source such a pain in the ass to use.
Conversely, many popular "good" open source libraries rely extensively on this inflow of small contributions to become comprehensively good.
And so it's a tradeoff. Forcing all open source into refusing drive-by PRs will have costs. What makes sense for major security-sensitive projects with large resources doesn't make sense for others.
It's not that we won't have open source at all. It's that it'll just be worse and encourage further fragmentation. e.g. One doesn't build a good .ZIP library by carefully reading the specification, you get it by collecting a million little examples of weird zip files in the wild breaking your code.
Well, the problem you just outlined is a reputation (+ UI) problem: why are contributions from unknown contributors shown at the same level as PRs from known quality contributors, for example?
We need to rethink some UX design and processes here, not pretend low quality people are going to follow your "no low quality pls i'm serious >:(" rules. Rather, design the processes against low quality.
Also, we're in a new world where code-change PRs are trivial, and the hard part isn't writing code anymore but generating the spec. Maybe we don't even allow PRs anymore except for trusted contributors, everyone else can only create an issue and help refine a plan there which the code impl is derived?
You know, even before LLMs, it would have been pretty cool if we had a better process around deliberating and collaborating around a plan before the implementation step of any non-trivial code change. Changing code in a PR with no link to discussion around what the impl should actually look like always did feel like the cart before the horse.
In the long distant past of 4-5 years ago, it simply wasn't a problem. Few projects were overwhelmed with PRs to begin with.
And for the major projects where there was a flood of PRs, it was fairly easy to identify if someone knew what they were talking about by looking at their language; Correct use of jargon, especially domain-specific jargon.
The broader reason why "unknown contributor" PRs were held in high regard is that, outside of some specific incidents (thank you, DigitalOcean and your stupid tshirts), the odds were pretty good of a drive by PR coming from someone who identified a problem in your software by using it. Those are incredibly valuable PRs, especially as the work of diagnosing the problem generally also identifies the solution.
It's very hard to design a UX that impedes clueless fools spamming PRs but not the occasional random person finding sincere issues and having the time to identify (and fix them) but not permanent project contribution.
> and the hard part isn't writing code anymore but generating the spec
My POV: This is a bunch of crap and always has been.
Any sufficiently detailed specification is code. And the cost of writing such a specification is the cost of writing code. Every time "low code" has been tried, it doesn't work for this very reason.
e.g. The work of a ticket "Create a product category for 'Lime'" consists not of adding a database entry and typing in the word 'Lime', it consists of the human work of calling your client and asking whether it should go under Fruit or Cement.
Because until now, unknown contributors either submitted obvious junk which could be closed by even an unskilled moderator (I've done triage work for OS projects before) or they submitted something that was workable and a good start.
The latter is where you get all known contributors from! So if you close off unknown contributors the project will eventually stagnate and die.
I don't see why we can't have AI powered reviews as a verification of truth and trust score modifier. Let me explain.
1. You layout policy stating that all code, especially AI code has to be written to a high quality level and have been reviewed for issues prior to submission.
2. Given that even the fastest AI models do a great job of code reviews, you setup an agent using Codex-Spark or Sonnnet, etc to scan submissions for a few different dimensions (maintainability, security, etc).
3. If a submission comes through that fails review, that's a strong indication that the submitter hasn't put even the lowest effort into reviewing their own code. Especially since most AI models will flag similar issues. Knock their trust score down and supply feedback.
3a. If the submitter never acts on the feedback - close the submission and knock the trust score down even more.
3b. If the submitter acts on the feedback - boost trust score slightly. We now have a self-reinforcing loop that pushes thoughtful submitters to screen their own code. (Or ai models to iterate and improve their own code)
4. Submission passes and trust score of submitter meets some minimal threshold. Queued for human review pending prioritization.
I haven't put much thought into this but it seems like you could design a system such that "clout chasing" or "bot submissions" would be forced to either deliver something useful or give up _and_ lose enough trust score that you can safely shadowban them.
> Precisely. “AI” contributions should be seen as an extension of the individual.
That's an OK view to hold, but I'll point out two things. First, it's not how the tech is usually wielded to interact with open-source software. Second, your worldview is at odds with the owners of this technology: the main reason why so much money is being poured into AI coding is that it's seen by investors as a replacement for the individual.
The desire to anthropomorphize LLMs is super interesting. People naturally anthropomorphize technology (even printers: "why are you not working!?"). It's a natural and useful heuristic. However, I can easily see how chatGPT would want to intensify this tendency in order to sell the technology's "agency" and the promise that it can solve all your problems. However, since it's a heuristic, it papers over a lot of details that one would do well to understand.
(as an aside - this reminds me of the trend of Object Oriented Ontology that specifically /tried/ to imbue agency onto large-scale phenomena that were difficult to understand discretely. I remember "global warming" being one of those things - and I can see now how this philosophy would have done more to obscure the dominion of experts wrt that topic)
The point is thst this is a common pro-gun argument to deflect from the fact that making guns harder to own does in fact reduce gun violence. Which is how much of the rest of the world works.
But post Sandy Hook, it's clear which side prevailed in this argument.
Except it seems to be arguing in the exact opposite direction, and about the other side of the problem?
Those in favor of gun control aren't trying to lower human responsibility, they're trying to place stricter limits on the guns than the status quo. Those against gun control are trying to loosen limits on the guns.
Here this person is proposing making individual responsibility stricter compared than what it is today. And they're not arguing for loosening limits on the tech either.
Isn't that practically the opposite of your analogy?
An argument that I have some sympathy for, while still being moderately+ in favor of gun control (here in the USA where I'm a citizen).
It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains. (Reasonable people can disagree here!)
Whereas it seems to me that if we accept the proposition that the vast majority of code in the future is going to be written by AI (and I do), these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.
> these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.
It is the conservative position: it will be easier to walk back the policy and start accepting AI produced code some time down the road when its benefits are clearer than it will be to excise AI produced code from years prior if there's a technical or social reason to do that.
Even if the promise of AI is fulfilled and projects that don't use it are comparatively smaller, that doesn't mean there's no value in that, in the same way that people still make furniture in wood with traditional methods today even if a company can make the same widget cheaper in an almost fully automated way.
> It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains.
This is even true despite the fact that there are bad actors only a few minutes drive away in many cases (Chicago->Indiana border, for example).
I don't know, it's a pretty leap for me to consider AI being hard to distinguish from human contributions.
AI is predictive at a token level. I think the usefulness and power of this has been nothing short of astonishing; but this token prediction is fundamentally limiting. The difference between human _driven_ vs AI generated code is usually in design. Overly verbose and leaky abstractions, too many small abstractions that don't provide clear value, broad sweeping refactors when smaller more surgical changes would have met the immediate goals, etc. are the hallmarks of AI generated code in my experience. I don't think those will go away until there is another generational leap beyond just token prediction.
That said, I used human "driven" instead of human "written" somewhat intentionally. I think AI in even its current state will become a revolutionary productivity boosting developer aid (it already is to some degree). Not dissimilar to a other development tools like debuggers and linters, but with much broader usefulness and impact. If a human uses AI in creating a PR, is that something to worry about? If a contribution can pass review and related process checks; does it matter how much or how little AI was used in it's creation?
Personally, my answer is no. But there is a vast difference between a human using AI and an AI generated contribution being able to pass as human. I think there will be increasing degrees of the former, but the latter is improbable to impossible without another generational leap in AI research/technology (at least IMO).
---
As a side note, over usage of AI to generate code _is_ a problem I am currently wrangling with. Contributors who are over relying on vibecoding are creating material overhead in code review and maintenance in my current role. It's making maintenance, which was already a long tail cost generally, an acute pain.
Of course you can tell. If someone suddenly submits a mountainous pile of code out of nowhere that claims to fix every problem, you can make a reasonable estimate that the author used AI. It's then equally reasonable to suggest said author might not have taken the requisite time and detail to understand the scope of the problem.
This is the basis of the argument - it doesn't matter if you use AI or not, but it does matter if you know what you're doing or not.
Whether the quality of the code is the responsibility of the submitter or not is kind of irrelevant though, because the cost of verifying that quality still falls on the maintainer. If every submitter could be trusted to do their due diligence then this cost would be less, but unfortunately they can't; it's human nature to take every possible shortcut.
The same way niche/luxury product and services compare to fast/cheap ones: they are made with focus and intent that goes against the statistical average, which also normally would take more time and effort to make.
McDonalds cooks ~great~ (edit: fair enough, decent) burgers when measured objectively, but people still go to more niche burger restaurants because they want something different and made with more care.
That's not to say that an human can't use AI with intent, but then AI becomes another tool and not an autonomous code generating agent.
Probably more of the measure of the Deluxe burger, which if fresh doesn't seem to have any faults for a burger. Now the little McFrankinstines leave much to be desired.
Because it might require time consuming testing, iterations, documentation etc.
If everything the maintainer wants can (hypothetically) be one-shotted, then there is no need to accept PR's at all. Just allow forks in case of open source.
Obviously - it takes effort to hone the idea/spec, and it takes time to validate the result. Code being free doesn’t make a kernel patch free, though it would make it cheaper.
Crystal ball, maybe, but 3 years ago, the AI generated classes with empty methods containing "// implement logic here" and now, AI is generating whole stack applications that run from the first try.
Past performance does not guarantee future results, of course. But acting like AI is now magically going to stagnate is also a really bold bet.
> now, AI is generating whole stack applications that run from the first try
I sincerely doubt that, because it still can't even generate a few hundred line script that runs on the first try. I would know, I just tried yesterday. The first attempt was using hallucinated APIs and while I did get it to work eventually, I don't think it can one shot a complex application if it can't one shot a simple script.
IMO, AI has already stagnated and isn't significantly better than it was 3 years ago. I don't see how it's supposed to get better still when the improvement has already stopped.
I routinely generate applications for my personal use using OpenCode + Claude Sonnet/Opus.
Yesterday I generated an app for my son to learn multiplication tables using spaced repetition algorithm and score keeping. It took me like 5 minutes.
Of course if you use ChatGPT it will not work but there is no way Claude Code/Open Code with any modern model isn't able to generate a one hundred line script on the first try.
I was asking which tool, not which, not which model.
For the same model, you can just have it generate dad jokes or use it in a tool like OpenCode or Cursor or Zed or Cline or … and make it program complex things.
If I use Claude Sonnet on duck.ai I will have hard time generating something interesting. The same model in OpenCode does all my programming work.
>isn't significantly better than it was 3 years ago.
Eh?
Ever hear the saying the first 90% of a problem is 90% of the work, the last 10% of the program is also 90% of the work.
AI/LLMs have improved massively in that context. That's not even including the other model types such as visual/motion-visual/audio which are to the point that telling their output from reality is a chore.
And one shotting a simple script simply doesn't mean much without context. I have it dump relatively complex powershell scripts often enough and it's helped me a lot with being able to explain scripting actions to other humans where before I'd make assumptions about the other users knowledge where it was not warranted.
The biggest grift is invested tech Bro's trying to sell you on thr fact that Ai growth is linear or even exponential.
In reality it's Logarithmic. Maybe with the occasional jolt. You'd think with Moores "law" that we'd know better by now that explosive growth isn't forever. Or at least that we're bound to physics as a cap to hit.
> but if AI is just as good, doesn't that just mean more good PRs?
If you believe the outputs of LLMs are derivative products of the materials the LLMs were trained on (which is a position I lean towards myself, but I also understand the viewpoint of those who disagree), then no, that's not a good thing, because it would be a license violation to accept those derived products without following the original material's license terms, such as attribution and copyleft terms. You are now party to violating the original materials' copyright by accepting AI generated code. That's ethically dubious, even if those original authors may have a hard time bringing a court case against you.
> In that case a lot of proprietary software is in breach of copyleft licences. Its probably by far the commonest breach.
Sure, but this doesn't really seem relevant to the conversation. Someone else violating software license terms doesn't justify me (or Debian, in the case of TFA) doing so.
> Is it always ethically dubious to breach a law?
I'm not really concerned with the law, here. I think it is ethically dubious to use someone else's work without compensating them in the manner they declared. Copyright law happens to be the method we've used for a couple hundred years to standardize the discussion about that compensation, and sometimes enforce it. Breaching the law doesn't really enter into the conversation, except as a way our society agrees to hold everyone to a minimum ethical standard.
> I'm not really concerned with the law, here. I think it is ethically dubious to use someone else's work without compensating them in the manner they declared.
OK, that is reasonable. I do not think copyright is a good mechanism though, and I think the need to compensate depends on multiple factors depending on what you use a work for and under what circumstances.
Let's burn that bridge when we get to it. I'm not even sure what 2027 will look like at this rate. There's no point concerning about 2035 when things are so tumultuous today.
You say "on a long enough timeline", but you already can't tell today in the hands of someone who knows what they're doing.
I think a lot of anti-LLM opinions just come from interacting with the lowest effort LLM slop and someone not realizing that it's really a problem with a low value person behind it.
It's why "no AI allowed" is pointless; high value contributors won't follow it because they know how to use it productively and they know there's no way for you to tell, and low value people never cared about wasting your time with low effort output, so the rule is performative.
e.g. If you tell me AI isn't allowed because it writes bad code, then you're clearly not talking to someone who uses AI to plan, specify, and implement high quality code.
> It's why "no AI allowed" is pointless … If you tell me AI isn't allowed because it writes bad code
I disagree that the rule is pointless, and your last point is a strawman. AI is disallowed because it’s the manner in which the would-be contributors are attempting to contribute to these projects. It’s a proxy rule.
Unfortunately for AI maximalists, code is more than just letters on the screen. There needs to be human understanding, and if you’re not a core contributor who’s proven you’re willing to stick around when shit hits the fan, a +3000 PR is a liability, not an asset.
Maybe there needs to be something like the MMORPG concept of “Dragon Kill Points (DKP)”, where you’re not entitled to loot (contribution) until you’ve proven that you give a shit.
> Unfortunately for AI maximalists, code is more than just letters on the screen. There needs to be human understanding, and if you’re not a core contributor who’s proven you’re willing to stick around when shit hits the fan, a +3000 PR is a liability, not an asset.
This isn't necessarily true; I've seen some projects absorb a PR of roughly that size, and after the smoke tests and other standard development stuff, the original PR author basically disappeared.
It added a feature he wanted, he tested and coded it, and got it in.
>So because some projects can absorb some PRs of a certain size, all projects of should be able to absorb PRs of that same size?
Your argument has nothing to do with AI and more to do with PR size and 'fire and forget' feature merges. That's what the commenter your responding to is pointing out.
And my entire point is that LLM-generated feature requests are strongly correlated with high risk merge requests / pull requests, to which the commenter made no meaningful argument against. Instead the commenter chose to focus on the size of the PR and say “well I’ve seen it in the wild”.
The way to get around this without getting all the LLM influencer bros in an uproar is to come up with a system that allows open source libraries to evaluate the risk of a PR (including the author’s ability to explain wtf the code does) without referencing AI because apparently it’s an easily-triggered community.
> and if you’re not a core contributor who’s proven you’re willing to stick around when shit hits the fan, a +3000 PR is a liability, not an asset.
And in the context of high-value contributors that GP was mentioning, they are never going to land a +3000 PR because they know there is going to be a human reviewer on the other side.
I don't see an issue here. You keep using AI to create high value contributions in the projects that accept it, I will keep not using it in mine, and we can see who wins out in 10 years.
High-value contributors follow the rules and social mores of the community they are contributing to. If they intentionally deceive others, they are not high-value.
Arguing that "doesn't secretly, sneakily break project rules" is an essential component of a quality contributor isn't a "no true scotsman" argument, it's a statement about qualifications
Like its been years and years now, if all this is true, you'd think there would be more of a paradigm shift? I'm happy I guess waiting for Godot like everyone else, but the shadows are getting a little long now, people are starting to just repeat the same things over and over.
Like, I am so tired now, it's causing such messes everywhere. Can all the best things about AI be manifest soon? Is there a timeline?
Like what can I take so that I can see the brave new world just out of reach? Where can I go? If I could just even taste the mindset of the true believer for a moment, I feel like it would be a reprieve.
Off the internet. Maybe it's just time we all face the public internet is dead.
Maybe a trusted private internet, though that comes with it's own risks and tradeoffs.
Maybe we start doing PRs over mailed USB keys. Anyone with enough interest will do it, but it will cut out the bots. We're back to a 90's sneakernet. Any internet presence may become a read only site telling others how to reach you offline.
The information superhighway died a long time ago. 4chan enlightened me on the power of intelligent stupidity. The machinations of a few smart people could embolden countless stupid people to cause nearly unlimited damage. Social media gathering up the smart and dumb alike allowed bullshit asymmetry to explode onto the scene and burned out anyone with a modicum of intelligence.
All LLM-output is slop. There's no good LLM output. It's stolen code, stolen literature, stolen media condensed into the greatest heist of the 21. century. Perfect capitalism - big LLM companies don't need to pay royalties to humans, while selling access to a service which generates monthly revenue.
Whether it trained on real world "stolen" code is an implementation detail. A controversial one, but it isn't a supporting argument for whether it can write high quality, functional code or not.
I'm fine with calling all LLM outputs slop, but I'll draw the line at asserting there's no good LLM output. LLM output is good when it works, and we can easily verify that a lot of code from LLMs does work. That the code LLMs output is derive of copyrighted works is neither here nor there. First of all, ALL creative work is derivative. Secondly IP is absurd horse shit and we never should have humored the premise of it being treated like real property.
I came from a poor background and stole pretty much all the textbooks I used to learn programming as a kid. I also stole all the music I listened to while studying them. Is everything I write slop for the same reason?
No. You're a human, who went through real life experiences. You learned, developed as a human being. You made mistakes and grew from them. You did what you have to do to advance. What you output has intrinsic value because of all this. I argue that even when you roll your face on your keyboard, the output is more valuable than ten pages of slop output from an LLM, since it's human, with all the history, experience, emotions and character which came before it.
I don't know why this got downvoted. I've already been so frustrated by HN LIDAR mindsets but holy shit.
Human society exists because we value humans, full stop. The easiest way to "solve" all of humanity's problems is to simply say that humans aren't valuable. Sometimes it feels like we're conceding a ridiculous amount of ground on that basic principle every year - one more human value gone because it "doesn't matter", so hey, we've obviously made progress!
Agreed. I think that sometimes people on HN lose sight of what is actually important, which is human flourishing. The other day there was someone arguing that the best thing to do to fix loneliness problems in society is to remove the human need for socializing. Which... is certainly one way to fix the problem, I guess, but completely missed the point. The point is not to fix a mismatch between essential human desires and what we can attain, the point is to work on fulfilling those desires! Just something goes with nerd autism, I guess.
> I don't know why this got downvoted. I've already been so frustrated by HN LIDAR mindsets but holy shit
The extreme sides (proponents, opponents) are clear, opposites, and fight each other. More nuanced takes get buried as droplets in a bucket. Likely a goal.
> Human society exists because we value humans, full stop.
Call me cynic, but I do not believe every human being agrees with this sentiment. From HR acting as if humans are resources, to human beings being dehumanized as workers, civilians, cannon fodder, and... well, the product. Every time human rights are violated, and we do not stand up to it, we lose.
I have a very simple question as human right: the right for a human being to know the other side is a human being yes or no, and if not: to speak gratis (no additional fee allowed) to a human being instead. Futhermore, ML must always cite the used sources, and ML programmer is responsible for mistake. This would increase insurance costs so much, that LLM's in public would die, but SLM's could thrive.
>Human society exists because we value humans, full stop.
Eh, human society exists because it is an emergent behavior of the evolutionary advantage afforded at the time of adoption by the human species. There is on iron rule stating that it must continue into the future, or even that it can exist into the future.
More so, the value of a human has wildly fluctuated over history and culture. The village chief, nobles, the king were all high value humans. The villagers would be middle to low value, and others may be considered no value.
The industrial age began to change this some as value started to move from the merchant class to the villager class as many high production jobs needed less and less training to complete. With industrialization businesses running machines and production lines needed as many people as they could get. Still human rights were hard fought in places like America where labor wars broke out.
In the modern US we've setup a dangerous set of idealism that will most likely end in disaster because they are in conflict with general human values. That is the "pull yourself up by your bootstraps", "Any collective action is communism and communism will turn you into a pillar of salt if you dare look at it", and "greed is good". Couple that with TV media and social media owned by rich billionaires you're not going to see much serious opposition to these ideals.
But if/as labor loses it's values, so will the humans that performed that labor. After decades of optimizing human society for maximal capital extraction, values are dead, and the ever present thought police owned by the rich will make sure you don't cause too much trouble by resurrecting them.
Intent matters. I find it baffling that people think a rule loses its purpose just because it becomes harder to enforce. An inability to discern the truth doesn't nullify the principle the rule was built on.
Does Debian have a rule that forbids (or a taboo that proscribes) contributors passing off other people’s work as their own? I could believe that such a rule is implied rather than written down. The GR could be about writing it down, and it would surely cover the case of code that came directly from a model. Even if we don’t consider a
model to be another person it is certainly not the contributor’s own work.
(If anything, the copyright to model-generated code cannot possibly be said to belong to the human contributor. They… didn’t write it! I’m glad to see that aspect was discussed though I’m surprised it wasn’t the main thrust.)
> Does Debian have a rule that forbids (or a taboo that proscribes) contributors passing off other people’s work as their own? I could believe that such a rule is implied rather than written down.
It’s implied because it’s illegal (infringes on the original author’s rights). Of course, LLMs aren’t people.
I think all machine generated content should be labeled as such. And if a maintainer or a consumer or whoever doesn't want to accept it, so be it. But people should at least have the choice.
Fork it to Slobian and let the clankers go to town creating, approving and merging pull requests by themselves. Look at the install base to see what people prefer.
The quality argument against LLM-generated code has always seemed weak to me. Maintainers already review patches because humans routinely submit bad code. The review process is the filter.
Bad human code is usually fairly obvious, bad LLM code often less so, because it’s trained to produce superficially sensible-looking code. Hence reviewing it requires higher alertness and is more work. The other problem is that LLMs allow a human to submit much larger amounts of code to be reviewed than if they had to write the code themselves.
This reminds me of the Hacktoberfest situation where maintainers were getting flooded with low-quality PRs. This could be that, but on steroids and constantly, not just one month.
Did anyone say it is a risk? What if courts eventually decide that users of products of closed models have to pay some reasonable fee to the owners of the training data?
In some sense, I think the promise of free software is more real today than before because everyone else's software is replicable for relatively cheap. That's probably a much stronger situation for individual freedom to replicate and run code than in the era of us relying on copyright.
This freedom depends on the hardware and pricing of megacorps that are currently busy in applying their knowledge to do surveillance and killing. I doubt we can rely on them to help with our freedom.
Treat this as person's own contribution. If the quality is bad, means the person has allowed it, or the person's quality of work is bad, and it doesn't matter whether they produced it or AI did. So in both cases they'd deserve a rejection of their PR. The only downside is that it takes away precious reviewer energy and time.
In my opinion- we need to successfully integrate generative AI into our workflows, but we need to do it appropriately and exercise caution. Ex. If you are a senior developer utilizing AI as a tool then I see using Generative AI as a competitive advantage. If you are a junior developer claiming to be a senior developer that is not okay.
All in All, just be honest with yourself, and be honest to others on where your skills lie. AI can be a great tool, but it should not replace you.
I'd love to see the policy on review tools to start with, I know even people who are skeptical of getting "AI Slop" thrown at them by agents at a high rate, getting code reviews from some of the SOTA models definitely can be helpful.
Google found that with Jules years ago at this point, same for other automated tools.
When I first saw the headline though, it sounded like someone was listening to one of my favorite Rush songs.
Good decision. The two extremes of this decision are both bad. On one hand the status quo of a lot of slop demanding attention from busy people is just not sustainable and something has to change. But throwing out the baby with the bath water by just blanket banning all forms of AI contributions is not a long term sustainable solution. It's a stop gap solution at best. And one that would be challenged more and more as inevitably tools keep on getting better and more widely used. It's not going to take years even. Deciding to not decide right now gives people some time to think and reflect.
The right way might be to fight AI slop with AI enforced guard rails. It's not actually that hard to implement technically. You can literally just put some markdown skills in your repository and periodically have an AI bot apply the review PR skill to incoming PRs to pre-screen them and automatically close PRs that obviously fall short of well documented criteria, and label & prioritize remaining ones.
Open claw might be a bridge too far for some at this point but it's maybe a glimpse of a future where we have AI bots filtering, screening and funneling inbound information. If you are a bit handy, you can just unleash codex or code claude on your issue tracker and pull requests right now. Worth experimenting with at a small scale.
Criteria could include doing a quick code review. Is the code appropriate and minimal? Does it meet all the documented criteria? Does it fix something that is worth fixing? Does it need further review? AIs can do all sorts of things with PRs ranging from commenting to closing the PR, prioritizing it, commenting on them, or flagging it for escalation to the right person in the team. By the time a real person chooses to spend time on a PR it should have already passed a lot of quality gates and be in a decent enough shape.
A second innovation here could be doing more with reputation. Github users build up reputation by virtue of all the contributions they make over time to all sorts of projects. Also, git allows people to sign their commits. That allows AI gate keepers to sort incoming contributions by reputation. Maybe be lenient towards known repeat contributors. Give the benefit of the doubt to new contributors but scrutinize them more and be very strict on everybody else by default. In a meritocracy, you build reputation by consistently doing good work. Dumping a lot of AI slop on somebody's desk would be the opposite.
Just some thoughts. I have a few smaller github projects but I'm so far not burdened by a lot of low quality PRs.
> The right way might be to fight AI slop with AI enforced guard rails.
Whenever I you tried to develop using guardrails with LLMs, I found out that they are much better at ,,cheating'' than a human: getting around the guardrails by creating the ugliest hacks around them.
Given the 10x+ productivity rate, it would be reasonable to establish a higher quality acceptance bar for AI submissions. 50-100% more performance, correctness, usability testing , and one round of human review.
If a change used to take a day or two, and now requires a few minutes, then it's fair to ask for a couple hours more prompting to add the additional tangible tests to compensate for any risks of hallucinations or low quality code sneaking in
> 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]'.
Quixotic, unworkable, pointless. It’s fundamentally impossible (at least without a level of surveillance that would obviously be unavceptable) to prove the “artisanal hand-crafted human code” label.
> 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".
This is in the right direction.
I think the missing link is around formalizing the reputation system; this exists for senior contributors but the on-ramp for new contributors is currently not working.
Perhaps bots should ruthlessly triage in-vouched submissions until the actor has proven a good-faith ability to deliver meaningful results. (Or the principal has staked / donated real money to the foundation to prove they are serious.)
I think the real problem here is the flood of low-effort slop, not AI tooling itself. In the hands of a responsible contributor LLMs are already providing big wins to many. (See antirez’s posts for example, if you are skeptical.)
> Quixotic, unworkable, pointless. It’s fundamentally impossible (at least without a level of surveillance that would obviously be unavceptable) to prove the “artisanal hand-crafted human code” label.
Difficulty of enforcing is a detail. Since the rule exists, it can be used when detection is done. And importantly it means that ignoring the rule means you’re intentionally defrauding the project.
Debian has always been Debian and thus there are these purist opinions, but perhaps my take too would be something along the "one-strike-and-you-are-out" kind of a policy (i.e., you submit slop without being able to explain your submission in any way) already followed in some projects:
Yeah this is what I was getting at with “reputation” - I think the world where anyone can submit a patch and get human eyes on it is a thing of the past.
IIRC Mitchell Hashimoto recently proposed some system of attestations for OSS contributors. It’s non-obvious how you’d scale this.
I agree. If the real concern is the flood of low-effort slop, unmaintainable patches, accidental code reuse, or licensing violations, then the process should target those directly. The useful work is improving review and triage so those problems get filtered out early. The genie is already out of the bottle with AI tooling, so broad “no AI” rules feel like a reaction to the tool and do not seem especially useful or enforceable.
LLM-generated code is incompatible with libre software. It's extremely frustrating to see such a lack of conviction to argue this point forcefully and repeatedly. It's certainly bad enough to see such a widespread embrace of this dangerous and anti-libre technology within proprietary software teams, but when it comes to FLOSS, it should be a no-brainer to formalize an emphatic anti-slop contributor policy.
> It's extremely frustrating to see such a lack of conviction to argue this point forcefully and repeatedly.
It is. You haven't argued it at all, right here. You just asserted it as if it were self-evident, talked about your feelings, then demanded policy.
Your only job here was to convince people to align with you, and you didn't bother. It makes me suspect that you haven't really solidified the argument in your own mind.
I don't understand a lot of the anti-LLM venom within this specific context. Debian doesn't have to worry about stealing GPL code, so the copyright argument is nearly nil. There's still the matter of attribution-ware, but Debian includes tons of attribution and I'm sure would happily include anyone who thinks their OSS might have been trained on.
So leaving that aside, it just seems to be the revulsion that programmers feel towards a lot of LLM slop and the aggravation of getting a lot of slop submissions? Something that seems to be universal in the FOSS social environment, but also seems to be indicative of a boundary issue for me:
The fact that machines have started to write reasonable code doesn't mean that you don't have any responsibility to read or review it before you hand it to someone. You could always write shit code and submit it without debugging it or refactoring it sanely, etc. Projects have always had to deal with this, and I suspect they've dealt with this through limiting the people they talk to to their friends, putting arbitrary barriers in front of people who want to contribute, and just being bitchy. While they were doing this, non-corporate FOSS was stagnating and dying because 1) no one would put up with that without being paid, and/or 2) money could buy your way past barriers and bitchiness.
Projects need to groom contributors, not simply pre-filter contributions by identity in order to cut down on their workload. There has to be an onboarding process, and that onboarding process has to include banning and condemning people that give you unreviewed slop, and spreading their names and accounts to other projects that could be targeted. Zero tolerance for people who send you something to read that they didn't bother to read. If somebody is getting AI to work for them, then trust grows in that person, and their contributions should be valued.
I think the AI part is a distraction. AI is better for Debian that almost anyone else, because Debian is copyleft and avoids the problems that copyleft poses for other software. The problem is that people working within Free Software need some sort of structured social/code interaction where there are reputations to be gained and lost that aren't isolated to single interactions over pull requests, or trying to figure out how and where to submit patches. Where all of the information is in one place about how to contribute, and also about who is contributing.
Priority needs to be placed on making all of this stuff clear. Debian is a massive enough project, basically all-encompassing, where it could actually set up something like this for itself and the rest of FOSS could attach itself later. Why doesn't Debian have a "github" that mirrors all of the software it distributes? Aren't they the perfect place? One of the only good, functional examples of online government?
edit: There's no reason that Debian shouldn't be giving attribution to every online FOSS project that could possibly be run on Linux (it will be run on Debian, and hopefully distributed through apt-get.) Maybe a Debian contributor slash FOSS-in-general social network is the way to do that? Isn't debian.org almost that already?
Before LLM did code, you could at least have assumed that the submitter had written it (at worst, copy-pasted large parts of it), even if they had not read or reviewed it. Furthermore, writing (even copy pasting) is quite labour intensive, so there was that hurdle too.
The website is absolutely atrocious, dark mode has pitch-black background with bold 100% white glowing text in foreground, shitty font, way to wide text.
Seriously how is lwn.net even still so popular with such an atrocious unreadable ugly website. Well yes I get the irony of asking that on HN (I use an extension to make it better).
An interesting concept that stood out to me. Committing the prompts instead of the resulting code only.
It it really true the LLM's are non-deterministic? I thought if you used the exact input and seed with the temperature set to 0 you would get the same output. It would actually be interesting to probe the commit prompts to see how slight variants preformed.
> I thought if you used the exact input and seed with the temperature set to 0 you would get the same output.
I think they can also be differences on different hardware, and also usually temperature is set higher than zero because it produces more "useful/interesting" outputs
A lot of low quality AI contributions arrive using free tiers of these AI models, the output of which is pretty crap. On the other hand, if you max out the model configs, i.e. get "the best money can buy", then those models are actually quite useful and powerful.
OSS should not miss out on the power LLMs can unleash. Talking about the maxed out versions of the newest models only, i.e. stuff like Claude 4.5+ and Gemini 3, so developments of the last 5 months.
But at the same time, maintainers should not have to review code written by a low quality model (and the high quality models, for now, are all closed, although I heard good things about Minmax 2.5 but I haven't tried it).
Given how hard it is to tell which model made a specific output, without doing an actual review, I think it would make most sense to have a rule restricting AI access to trusted contributors only, i.e. maintainers as a start, and maybe some trusted group of contributors where you know that they use the expensive but useful models, and not the cheap but crap models.
It's the difference between raw LLM output vs LLM output that was tweaked, reviewed and validated by a competent developer.
Both can look like the same exact type of AI-generated code. But one is a broken useless piece of shit and the other actually does what it claims to do.
The problem is just how hard it is to differentiate the two at a glance.
> It's the difference between raw LLM output vs LLM output that was tweaked, reviewed and validated by a competent developer.
This is one of those areas where you might have been right.. 4-6 months ago. But if you're paying attention, the floor has moved up substantially.
For the work I do, last year the models would occasionally produce code with bugs, linter errors, etc, now the frontier models produce mostly flawless code that I don't need to review. I'll still write tests, or prompt test scenarios for it but most of the testing is functional.
If the exponential curve continues I think everyone needs to prepare for a step function change. Debian may even cease to be relevant because AI will write something better in a couple of hours.
This very much depends on the domain you work in. Small projects in well tread domains are incredible for AI. SaaS projects can essentially be one-shot. But large projects, projects with specific standards or idioms, projects with particular versions of languages, performance concerns, hardware concerns, all things the Debian project has to deal with, aren't 'solved' in the same way.
The tacit understanding of all these is that the valued contributors can us AI as long as they can "defend the code" if you will, because AI used lightly and in that way would be indistinguishable from knuthkode.
The problem is having an unwritten rule is sometimes worse than a written one, even if it "works".
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.
> AI here is the final nail in the coffin
so far*
> 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.
> 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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
Accessibility is an angle that rarely comes up in these debates and it's a strong one
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.
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.
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.
> 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...
> 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.
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.
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.
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?
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!
>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
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.
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.
Yeah, if RSI is an issue why would you want to be forced to type more?
> 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?
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.
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.
> 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.
Yes, I literally quoted it.
> 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?
> 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.
[1] https://en.wikipedia.org/wiki/Microtargeting
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.
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.
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.
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.
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 "
https://www.youtube.com/watch?v=T4Upf_B9RLQ
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.
I think generating slop and having others review it is bad even if you are disabled. I say this as a disabled person myself.
If it works, it's not wrong. Wasting any time or energy on determining whether or not the source is AI is stupid. If all the requirements are met, in terms of style guide, documentation, functionality, thorough testing and correctness, then it's good. Doesn't matter if AI wrote it, or if it's artisanal hand-crafted bytecode lovingly prepared by a native of Computronistan.
The trick is to define what works - set the bar high enough that you're driving away raw human contributors, annoying high value humans, or arbitrarily barring AI users out of dogma or politics or whatever. A hierarchy of maintainers, with people willing to volunteer to sift through submissions, each handing up a much reduced list to the next level, is probably where big projects will have to go.
At some point it won't matter; while it does, look for enthusiastic volunteers and make good, sensible, functional rules that get the best results.
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.
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).
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.)
> 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.
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
I think framing it as a trust question is exactly right
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).
I quite like this direction. Limit new contributors to small contributions, and then relax restrictions as more of their contributions are accepted.
The people who write the most shitty AI code seem to be the proudest of their use of AI.
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
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.
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.
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.
That's what "shirk" means. It wasn't a typo.
I think the reality is going to be if you are just like "YOLO HERES THE CODE FIX" vs "Hey, I used AI, BUT I did everything I possibly could to validate the change" the latter is more acceptable.
My question on AI generated contributions and content in general: on a long enough timeline, with ever improving advancements in AI, how can people reliably tell the difference between human and AI generated efforts?
Sure now it is easy, but in 3-10 years AI will get significantly better. It is a lot like the audio quality of an MP3 recording. It is not perfect (lossless audio is better), but for the majority of users it is "good enough".
At a certain point AI generated content, PR's, etc will be good enough for humans to accept it as "human". What happens then, when even the best checks and balances are fooled?
> My question on AI generated contributions and content in general: on a long enough timeline, with ever improving advancements in AI, how can people reliably tell the difference between human and AI generated efforts?
Can you reliably tell that the contributor is truly the author of the patch and that they aren't working for a company that asserts copyright on that code? No, but it's probably still a good idea to have a policy that says "you can't do that", and you should be on the lookout for obvious violations.
It's the same story here. If you do nothing, you invite problems. If you do something, you won't stop every instance, but you're on stronger footing if it ever blows up.
Of course, the next question is whether AI-generated code that matches or surpasses human quality is even a problem. But right now, it's academic: most of the AI submissions received by open source projects are low quality. And if it improves, some projects might still have issues with it on legal (copyright) or ideological grounds, and that's their prerogative.
Precisely. “AI” contributions should be seen as an extension of the individual. If anything, they could ask that the account belong to a person and not be a second bot only account. Basically, a person’s own reputation should be on the line.
Reputation isn't very relevant here. Yes, for established well known FOSS developers, their reputation will tank if they put out sloppy PRs and people will just ignore them.
But the projects aren't drowning under PRs from reputable people. They're drowning in drive-by PRs from people with no reputation to speak of. Even if you outright ban their account, they'll just spin up a new one and try again.
Blocking AI submissions serves as a heuristic to reduce this flood of PRs, because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.
And AI cannot be the solution here, because open source projects have no funds. Asking maintainers to fork over $200/month for "AI code reviews" just kills the project.
> because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.
Hmmm, no? That's actually very common in open source. Maybe "banning" isn't the right word, but lots of projects don't accept random drive-by submissions and never have. Debian is a perfect example, you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer, or commit to the process of building trust to become a maintainer yourself.
I have seen high profile GitHub projects that summarily close PRs if you didn't raise the bug/feature as an issue or join their discord first.
Setting aside "make an issue first" because those too are flooded with LLMs.
> you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer
I did mean the "trivial" patches as well, as often it's a lot of these small little fixes to single issues that improve software quality overall.
But yes, it's true that it's not uncommon for projects to refuse outside PRs.
This already causes massive amounts of friction and contributes (heh) heavily to what makes Open Source such a pain in the ass to use.
Conversely, many popular "good" open source libraries rely extensively on this inflow of small contributions to become comprehensively good.
And so it's a tradeoff. Forcing all open source into refusing drive-by PRs will have costs. What makes sense for major security-sensitive projects with large resources doesn't make sense for others.
It's not that we won't have open source at all. It's that it'll just be worse and encourage further fragmentation. e.g. One doesn't build a good .ZIP library by carefully reading the specification, you get it by collecting a million little examples of weird zip files in the wild breaking your code.
You can literally just attach a patch to a bugreport on debian…
Well, the problem you just outlined is a reputation (+ UI) problem: why are contributions from unknown contributors shown at the same level as PRs from known quality contributors, for example?
We need to rethink some UX design and processes here, not pretend low quality people are going to follow your "no low quality pls i'm serious >:(" rules. Rather, design the processes against low quality.
Also, we're in a new world where code-change PRs are trivial, and the hard part isn't writing code anymore but generating the spec. Maybe we don't even allow PRs anymore except for trusted contributors, everyone else can only create an issue and help refine a plan there which the code impl is derived?
You know, even before LLMs, it would have been pretty cool if we had a better process around deliberating and collaborating around a plan before the implementation step of any non-trivial code change. Changing code in a PR with no link to discussion around what the impl should actually look like always did feel like the cart before the horse.
In the long distant past of 4-5 years ago, it simply wasn't a problem. Few projects were overwhelmed with PRs to begin with.
And for the major projects where there was a flood of PRs, it was fairly easy to identify if someone knew what they were talking about by looking at their language; Correct use of jargon, especially domain-specific jargon.
The broader reason why "unknown contributor" PRs were held in high regard is that, outside of some specific incidents (thank you, DigitalOcean and your stupid tshirts), the odds were pretty good of a drive by PR coming from someone who identified a problem in your software by using it. Those are incredibly valuable PRs, especially as the work of diagnosing the problem generally also identifies the solution.
It's very hard to design a UX that impedes clueless fools spamming PRs but not the occasional random person finding sincere issues and having the time to identify (and fix them) but not permanent project contribution.
> and the hard part isn't writing code anymore but generating the spec
My POV: This is a bunch of crap and always has been.
Any sufficiently detailed specification is code. And the cost of writing such a specification is the cost of writing code. Every time "low code" has been tried, it doesn't work for this very reason.
e.g. The work of a ticket "Create a product category for 'Lime'" consists not of adding a database entry and typing in the word 'Lime', it consists of the human work of calling your client and asking whether it should go under Fruit or Cement.
Because until now, unknown contributors either submitted obvious junk which could be closed by even an unskilled moderator (I've done triage work for OS projects before) or they submitted something that was workable and a good start.
The latter is where you get all known contributors from! So if you close off unknown contributors the project will eventually stagnate and die.
I don't see why we can't have AI powered reviews as a verification of truth and trust score modifier. Let me explain.
1. You layout policy stating that all code, especially AI code has to be written to a high quality level and have been reviewed for issues prior to submission.
2. Given that even the fastest AI models do a great job of code reviews, you setup an agent using Codex-Spark or Sonnnet, etc to scan submissions for a few different dimensions (maintainability, security, etc).
3. If a submission comes through that fails review, that's a strong indication that the submitter hasn't put even the lowest effort into reviewing their own code. Especially since most AI models will flag similar issues. Knock their trust score down and supply feedback.
3a. If the submitter never acts on the feedback - close the submission and knock the trust score down even more.
3b. If the submitter acts on the feedback - boost trust score slightly. We now have a self-reinforcing loop that pushes thoughtful submitters to screen their own code. (Or ai models to iterate and improve their own code)
4. Submission passes and trust score of submitter meets some minimal threshold. Queued for human review pending prioritization.
I haven't put much thought into this but it seems like you could design a system such that "clout chasing" or "bot submissions" would be forced to either deliver something useful or give up _and_ lose enough trust score that you can safely shadowban them.
The immediate problem is just cost. Open Source has no money, so any fancy AI solution is off the table immediately.
In terms of your plan though, you're just building a generative adversarial network here. Automated review is relatively easy to "attack".
Yet human contributors don't put up with having to game an arbitrary score system. StackOverflow imploded in no small part because of it.
> Precisely. “AI” contributions should be seen as an extension of the individual.
That's an OK view to hold, but I'll point out two things. First, it's not how the tech is usually wielded to interact with open-source software. Second, your worldview is at odds with the owners of this technology: the main reason why so much money is being poured into AI coding is that it's seen by investors as a replacement for the individual.
Interesting argument for AI ethics in general. It takes the form of "guns don't kill people - people kill people".
Unfortunately ChatGPT turned “text continuation” into “separate entity you can talk to”
The desire to anthropomorphize LLMs is super interesting. People naturally anthropomorphize technology (even printers: "why are you not working!?"). It's a natural and useful heuristic. However, I can easily see how chatGPT would want to intensify this tendency in order to sell the technology's "agency" and the promise that it can solve all your problems. However, since it's a heuristic, it papers over a lot of details that one would do well to understand.
(as an aside - this reminds me of the trend of Object Oriented Ontology that specifically /tried/ to imbue agency onto large-scale phenomena that were difficult to understand discretely. I remember "global warming" being one of those things - and I can see now how this philosophy would have done more to obscure the dominion of experts wrt that topic)
I don't think any side on the issue of gun ownership has ever claimed that statement is false, so I'm not sure what your point is.
The point is thst this is a common pro-gun argument to deflect from the fact that making guns harder to own does in fact reduce gun violence. Which is how much of the rest of the world works.
But post Sandy Hook, it's clear which side prevailed in this argument.
Except it seems to be arguing in the exact opposite direction, and about the other side of the problem?
Those in favor of gun control aren't trying to lower human responsibility, they're trying to place stricter limits on the guns than the status quo. Those against gun control are trying to loosen limits on the guns.
Here this person is proposing making individual responsibility stricter compared than what it is today. And they're not arguing for loosening limits on the tech either.
Isn't that practically the opposite of your analogy?
An argument that I have some sympathy for, while still being moderately+ in favor of gun control (here in the USA where I'm a citizen).
It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains. (Reasonable people can disagree here!)
Whereas it seems to me that if we accept the proposition that the vast majority of code in the future is going to be written by AI (and I do), these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.
> these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.
It is the conservative position: it will be easier to walk back the policy and start accepting AI produced code some time down the road when its benefits are clearer than it will be to excise AI produced code from years prior if there's a technical or social reason to do that.
Even if the promise of AI is fulfilled and projects that don't use it are comparatively smaller, that doesn't mean there's no value in that, in the same way that people still make furniture in wood with traditional methods today even if a company can make the same widget cheaper in an almost fully automated way.
> It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains.
This is even true despite the fact that there are bad actors only a few minutes drive away in many cases (Chicago->Indiana border, for example).
I don't know, it's a pretty leap for me to consider AI being hard to distinguish from human contributions.
AI is predictive at a token level. I think the usefulness and power of this has been nothing short of astonishing; but this token prediction is fundamentally limiting. The difference between human _driven_ vs AI generated code is usually in design. Overly verbose and leaky abstractions, too many small abstractions that don't provide clear value, broad sweeping refactors when smaller more surgical changes would have met the immediate goals, etc. are the hallmarks of AI generated code in my experience. I don't think those will go away until there is another generational leap beyond just token prediction.
That said, I used human "driven" instead of human "written" somewhat intentionally. I think AI in even its current state will become a revolutionary productivity boosting developer aid (it already is to some degree). Not dissimilar to a other development tools like debuggers and linters, but with much broader usefulness and impact. If a human uses AI in creating a PR, is that something to worry about? If a contribution can pass review and related process checks; does it matter how much or how little AI was used in it's creation?
Personally, my answer is no. But there is a vast difference between a human using AI and an AI generated contribution being able to pass as human. I think there will be increasing degrees of the former, but the latter is improbable to impossible without another generational leap in AI research/technology (at least IMO).
---
As a side note, over usage of AI to generate code _is_ a problem I am currently wrangling with. Contributors who are over relying on vibecoding are creating material overhead in code review and maintenance in my current role. It's making maintenance, which was already a long tail cost generally, an acute pain.
Of course you can tell. If someone suddenly submits a mountainous pile of code out of nowhere that claims to fix every problem, you can make a reasonable estimate that the author used AI. It's then equally reasonable to suggest said author might not have taken the requisite time and detail to understand the scope of the problem.
This is the basis of the argument - it doesn't matter if you use AI or not, but it does matter if you know what you're doing or not.
The system works because responsibility sits with the submitter
Whether the quality of the code is the responsibility of the submitter or not is kind of irrelevant though, because the cost of verifying that quality still falls on the maintainer. If every submitter could be trusted to do their due diligence then this cost would be less, but unfortunately they can't; it's human nature to take every possible shortcut.
The same way niche/luxury product and services compare to fast/cheap ones: they are made with focus and intent that goes against the statistical average, which also normally would take more time and effort to make.
McDonalds cooks ~great~ (edit: fair enough, decent) burgers when measured objectively, but people still go to more niche burger restaurants because they want something different and made with more care.
That's not to say that an human can't use AI with intent, but then AI becomes another tool and not an autonomous code generating agent.
> McDonalds cooks great burgers when measured objectively
Wait, what? In what world are McDonalds burgers "great"? They're cheap. Maybe even a good value. But that's not the same as great.
They are consistent and decent, though arguably some are even good (though everyone usually has a preferred fast food destination).
Some of the best burgers I've ever had came from fast food.
Probably more of the measure of the Deluxe burger, which if fresh doesn't seem to have any faults for a burger. Now the little McFrankinstines leave much to be desired.
Fair enough, I should've said borderline decent.
https://xkcd.com/810/
I know it's a cliche but it's just too perfect to answer this question.
Why accept PR's in this case, if the maintainers themselves can ask their favorite LLM to implement a feature/fix an issue?
Because it might require time consuming testing, iterations, documentation etc.
If everything the maintainer wants can (hypothetically) be one-shotted, then there is no need to accept PR's at all. Just allow forks in case of open source.
Obviously - it takes effort to hone the idea/spec, and it takes time to validate the result. Code being free doesn’t make a kernel patch free, though it would make it cheaper.
> but in 3-10 years AI will get significantly better
Crystal ball or time machine?
Crystal ball, maybe, but 3 years ago, the AI generated classes with empty methods containing "// implement logic here" and now, AI is generating whole stack applications that run from the first try.
Past performance does not guarantee future results, of course. But acting like AI is now magically going to stagnate is also a really bold bet.
> now, AI is generating whole stack applications that run from the first try
I sincerely doubt that, because it still can't even generate a few hundred line script that runs on the first try. I would know, I just tried yesterday. The first attempt was using hallucinated APIs and while I did get it to work eventually, I don't think it can one shot a complex application if it can't one shot a simple script.
IMO, AI has already stagnated and isn't significantly better than it was 3 years ago. I don't see how it's supposed to get better still when the improvement has already stopped.
What tool did you use ?
I routinely generate applications for my personal use using OpenCode + Claude Sonnet/Opus.
Yesterday I generated an app for my son to learn multiplication tables using spaced repetition algorithm and score keeping. It took me like 5 minutes.
Of course if you use ChatGPT it will not work but there is no way Claude Code/Open Code with any modern model isn't able to generate a one hundred line script on the first try.
Are we still doing the "your fault for not using this other model" thing? It's a bit of a tired trope at this point.
I was asking which tool, not which, not which model.
For the same model, you can just have it generate dad jokes or use it in a tool like OpenCode or Cursor or Zed or Cline or … and make it program complex things.
If I use Claude Sonnet on duck.ai I will have hard time generating something interesting. The same model in OpenCode does all my programming work.
>isn't significantly better than it was 3 years ago.
Eh?
Ever hear the saying the first 90% of a problem is 90% of the work, the last 10% of the program is also 90% of the work.
AI/LLMs have improved massively in that context. That's not even including the other model types such as visual/motion-visual/audio which are to the point that telling their output from reality is a chore.
And one shotting a simple script simply doesn't mean much without context. I have it dump relatively complex powershell scripts often enough and it's helped me a lot with being able to explain scripting actions to other humans where before I'd make assumptions about the other users knowledge where it was not warranted.
The biggest grift is invested tech Bro's trying to sell you on thr fact that Ai growth is linear or even exponential.
In reality it's Logarithmic. Maybe with the occasional jolt. You'd think with Moores "law" that we'd know better by now that explosive growth isn't forever. Or at least that we're bound to physics as a cap to hit.
Isn't your prediction a good thing? People prefer humans currently as they are better but if AI is just as good, doesn't that just mean more good PRs?
> but if AI is just as good, doesn't that just mean more good PRs?
If you believe the outputs of LLMs are derivative products of the materials the LLMs were trained on (which is a position I lean towards myself, but I also understand the viewpoint of those who disagree), then no, that's not a good thing, because it would be a license violation to accept those derived products without following the original material's license terms, such as attribution and copyleft terms. You are now party to violating the original materials' copyright by accepting AI generated code. That's ethically dubious, even if those original authors may have a hard time bringing a court case against you.
> If you believe the outputs of LLMs are derivative products of the materials the LLMs were trained on
In that case a lot of proprietary software is in breach of copyleft licences. Its probably by far the commonest breach.
> You are now party to violating the original materials' copyright by accepting AI generated code. That's ethically dubious
That is arguable. Is it always ethically dubious to breach a law? If not, which is it ethically dubious to breach this law in this particular way?
> In that case a lot of proprietary software is in breach of copyleft licences. Its probably by far the commonest breach.
Sure, but this doesn't really seem relevant to the conversation. Someone else violating software license terms doesn't justify me (or Debian, in the case of TFA) doing so.
> Is it always ethically dubious to breach a law?
I'm not really concerned with the law, here. I think it is ethically dubious to use someone else's work without compensating them in the manner they declared. Copyright law happens to be the method we've used for a couple hundred years to standardize the discussion about that compensation, and sometimes enforce it. Breaching the law doesn't really enter into the conversation, except as a way our society agrees to hold everyone to a minimum ethical standard.
> I'm not really concerned with the law, here. I think it is ethically dubious to use someone else's work without compensating them in the manner they declared.
OK, that is reasonable. I do not think copyright is a good mechanism though, and I think the need to compensate depends on multiple factors depending on what you use a work for and under what circumstances.
Let's burn that bridge when we get to it. I'm not even sure what 2027 will look like at this rate. There's no point concerning about 2035 when things are so tumultuous today.
with improvements, we wouldn't even talk about code. just designs and features!
You say "on a long enough timeline", but you already can't tell today in the hands of someone who knows what they're doing.
I think a lot of anti-LLM opinions just come from interacting with the lowest effort LLM slop and someone not realizing that it's really a problem with a low value person behind it.
It's why "no AI allowed" is pointless; high value contributors won't follow it because they know how to use it productively and they know there's no way for you to tell, and low value people never cared about wasting your time with low effort output, so the rule is performative.
e.g. If you tell me AI isn't allowed because it writes bad code, then you're clearly not talking to someone who uses AI to plan, specify, and implement high quality code.
> It's why "no AI allowed" is pointless … If you tell me AI isn't allowed because it writes bad code
I disagree that the rule is pointless, and your last point is a strawman. AI is disallowed because it’s the manner in which the would-be contributors are attempting to contribute to these projects. It’s a proxy rule.
Unfortunately for AI maximalists, code is more than just letters on the screen. There needs to be human understanding, and if you’re not a core contributor who’s proven you’re willing to stick around when shit hits the fan, a +3000 PR is a liability, not an asset.
Maybe there needs to be something like the MMORPG concept of “Dragon Kill Points (DKP)”, where you’re not entitled to loot (contribution) until you’ve proven that you give a shit.
> Unfortunately for AI maximalists, code is more than just letters on the screen. There needs to be human understanding, and if you’re not a core contributor who’s proven you’re willing to stick around when shit hits the fan, a +3000 PR is a liability, not an asset.
This isn't necessarily true; I've seen some projects absorb a PR of roughly that size, and after the smoke tests and other standard development stuff, the original PR author basically disappeared.
It added a feature he wanted, he tested and coded it, and got it in.
So because some projects can absorb some PRs of a certain size, all projects of should be able to absorb PRs of that same size?
This anecdotal argument is a dead end. The nuance is clear: not all software is the same, and not all edits to software are the same.
>So because some projects can absorb some PRs of a certain size, all projects of should be able to absorb PRs of that same size?
Your argument has nothing to do with AI and more to do with PR size and 'fire and forget' feature merges. That's what the commenter your responding to is pointing out.
And my entire point is that LLM-generated feature requests are strongly correlated with high risk merge requests / pull requests, to which the commenter made no meaningful argument against. Instead the commenter chose to focus on the size of the PR and say “well I’ve seen it in the wild”.
The way to get around this without getting all the LLM influencer bros in an uproar is to come up with a system that allows open source libraries to evaluate the risk of a PR (including the author’s ability to explain wtf the code does) without referencing AI because apparently it’s an easily-triggered community.
> and if you’re not a core contributor who’s proven you’re willing to stick around when shit hits the fan, a +3000 PR is a liability, not an asset.
And in the context of high-value contributors that GP was mentioning, they are never going to land a +3000 PR because they know there is going to be a human reviewer on the other side.
>where you’re not entitled to loot (contribution) until you’ve proven that you give a shit.
So what metric are you going to try to use to prove yourself?
Vibe coded slop is a 50 DKP minus of course
I don't see an issue here. You keep using AI to create high value contributions in the projects that accept it, I will keep not using it in mine, and we can see who wins out in 10 years.
> high value contributors won't follow it
High-value contributors follow the rules and social mores of the community they are contributing to. If they intentionally deceive others, they are not high-value.
Ah, the no true Scotsman theory.
Arguing that "doesn't secretly, sneakily break project rules" is an essential component of a quality contributor isn't a "no true scotsman" argument, it's a statement about qualifications
But then why have any contributions at all?
Like its been years and years now, if all this is true, you'd think there would be more of a paradigm shift? I'm happy I guess waiting for Godot like everyone else, but the shadows are getting a little long now, people are starting to just repeat the same things over and over.
Like, I am so tired now, it's causing such messes everywhere. Can all the best things about AI be manifest soon? Is there a timeline?
Like what can I take so that I can see the brave new world just out of reach? Where can I go? If I could just even taste the mindset of the true believer for a moment, I feel like it would be a reprieve.
> Where can I go?
Off the internet. Maybe it's just time we all face the public internet is dead.
Maybe a trusted private internet, though that comes with it's own risks and tradeoffs.
Maybe we start doing PRs over mailed USB keys. Anyone with enough interest will do it, but it will cut out the bots. We're back to a 90's sneakernet. Any internet presence may become a read only site telling others how to reach you offline.
The information superhighway died a long time ago. 4chan enlightened me on the power of intelligent stupidity. The machinations of a few smart people could embolden countless stupid people to cause nearly unlimited damage. Social media gathering up the smart and dumb alike allowed bullshit asymmetry to explode onto the scene and burned out anyone with a modicum of intelligence.
All LLM-output is slop. There's no good LLM output. It's stolen code, stolen literature, stolen media condensed into the greatest heist of the 21. century. Perfect capitalism - big LLM companies don't need to pay royalties to humans, while selling access to a service which generates monthly revenue.
Whether it trained on real world "stolen" code is an implementation detail. A controversial one, but it isn't a supporting argument for whether it can write high quality, functional code or not.
Sorry, but no, that is not a detail, that is a major sticking point for me.
I'm fine with calling all LLM outputs slop, but I'll draw the line at asserting there's no good LLM output. LLM output is good when it works, and we can easily verify that a lot of code from LLMs does work. That the code LLMs output is derive of copyrighted works is neither here nor there. First of all, ALL creative work is derivative. Secondly IP is absurd horse shit and we never should have humored the premise of it being treated like real property.
I came from a poor background and stole pretty much all the textbooks I used to learn programming as a kid. I also stole all the music I listened to while studying them. Is everything I write slop for the same reason?
No. You're a human, who went through real life experiences. You learned, developed as a human being. You made mistakes and grew from them. You did what you have to do to advance. What you output has intrinsic value because of all this. I argue that even when you roll your face on your keyboard, the output is more valuable than ten pages of slop output from an LLM, since it's human, with all the history, experience, emotions and character which came before it.
A quote from Neuromancer comes to mind:
The Neo-Victorian perspective of The Diamond Age is not a luxury most of us are going to be able to afford unfortunately.
I don't know why this got downvoted. I've already been so frustrated by HN LIDAR mindsets but holy shit.
Human society exists because we value humans, full stop. The easiest way to "solve" all of humanity's problems is to simply say that humans aren't valuable. Sometimes it feels like we're conceding a ridiculous amount of ground on that basic principle every year - one more human value gone because it "doesn't matter", so hey, we've obviously made progress!
Agreed. I think that sometimes people on HN lose sight of what is actually important, which is human flourishing. The other day there was someone arguing that the best thing to do to fix loneliness problems in society is to remove the human need for socializing. Which... is certainly one way to fix the problem, I guess, but completely missed the point. The point is not to fix a mismatch between essential human desires and what we can attain, the point is to work on fulfilling those desires! Just something goes with nerd autism, I guess.
> I don't know why this got downvoted. I've already been so frustrated by HN LIDAR mindsets but holy shit
The extreme sides (proponents, opponents) are clear, opposites, and fight each other. More nuanced takes get buried as droplets in a bucket. Likely a goal.
> Human society exists because we value humans, full stop.
Call me cynic, but I do not believe every human being agrees with this sentiment. From HR acting as if humans are resources, to human beings being dehumanized as workers, civilians, cannon fodder, and... well, the product. Every time human rights are violated, and we do not stand up to it, we lose.
I have a very simple question as human right: the right for a human being to know the other side is a human being yes or no, and if not: to speak gratis (no additional fee allowed) to a human being instead. Futhermore, ML must always cite the used sources, and ML programmer is responsible for mistake. This would increase insurance costs so much, that LLM's in public would die, but SLM's could thrive.
>Human society exists because we value humans, full stop.
Eh, human society exists because it is an emergent behavior of the evolutionary advantage afforded at the time of adoption by the human species. There is on iron rule stating that it must continue into the future, or even that it can exist into the future.
More so, the value of a human has wildly fluctuated over history and culture. The village chief, nobles, the king were all high value humans. The villagers would be middle to low value, and others may be considered no value.
The industrial age began to change this some as value started to move from the merchant class to the villager class as many high production jobs needed less and less training to complete. With industrialization businesses running machines and production lines needed as many people as they could get. Still human rights were hard fought in places like America where labor wars broke out.
In the modern US we've setup a dangerous set of idealism that will most likely end in disaster because they are in conflict with general human values. That is the "pull yourself up by your bootstraps", "Any collective action is communism and communism will turn you into a pillar of salt if you dare look at it", and "greed is good". Couple that with TV media and social media owned by rich billionaires you're not going to see much serious opposition to these ideals.
But if/as labor loses it's values, so will the humans that performed that labor. After decades of optimizing human society for maximal capital extraction, values are dead, and the ever present thought police owned by the rich will make sure you don't cause too much trouble by resurrecting them.
Well put. Im gonna start parroting this talking point more from now on.
And I thought being a stochastic parrot was limited to LLMs, but apparently they learned it from somewhere...
Intent matters. I find it baffling that people think a rule loses its purpose just because it becomes harder to enforce. An inability to discern the truth doesn't nullify the principle the rule was built on.
Debian's priority is not to upset people who have put the work in on the project.
Basically "let's not screw anyone"
It's a good policy
Does Debian have a rule that forbids (or a taboo that proscribes) contributors passing off other people’s work as their own? I could believe that such a rule is implied rather than written down. The GR could be about writing it down, and it would surely cover the case of code that came directly from a model. Even if we don’t consider a model to be another person it is certainly not the contributor’s own work.
(If anything, the copyright to model-generated code cannot possibly be said to belong to the human contributor. They… didn’t write it! I’m glad to see that aspect was discussed though I’m surprised it wasn’t the main thrust.)
> Does Debian have a rule that forbids (or a taboo that proscribes) contributors passing off other people’s work as their own? I could believe that such a rule is implied rather than written down.
It’s implied because it’s illegal (infringes on the original author’s rights). Of course, LLMs aren’t people.
I think all machine generated content should be labeled as such. And if a maintainer or a consumer or whoever doesn't want to accept it, so be it. But people should at least have the choice.
Fork it to Slobian and let the clankers go to town creating, approving and merging pull requests by themselves. Look at the install base to see what people prefer.
The discussion in question starts here: https://lists.debian.org/debian-vote/2026/02/msg00000.html
What a banger sub-thread: https://lists.debian.org/debian-vote/2026/02/msg00020.html
The quality argument against LLM-generated code has always seemed weak to me. Maintainers already review patches because humans routinely submit bad code. The review process is the filter.
Bad human code is usually fairly obvious, bad LLM code often less so, because it’s trained to produce superficially sensible-looking code. Hence reviewing it requires higher alertness and is more work. The other problem is that LLMs allow a human to submit much larger amounts of code to be reviewed than if they had to write the code themselves.
This reminds me of the Hacktoberfest situation where maintainers were getting flooded with low-quality PRs. This could be that, but on steroids and constantly, not just one month.
Did anyone say it is a risk? What if courts eventually decide that users of products of closed models have to pay some reasonable fee to the owners of the training data?
In some sense, I think the promise of free software is more real today than before because everyone else's software is replicable for relatively cheap. That's probably a much stronger situation for individual freedom to replicate and run code than in the era of us relying on copyright.
This freedom depends on the hardware and pricing of megacorps that are currently busy in applying their knowledge to do surveillance and killing. I doubt we can rely on them to help with our freedom.
Treat this as person's own contribution. If the quality is bad, means the person has allowed it, or the person's quality of work is bad, and it doesn't matter whether they produced it or AI did. So in both cases they'd deserve a rejection of their PR. The only downside is that it takes away precious reviewer energy and time.
Aside, that's a fun read/format, like reading about judges arguing how to interpret a law or debating whether a law is constitutional.
In my opinion- we need to successfully integrate generative AI into our workflows, but we need to do it appropriately and exercise caution. Ex. If you are a senior developer utilizing AI as a tool then I see using Generative AI as a competitive advantage. If you are a junior developer claiming to be a senior developer that is not okay.
All in All, just be honest with yourself, and be honest to others on where your skills lie. AI can be a great tool, but it should not replace you.
I'd love to see the policy on review tools to start with, I know even people who are skeptical of getting "AI Slop" thrown at them by agents at a high rate, getting code reviews from some of the SOTA models definitely can be helpful.
Google found that with Jules years ago at this point, same for other automated tools.
When I first saw the headline though, it sounded like someone was listening to one of my favorite Rush songs.
"""
If you choose not to decide
You still have made a choice
You can choose from phantom fears
And kindness that can kill
I will choose a path that’s clear
I will choose free will.
"""
Good decision. The two extremes of this decision are both bad. On one hand the status quo of a lot of slop demanding attention from busy people is just not sustainable and something has to change. But throwing out the baby with the bath water by just blanket banning all forms of AI contributions is not a long term sustainable solution. It's a stop gap solution at best. And one that would be challenged more and more as inevitably tools keep on getting better and more widely used. It's not going to take years even. Deciding to not decide right now gives people some time to think and reflect.
The right way might be to fight AI slop with AI enforced guard rails. It's not actually that hard to implement technically. You can literally just put some markdown skills in your repository and periodically have an AI bot apply the review PR skill to incoming PRs to pre-screen them and automatically close PRs that obviously fall short of well documented criteria, and label & prioritize remaining ones.
Open claw might be a bridge too far for some at this point but it's maybe a glimpse of a future where we have AI bots filtering, screening and funneling inbound information. If you are a bit handy, you can just unleash codex or code claude on your issue tracker and pull requests right now. Worth experimenting with at a small scale.
Criteria could include doing a quick code review. Is the code appropriate and minimal? Does it meet all the documented criteria? Does it fix something that is worth fixing? Does it need further review? AIs can do all sorts of things with PRs ranging from commenting to closing the PR, prioritizing it, commenting on them, or flagging it for escalation to the right person in the team. By the time a real person chooses to spend time on a PR it should have already passed a lot of quality gates and be in a decent enough shape.
A second innovation here could be doing more with reputation. Github users build up reputation by virtue of all the contributions they make over time to all sorts of projects. Also, git allows people to sign their commits. That allows AI gate keepers to sort incoming contributions by reputation. Maybe be lenient towards known repeat contributors. Give the benefit of the doubt to new contributors but scrutinize them more and be very strict on everybody else by default. In a meritocracy, you build reputation by consistently doing good work. Dumping a lot of AI slop on somebody's desk would be the opposite.
Just some thoughts. I have a few smaller github projects but I'm so far not burdened by a lot of low quality PRs.
> The right way might be to fight AI slop with AI enforced guard rails.
Whenever I you tried to develop using guardrails with LLMs, I found out that they are much better at ,,cheating'' than a human: getting around the guardrails by creating the ugliest hacks around them.
A title that might make Geddy Lee proud
Given the 10x+ productivity rate, it would be reasonable to establish a higher quality acceptance bar for AI submissions. 50-100% more performance, correctness, usability testing , and one round of human review.
If a change used to take a day or two, and now requires a few minutes, then it's fair to ask for a couple hours more prompting to add the additional tangible tests to compensate for any risks of hallucinations or low quality code sneaking in
Soon we can call it debslop!
> 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]'.
Quixotic, unworkable, pointless. It’s fundamentally impossible (at least without a level of surveillance that would obviously be unavceptable) to prove the “artisanal hand-crafted human code” label.
> 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".
This is in the right direction.
I think the missing link is around formalizing the reputation system; this exists for senior contributors but the on-ramp for new contributors is currently not working.
Perhaps bots should ruthlessly triage in-vouched submissions until the actor has proven a good-faith ability to deliver meaningful results. (Or the principal has staked / donated real money to the foundation to prove they are serious.)
I think the real problem here is the flood of low-effort slop, not AI tooling itself. In the hands of a responsible contributor LLMs are already providing big wins to many. (See antirez’s posts for example, if you are skeptical.)
> Quixotic, unworkable, pointless. It’s fundamentally impossible (at least without a level of surveillance that would obviously be unavceptable) to prove the “artisanal hand-crafted human code” label.
Difficulty of enforcing is a detail. Since the rule exists, it can be used when detection is done. And importantly it means that ignoring the rule means you’re intentionally defrauding the project.
Debian has always been Debian and thus there are these purist opinions, but perhaps my take too would be something along the "one-strike-and-you-are-out" kind of a policy (i.e., you submit slop without being able to explain your submission in any way) already followed in some projects:
https://news.ycombinator.com/item?id=47109952
Yeah this is what I was getting at with “reputation” - I think the world where anyone can submit a patch and get human eyes on it is a thing of the past.
IIRC Mitchell Hashimoto recently proposed some system of attestations for OSS contributors. It’s non-obvious how you’d scale this.
This is like trying to stop spam by banning emails that send you spam.
They can spin up LLM-backed contributors faster than you can ban them.
If the situation becomes that worse, I agree with you; otherwise, I don't see that as a problem.
Banning AI would hardly stop that, the LLM contributors would simply claim they're not AI.
Hence why banning AI contributions is meaningless, you literally only punish 'good' actors.
I agree. If the real concern is the flood of low-effort slop, unmaintainable patches, accidental code reuse, or licensing violations, then the process should target those directly. The useful work is improving review and triage so those problems get filtered out early. The genie is already out of the bottle with AI tooling, so broad “no AI” rules feel like a reaction to the tool and do not seem especially useful or enforceable.
LLM-generated code is incompatible with libre software. It's extremely frustrating to see such a lack of conviction to argue this point forcefully and repeatedly. It's certainly bad enough to see such a widespread embrace of this dangerous and anti-libre technology within proprietary software teams, but when it comes to FLOSS, it should be a no-brainer to formalize an emphatic anti-slop contributor policy.
> It's extremely frustrating to see such a lack of conviction to argue this point forcefully and repeatedly.
It is. You haven't argued it at all, right here. You just asserted it as if it were self-evident, talked about your feelings, then demanded policy.
Your only job here was to convince people to align with you, and you didn't bother. It makes me suspect that you haven't really solidified the argument in your own mind.
I don't understand a lot of the anti-LLM venom within this specific context. Debian doesn't have to worry about stealing GPL code, so the copyright argument is nearly nil. There's still the matter of attribution-ware, but Debian includes tons of attribution and I'm sure would happily include anyone who thinks their OSS might have been trained on.
So leaving that aside, it just seems to be the revulsion that programmers feel towards a lot of LLM slop and the aggravation of getting a lot of slop submissions? Something that seems to be universal in the FOSS social environment, but also seems to be indicative of a boundary issue for me:
The fact that machines have started to write reasonable code doesn't mean that you don't have any responsibility to read or review it before you hand it to someone. You could always write shit code and submit it without debugging it or refactoring it sanely, etc. Projects have always had to deal with this, and I suspect they've dealt with this through limiting the people they talk to to their friends, putting arbitrary barriers in front of people who want to contribute, and just being bitchy. While they were doing this, non-corporate FOSS was stagnating and dying because 1) no one would put up with that without being paid, and/or 2) money could buy your way past barriers and bitchiness.
Projects need to groom contributors, not simply pre-filter contributions by identity in order to cut down on their workload. There has to be an onboarding process, and that onboarding process has to include banning and condemning people that give you unreviewed slop, and spreading their names and accounts to other projects that could be targeted. Zero tolerance for people who send you something to read that they didn't bother to read. If somebody is getting AI to work for them, then trust grows in that person, and their contributions should be valued.
I think the AI part is a distraction. AI is better for Debian that almost anyone else, because Debian is copyleft and avoids the problems that copyleft poses for other software. The problem is that people working within Free Software need some sort of structured social/code interaction where there are reputations to be gained and lost that aren't isolated to single interactions over pull requests, or trying to figure out how and where to submit patches. Where all of the information is in one place about how to contribute, and also about who is contributing.
Priority needs to be placed on making all of this stuff clear. Debian is a massive enough project, basically all-encompassing, where it could actually set up something like this for itself and the rest of FOSS could attach itself later. Why doesn't Debian have a "github" that mirrors all of the software it distributes? Aren't they the perfect place? One of the only good, functional examples of online government?
edit: There's no reason that Debian shouldn't be giving attribution to every online FOSS project that could possibly be run on Linux (it will be run on Debian, and hopefully distributed through apt-get.) Maybe a Debian contributor slash FOSS-in-general social network is the way to do that? Isn't debian.org almost that already?
Before LLM did code, you could at least have assumed that the submitter had written it (at worst, copy-pasted large parts of it), even if they had not read or reviewed it. Furthermore, writing (even copy pasting) is quite labour intensive, so there was that hurdle too.
The website is absolutely atrocious, dark mode has pitch-black background with bold 100% white glowing text in foreground, shitty font, way to wide text.
Seriously how is lwn.net even still so popular with such an atrocious unreadable ugly website. Well yes I get the irony of asking that on HN (I use an extension to make it better).
They have a settings page where you can set the colours you like… Most people who don't like them just change them to something they like.
Again you can see which developers are owned by corporations and which are not. There is no free software any longer.
What do you mean?
A number of debian developers do that as part of their full time jobs for canonical, microsoft, and other companies.
An interesting concept that stood out to me. Committing the prompts instead of the resulting code only.
It it really true the LLM's are non-deterministic? I thought if you used the exact input and seed with the temperature set to 0 you would get the same output. It would actually be interesting to probe the commit prompts to see how slight variants preformed.
> I thought if you used the exact input and seed with the temperature set to 0 you would get the same output.
I think they can also be differences on different hardware, and also usually temperature is set higher than zero because it produces more "useful/interesting" outputs
I think it's a complicated issue.
A lot of low quality AI contributions arrive using free tiers of these AI models, the output of which is pretty crap. On the other hand, if you max out the model configs, i.e. get "the best money can buy", then those models are actually quite useful and powerful.
OSS should not miss out on the power LLMs can unleash. Talking about the maxed out versions of the newest models only, i.e. stuff like Claude 4.5+ and Gemini 3, so developments of the last 5 months.
But at the same time, maintainers should not have to review code written by a low quality model (and the high quality models, for now, are all closed, although I heard good things about Minmax 2.5 but I haven't tried it).
Given how hard it is to tell which model made a specific output, without doing an actual review, I think it would make most sense to have a rule restricting AI access to trusted contributors only, i.e. maintainers as a start, and maybe some trusted group of contributors where you know that they use the expensive but useful models, and not the cheap but crap models.
It's the difference between raw LLM output vs LLM output that was tweaked, reviewed and validated by a competent developer.
Both can look like the same exact type of AI-generated code. But one is a broken useless piece of shit and the other actually does what it claims to do.
The problem is just how hard it is to differentiate the two at a glance.
> It's the difference between raw LLM output vs LLM output that was tweaked, reviewed and validated by a competent developer.
This is one of those areas where you might have been right.. 4-6 months ago. But if you're paying attention, the floor has moved up substantially.
For the work I do, last year the models would occasionally produce code with bugs, linter errors, etc, now the frontier models produce mostly flawless code that I don't need to review. I'll still write tests, or prompt test scenarios for it but most of the testing is functional.
If the exponential curve continues I think everyone needs to prepare for a step function change. Debian may even cease to be relevant because AI will write something better in a couple of hours.
This very much depends on the domain you work in. Small projects in well tread domains are incredible for AI. SaaS projects can essentially be one-shot. But large projects, projects with specific standards or idioms, projects with particular versions of languages, performance concerns, hardware concerns, all things the Debian project has to deal with, aren't 'solved' in the same way.
The tacit understanding of all these is that the valued contributors can us AI as long as they can "defend the code" if you will, because AI used lightly and in that way would be indistinguishable from knuthkode.
The problem is having an unwritten rule is sometimes worse than a written one, even if it "works".