Discussion
Debian decides not to decide on AI-generated contributions
SamuelAdams: 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?
sheepscreek: 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.
Jleagle: 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?
hombre_fatal: 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.
wadim: Why accept PR's in this case, if the maintainers themselves can ask their favorite LLM to implement a feature/fix an issue?
FrojoS: 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.
lich_king: > 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 if the contributor is even 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 everything, but you're on stronger footing if it ever blows up.
theptip: 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.
coldpie: > 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.
graemep: > If you believe the outputs of LLMs are derivative products of the materials the LLMs were trained onIn 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 dubiousThat 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?
lpcvoid: 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.
hombre_fatal: 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.
datsci_est_2015: > It's why "no AI allowed" is pointless … If you tell me AI isn't allowed because it writes bad codeI 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.
mrbungie: 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 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.
AlexandrB: > McDonalds cooks great burgers when measured objectivelyWait, what? In what world are McDonalds burgers "great"? They're cheap. Maybe even a good value. But that's not the same as great.
sieep: Well put. Im gonna start parroting this talking point more from now on.
ronsor: And I thought being a stochastic parrot was limited to LLMs, but apparently they learned it from somewhere...
__alexs: 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?
lpcvoid: 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.
theptip: > 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.)
techwizrd: 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.
__alexs: The Neo-Victorian perspective of The Diamond Age is not a luxury most of us are going to be able to afford unfortunately.
vladms: 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.
rustyhancock: 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
vladms: > 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).
jacquesm: Sorry, but no, that is not a detail, that is a major sticking point for me.
darkwater: > 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.
SlinkyOnStairs: 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.
hombre_fatal: 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.
bombcar: 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.
SlinkyOnStairs: 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 specMy 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.
bityard: > 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.
iLoveOncall: > but in 3-10 years AI will get significantly betterCrystal ball or time machine?
pjerem: 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.
delichon: > I see reviewing and accepting a PR is a question of trustI 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.
mikkupikku: 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.
est31: 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.
bombcar: 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".
jruohonen: 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
bombcar: 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.
mr-wendel: 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.
glenstein: 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 instigating nuclear wars.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.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.
hananova: > 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.
jajuuka: 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.
sothatsit: 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 they submitted bad code, having used AI is not a valid excuse.
bombcar: > 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.
datsci_est_2015: 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.
bigstrat2003: > now, AI is generating whole stack applications that run from the first tryI 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.
sigseg1v: Vibe coded slop is a 50 DKP minus of course
IshKebab: It should be the responsibility of the person submitting changes. The problem is AI apparently makes it easy for people to shirk that responsibility.
ACCount37: 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.
QuercusMax: 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.
moduspol: > 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.
ok_dad: 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.
distances: 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.
qsera: > people to shirk that responsibility.Actually not shrink, but just transfer it to reviewers.
sothatsit: Trusted contributors using LLMs does not cause this problem. It is only a real problem in the ever-increasing number of new unknown contributors that are shirking responsibilities.Policies against AI only really affect the trusted group of people acting in good-faith, but they don’t really affect the second group who are acting without care from the start.
VorpalWay: 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.
MintPaw: 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.
dudeinhawaii: 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.
SlinkyOnStairs: 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.
qsera: > 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.
sothatsit: 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.Attempting to restrict AI to improve contribution quality might counterintuitively have the opposite effect by hindering good contributors while bad contributors ignore the restrictions.
1vuio0pswjnm7: A title that might make Geddy Lee proud
dormento: I wonder if the right call wouldn't be impose a LOC limit on contributions (sensibly chosen for the combination of language/framework/toolset).
sothatsit: I quite like this direction. Limit new contributors to small contributions, and then relax restrictions as more of their contributions are accepted.
j2kun: This is a bit of a straw man. The harms of AI in OSS are not from people needing accessibility tooling.
DonsDiscountGas: 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.
johnnyanmac: He doesn't think others deserve a voice, so why should I consider his?
mr-wendel: 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.
johnnyanmac: > 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.
johnnyanmac: [delayed]
ivan_gammel: 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.
notatoad: 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.
why_at: >Personally, I love the "hallucinations" as they help me fine-tune my prompts, base instructions, and reinforce intentionalityThis 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
lawn: Yeah, if RSI is an issue why would you want to be forced to type more?
aerodexis: Interesting argument for AI ethics in general. It takes the form of "guns don't kill people - people kill people".
dataflow: 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.
johnnyanmac: 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.
veunes: Accessibility is an angle that rarely comes up in these debates and it's a strong one
veunes: 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.
pixl97: > 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?
ivan_gammel: 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.
arjie: 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.
veunes: The system works because responsibility sits with the submitter
MeteorMarc: 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?
veunes: 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
oceanplexian: > 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.
