11 ms·
Debian decides not to decide on AI-generated contributions
- techpulse_x 7mo ago[flagged]
- 3012846 7mo agoAgain you can see which developers are owned by corporations and which are not. There is no free software any longer.
- fidorka 7mo agoWhat do you mean?
- LtWorf 7mo agoA number of debian developers do that as part of their full time jobs for canonical, microsoft, and other companies.
- PunchyHamster 7mo agoIf you see developer rooting for using MIT/BSD licenses and especially replacing GPL with them, there is probably good 98% chance of them being corporate programmer that legal didn't allow to use GPL-licensed code and they are sad they can't steal everyone's work
- LtWorf 7mo agoLast elections for DPL it was the stated goal of one of the candidates to reduce the amount of copyleft in debian. At least they didn't win.
- SamuelAdams 7mo agoMy 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?
- hombre_fatal 7mo agoYou 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.
- lpcvoid 7mo agoAll 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.
- sieep 7mo agoWell put. Im gonna start parroting this talking point more from now on.
- ronsor 7mo agoAnd I thought being a stochastic parrot was limited to LLMs, but apparently they learned it from somewhere...
- hombre_fatal 7mo agoWhether 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.
- deleted 7mo ago[deleted]
- theptip 7mo ago> 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.)
- jruohonen 7mo agoDebian 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 https://news.ycombinator.com/item?id=47109952
- vladms 7mo agoVery 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 7mo agoImportant 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 7mo ago> 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).
- PowerfulWizard 7mo agoOn judging vs. making, also someone has to take time away from development to do code review. If the code being reviewed is written by someone who is involved and interested then at least there's a benefit to training and consensus building in discussing the code and the project in the review phase. The time and energy of developers who are qualified to review is quite possibly the bottleneck on development speed too so wasting review time will slow down development. For AI generated code if previous PRs aren't loaded into context then there's no lasting benefit from the time taken to review and it's blank slate each time. I think ultimately it can be solved with workflow changes (i.e. AI written code should be attributed to the AI in VCS, the full trace and manual edits should be visible for review, all human input prompts to the AI should be browsable during review without having scroll 10k lines of AI reasoning.)
- hombre_fatal 7mo agoAside, that's a fun read/format, like reading about judges arguing how to interpret a law or debating whether a law is constitutional.
- est31 7mo agoI 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.
- deleted 7mo ago[deleted]
- bombcar 7mo agoThe 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".
- ACCount37 7mo agoIt'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.
- oceanplexian 7mo ago> 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.
- mr-wendel 7mo agoMy 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 7mo agoFantastic 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.
- newzino 7mo ago[flagged]
- sothatsit 7mo agoConcerns about the wasting of maintainer’s time, onboarding, or copyright, are of great interest to me from a policy perspective. But I find some of the debate around the quality of AI contributions to be odd. Quality should always be the responsibility of the person submitting changes. Whether a person used LLMs should not be a large concern if someone is acting in good-faith. If they submitted bad code, having used AI is not a valid excuse. Policies restricting AI-use might hurt good contributors while bad contributors ignore the restrictions. That said, restrictions for non-quality reasons, like copyright concerns, might still make sense.
- IshKebab 7mo agoIt should be the responsibility of the person submitting changes. The problem is AI apparently makes it easy for people to shirk that responsibility.
- qsera 7mo ago> people to shirk that responsibility. Actually not shrink, but just transfer it to reviewers.
- sothatsit 7mo agoTrusted contributors using LLMs do not cause this problem though. It is the larger volume of low-effort contributions causing this problem, and those contributors are the most likely to ignore the policies. Therefore, policies restricting AI-use on the basis of avoiding low-quality contributions are probably hurting more than they’re helping.
- bhekanik 7mo ago[dead]
- wetpaws 7mo ago[dead]
- retired 7mo agoFork it to Slobian and let the clankers go to town creating, approving and merging pull requests by themselves. Look at the install base to see what people prefer.
- zadikian 7mo agoWas going to say, I'm interested to see if someone can build a nicer Linux distro going full AI spam.
- MintPaw 7mo agoAn 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.
- LelouBil 7mo ago> 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
- pabs3 7mo agoThe LWN comments say that you are correct for local AIs (but not LLM services), modulo some caveats about compiler flags and hardware used.
- aplomb1026 7mo ago[flagged]
- 1vuio0pswjnm7 7mo agoA title that might make Geddy Lee proud
- veunes 7mo agoThe 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.
- layer8 7mo agoBad 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.
- a96 7mo agoBut bad human submissions are expensive to send and expensive to receive. LLM submissions are cheap to send and expensive to receive. This creates a spam (slop) problem, just like in other contexts.
- ray023 7mo agoThe website is absolutely atrocious, dark mode has pitch-black background with bold 100% white glowing text in foreground, shitty font, way to wide text. Seriously how is lwn.net even still so popular with such an atrocious unreadable ugly website. Well yes I get the irony of asking that on HN (I use an extension to make it better).
- LtWorf 7mo agoThey 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.
- Yhippa 7mo agoThis reminds me of the Hacktoberfest situation where maintainers were getting flooded with low-quality PRs. This could be that, but on steroids and constantly, not just one month.
- MeteorMarc 7mo agoDid 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?
- arjie 7mo agoIn 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.
- LtWorf 7mo agoThis 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.
- jaredcwhite 7mo agoLLM-generated code is incompatible with libre software. It's extremely frustrating to see such a lack of conviction to argue this point forcefully and repeatedly. It's certainly bad enough to see such a widespread embrace of this dangerous and anti-libre technology within proprietary software teams, but when it comes to FLOSS, it should be a no-brainer to formalize an emphatic anti-slop contributor policy.
- pessimizer 7mo ago> 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.
- jaredcwhite 7mo agoSpoken like a true LLM!
- Dylan16807 7mo agoWhat you think is obvious is not obvious. Please make your argument instead of insulting people. I could guess at arguments but the ones that come to mind are pretty weak. For copyrightability, if half the lines in a FLOSS project are public domain, the license will still be effective. For infringement when training, that's not really the user's problem. For LLMs being proprietary, that doesn't infect the output, also many LLMs are not proprietary. For danger, there's not a lot of that specifically in the code-making context, and I don't see how danger makes something anti-FLOSS either.
- shevy-java 7mo agoSoon we can call it debslop!
- tonymet 7mo agoGiven the 10x+ productivity rate, it would be reasonable to establish a higher quality acceptance bar for AI submissions. 50-100% more performance, correctness, usability testing , and one round of human review. If a change used to take a day or two, and now requires a few minutes, then it's fair to ask for a couple hours more prompting to add the additional tangible tests to compensate for any risks of hallucinations or low quality code sneaking in
- kruffalon 7mo agoThe discussion in question starts here: https://lists.debian.org/debian-vote/2026/02/msg00000.html https://lists.debian.org/debian-vote/2026/02/msg00000.html What a banger sub-thread: https://lists.debian.org/debian-vote/2026/02/msg00020.html https://lists.debian.org/debian-vote/2026/02/msg00020.html
- pessimizer 7mo agoI don't understand a lot of the anti-LLM venom within this specific context. Debian doesn't have to worry about stealing GPL code, so the copyright argument is nearly nil. There's still the matter of attribution-ware, but Debian includes tons of attribution and I'm sure would happily include anyone who thinks their OSS might have been trained on. So leaving that aside, it just seems to be the revulsion that programmers feel towards a lot of LLM slop and the aggravation of getting a lot of slop submissions? Something that seems to be universal in the FOSS social environment, but also seems to be indicative of a boundary issue for me: The fact that machines have started to write reasonable code doesn't mean that you don't have any responsibility to read or review it before you hand it to someone. You could always write shit code and submit it without debugging it or refactoring it sanely, etc. Projects have always had to deal with this, and I suspect they've dealt with this through limiting the people they talk to to their friends, putting arbitrary barriers in front of people who want to contribute, and just being bitchy. While they were doing this, non-corporate FOSS was stagnating and dying because 1) no one would put up with that without being paid, and/or 2) money could buy your way past barriers and bitchiness. Projects need to groom contributors, not simply pre-filter contributions by identity in order to cut down on their workload. There has to be an onboarding process, and that onboarding process has to include banning and condemning people that give you unreviewed slop, and spreading their names and accounts to other projects that could be targeted. Zero tolerance for people who send you something to read that they didn't bother to read. If somebody is getting AI to work for them, then trust grows in that person, and their contributions should be valued. I think the AI part is a distraction. AI is better for Debian that almost anyone else, because Debian is copyleft and avoids the problems that copyleft poses for other software. The problem is that people working within Free Software need some sort of structured social/code interaction where there are reputations to be gained and lost that aren't isolated to single interactions over pull requests, or trying to figure out how and where to submit patches. Where all of the information is in one place about how to contribute, and also about who is contributing. Priority needs to be placed on making all of this stuff clear. Debian is a massive enough project, basically all-encompassing, where it could actually set up something like this for itself and the rest of FOSS could attach itself later. Why doesn't Debian have a "github" that mirrors all of the software it distributes? Aren't they the perfect place? One of the only good, functional examples of online government? edit: There's no reason that Debian shouldn't be giving attribution to every online FOSS project that could possibly be run on Linux (it will be run on Debian, and hopefully distributed through apt-get.) Maybe a Debian contributor slash FOSS-in-general social network is the way to do that? Isn't debian.org almost that already?
- gorgoiler 7mo agoDoes Debian have a rule that forbids (or a taboo that proscribes) contributors passing off other people’s work as their own? I could believe that such a rule is implied rather than written down. The GR could be about writing it down, and it would surely cover the case of code that came directly from a model. Even if we don’t consider a model to be another person it is certainly not the contributor’s own work. (If anything, the copyright to model-generated code cannot possibly be said to belong to the human contributor. They… didn’t write it! I’m glad to see that aspect was discussed though I’m surprised it wasn’t the main thrust.)
- layer8 7mo ago> 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.
- itigges22 7mo ago[flagged]
- jillesvangurp 7mo agoGood decision. The two extremes of this decision are both bad. On one hand the status quo of a lot of slop demanding attention from busy people is just not sustainable and something has to change. But throwing out the baby with the bath water by just blanket banning all forms of AI contributions is not a long term sustainable solution. It's a stop gap solution at best. And one that would be challenged more and more as inevitably tools keep on getting better and more widely used. It's not going to take years even. Deciding to not decide right now gives people some time to think and reflect. The right way might be to fight AI slop with AI enforced guard rails. It's not actually that hard to implement technically. You can literally just put some markdown skills in your repository and periodically have an AI bot apply the review PR skill to incoming PRs to pre-screen them and automatically close PRs that obviously fall short of well documented criteria, and label & prioritize remaining ones. Open claw might be a bridge too far for some at this point but it's maybe a glimpse of a future where we have AI bots filtering, screening and funneling inbound information. If you are a bit handy, you can just unleash codex or code claude on your issue tracker and pull requests right now. Worth experimenting with at a small scale. Criteria could include doing a quick code review. Is the code appropriate and minimal? Does it meet all the documented criteria? Does it fix something that is worth fixing? Does it need further review? AIs can do all sorts of things with PRs ranging from commenting to closing the PR, prioritizing it, commenting on them, or flagging it for escalation to the right person in the team. By the time a real person chooses to spend time on a PR it should have already passed a lot of quality gates and be in a decent enough shape. A second innovation here could be doing more with reputation. Github users build up reputation by virtue of all the contributions they make over time to all sorts of projects. Also, git allows people to sign their commits. That allows AI gate keepers to sort incoming contributions by reputation. Maybe be lenient towards known repeat contributors. Give the benefit of the doubt to new contributors but scrutinize them more and be very strict on everybody else by default. In a meritocracy, you build reputation by consistently doing good work. Dumping a lot of AI slop on somebody's desk would be the opposite. Just some thoughts. I have a few smaller github projects but I'm so far not burdened by a lot of low quality PRs.
- xiphias2 7mo ago> 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.
- rcleveng 7mo agoI'd love to see the policy on review tools to start with, I know even people who are skeptical of getting "AI Slop" thrown at them by agents at a high rate, getting code reviews from some of the SOTA models definitely can be helpful. Google found that with Jules years ago at this point, same for other automated tools. When I first saw the headline though, it sounded like someone was listening to one of my favorite Rush songs. """ If you choose not to decide You still have made a choice You can choose from phantom fears And kindness that can kill I will choose a path that’s clear I will choose free will. """
- kvakvs 7mo agoTreat this as person's own contribution. If the quality is bad, means the person has allowed it, or the person's quality of work is bad, and it doesn't matter whether they produced it or AI did. So in both cases they'd deserve a rejection of their PR. The only downside is that it takes away precious reviewer energy and time.
- kristopolous 7mo agoDebian's priority is not to upset people who have put the work in on the project. Basically "let's not screw anyone" It's a good policy
- chrsw 7mo agoI think all machine generated content should be labeled as such. And if a maintainer or a consumer or whoever doesn't want to accept it, so be it. But people should at least have the choice.
- giancarlostoro 7mo agoI think the reality is going to be if you are just like "YOLO HERES THE CODE FIX" vs "Hey, I used AI, BUT I did everything I possibly could to validate the change" the latter is more acceptable.
- observationist 7mo agoIf it works, it's not wrong. Wasting any time or energy on determining whether or not the source is AI is stupid. If all the requirements are met, in terms of style guide, documentation, functionality, thorough testing and correctness, then it's good. Doesn't matter if AI wrote it, or if it's artisanal hand-crafted bytecode lovingly prepared by a native of Computronistan. The trick is to define what works - set the bar high enough that you're driving away raw human contributors, annoying high value humans, or arbitrarily barring AI users out of dogma or politics or whatever. A hierarchy of maintainers, with people willing to volunteer to sift through submissions, each handing up a much reduced list to the next level, is probably where big projects will have to go. At some point it won't matter; while it does, look for enthusiastic volunteers and make good, sensible, functional rules that get the best results.
- deleted 7mo ago[deleted]
- PinkMilkshake 7mo agoI don't particularly care if vibe coding and the like are used for web apps and mobile apps. The quality there has always been poor and gets worse over time. AI slopware is just the new low and in a few years time I'm sure they will find a way to make things even worse. But for software infrastructure; Kernels, operating systems, compilers, browsers, etc, it is crazy we are even considering AI at it's current ability. If we are going to do that, we need to switch to Ada/SPARK or some other type of formally verifiable system. Maybe I'm overreacting, but all I want to do right now is escape. It horrifies me to think that one day I may be driving a car with a braking system vibe coded in C++.
- isodev 7mo agoI 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.).
- citizenpaul 7mo agoi 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.
- LtWorf 7mo agoIf it can comfort you, on the mailing list the main developer for ext4 is in favour of using AI
- himata4113 7mo agoI think the problem is that AI can generate 1-2k lines of junk and dress it up in a PR. But take it as someone who regulary maxes two x20 accounts: Once you get a workflow going especially cases when you want to satisfy a fixed amount of tests there is no going back. The days of AI hardcoding things to past tests are going to be behind us as they gain the ability to generalize not just in their knowledge but problem solving instead, especially if you know how to hit AI where it hurts. This is where it becomes relevant: upstreaming hardware support, if someone wants to add / fix a bug and they successfully test it and it works there has to be some kind of middle ground where the PR should be justified and worth the effort of a review, but the person submitting the PR possibly has no idea about what they're talking about and just has to trust AI. I do not have an answer to that except for limiting the size and scope of such PRs. Possibly require previous work being acknoledged (hand made) rather than AI generated to validate that you at least know what the PR is about and what it does.
- PeterStuer 7mo agoIn 2025 it might have still been a discussion, but at this point, projects refusing any ai use for contributions or either just virtue signaling and willingly turning a blind eye, or have just chosen to silent quit. It is over. Everyone is using AI (sure, you are the exception. For now).
- project2501a 7mo agoSure, but does that mean we should accept Peter Theil's gospel in unquestioned?
- lemma_peculiar 7mo agoFocusing only on code quality in AI contributions misses the bigger question: does the contribution actually improve the project?
- amelius 7mo agoThat's ok but imho they should work on AI from the user's point of view. At this moment it is impossible to "apt-get install" most of the new AI stuff, and get it working with the GPU.
- inder1 7mo agodebian's stance actually makes more sense than a ban. you can't detect the origin of a contribution reliably. what you can do is hold the contributor accountable for what they submit. the problem is when people use that accountability structure without the skill to back it up. the asymmetric warfare framing in the comments is right: the cost to submit low-quality PRs is near zero now. but the cost to review them didn't change. the maintainer burden goes up, not down. that's the pattern worth paying attention to: AI compresses the cost of producing output, but the responsibility for output quality doesn't compress with it.