> 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.

> 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.

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 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.

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.

> I'd MUCH rather see a holistic embrace and integration of these tools into our ecosystems. Telling people "no AI!" (even if very well defined on what that means) is toothless against people with little regard for making the world (or just one specific repo) a better place.

If it makes them go thru AI contributions to make sure there is no AI nonsense in them, that's already massive win.

The AI on itself is not a problem

> But, on the flip side, I personally advocate hard for AI from the point-of-view on accessibility. I know (more-or-less) exactly what output I'm aiming for and control that obsessively, but it's AI and my voice at the helm instead of my fingertips.

and you are the 1% (assuming your claims are true and not hallucinated gains, which are common in AI world too), vast majority of AI contributions are peak lazy, or at best goal-seeking with no regard of the target, consequences or quality

THAT is what people complain about. If AI was just used to shortcut the boring, augument the knowledge and produce better quality code, there would be very little arugments against AI-driven contributions. But that is not the case, the AI pundits will purposefully not check the AI output just because that would require time and knowledge and that looks bad on "how faster AI makes you" KPI

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.

On the code side of the issue, I would say that AI completion and chat are ok because people are still forced to interact with the generated code. When coding with agents people have to go out of their way to do it

lol You are actually trying to argue and say "Oh actually, I love how AI fucks up, it makes me keep on my toes."

That's like saying I love hiring fuck ups that randomly do out of context and out of ruleset work for me when I ask them to perform tasks.

I would also argue to you that "folks" have done more well to debate the upsides of AI. It is pretty much all I ever see when I come to this website any more the last couple of years. Oh, and by coincidence, the operator/owner of the website just happens to be at the helm of ChatGPT. How convenient.

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.

As someone who got a pretty severe case of carpal tunnel in his youth that can still blow up today, I have to admit I have worried about my ability to work. "Will I have to become a manager?" Etc.

I think you have a good point

>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

> without a battle of ego.

This resonates. Recently, I've started to consider Claude as a partner. I like how he's willing to accept he's wrong when you provide evidence. It can be more pleasant than working with humans.

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).

Glad to see this response, I was wondering the other day how the affected accessibility. I remember reading a thread a few years back of visually challenged developers and their work flow and was kinda surprised there has been such little discussion around developer accessibility with the advent of ai agents and coding routines.

>I love the "hallucinations"

Sorry, the rest of your comment could have the recipe for fat free deep fried blowjobs that cure cancer and I wouldn't read past that.

This is a bit of a straw man. The harms of AI in OSS are not from people needing accessibility tooling.

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?

> 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.

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.

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

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

> 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 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.

> 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 distinction that matters is whether the contributor can defend their work in review, not what tool produced it.

I maintain a 300-commit fork built with heavy AI assistance. The AI writes a lot of the code. I review every line and can explain every choice. The test: can they respond to feedback, explain why they chose this approach over the simpler one, iterate on edge cases? That works regardless of how the code was produced.

Debian's problem isn't AI. It's distinguishing "used a tool well" from "dumped output." Code review already does this. Tighter process for new contributors (smaller patches, demonstrated understanding through review conversation) filters on engagement quality, not tool choice.

The real invariant is responsibility: if you submit a patch, you own it. You should understand it, be able to defend the design choices, and maintain it if needed

It should be the responsibility of the person submitting changes. The problem is AI apparently makes it easy for people to shirk that responsibility.

> 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.

They can't, anyone who uses the tool correctly will be indistinguishable from their regular code contributions.

The ones that make the headlines here on HN are not subtle at all, they're probably the bottom of the barrel of AI users.

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.

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.

The system works because responsibility sits with the submitter

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.

> but in 3-10 years AI will get significantly better

Crystal ball or time machine?

Why accept PR's in this case, if the maintainers themselves can ask their favorite LLM to implement a feature/fix an issue?

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?

https://xkcd.com/810/

I know it's a cliche but it's just too perfect to answer this question.

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.

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.

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.

with improvements, we wouldn't even talk about code. just designs and features!

> 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 don’t think you’re overreacting.

Great care and attention is required for critical system components and LLMs lack both.

Not to mention the copyright risks - do we really want a piece of code that can’t be licensed or turns out to be a verbatim copy from another project to end up in the kernel or something? (No, the answer is we don’t want.).

i dont work in then auto industry but Ive read stuff from people that do and Im pretty sure I remember they all say that all major car mfg code is tons of auto generated slop even pre AI.

Was going to say, I'm interested to see if someone can build a nicer Linux distro going full AI spam.

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.

Sure, but does that mean we should accept Peter Theil's gospel in unquestioned?

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.

> 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

> 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.

> 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

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.

> 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.

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.

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.

What do you mean?

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.

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".