Hacker News

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

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.

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

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.

Accessibility is an angle that rarely comes up in these debates and it's a strong one

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

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

>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

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.

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

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

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.

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

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

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

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

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

Crystal ball or time machine?

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.

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?

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.

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.

> 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

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

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