Live data from Hacker News

Debian decides not to decide on AI-generated contributions

lwn.net

111–120 of 308 posts

Re: Debian decides not to decide on AI-generated contributions

#111

Earlier quoted context omitted.

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 submi…

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 submissi…

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.

Re: Debian decides not to decide on AI-generated contributions

#112

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 user…

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 pro…

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

Re: Debian decides not to decide on AI-generated contributions

#113

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 user…

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

Re: Debian decides not to decide on AI-generated contributions

#114
post #98

Earlier quoted context omitted.

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

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 dri…

I wonder if the right call wouldn't be impose a LOC limit on contributions (sensibly chosen for the combination of language/framework/toolset).

Re: Debian decides not to decide on AI-generated contributions

#115
post #80

Earlier quoted context omitted.

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 onl…

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

Re: Debian decides not to decide on AI-generated contributions

#116
post #80

Earlier quoted context omitted.

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

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?

Re: Debian decides not to decide on AI-generated contributions

#117

Earlier quoted context omitted.

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 dri…

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.

Re: Debian decides not to decide on AI-generated contributions

#119

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 user…

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.

Re: Debian decides not to decide on AI-generated contributions

#120

Earlier quoted context omitted.

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.

Post reply on HN