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.

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.

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.

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.

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?

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

What a banger sub-thread: https://lists.debian.org/debian-vote/2026/02/msg00020.html

All in All, just be honest with yourself, and be honest to others on where your skills lie. AI can be a great tool, but it should not replace you.

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.

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

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

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?

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

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.