Exploring Solutions to Tackle Low-Quality Contributions on GitHub · community · Discussion #185387

I know this is a pretty ambitious idea and not trivial to implement, but it would be really powerful to have an AI-detection mechanism with a configurable threshold at the repository or organization level. That way, teams could decide what percentage of AI-generated code is acceptable in pull requests.

Another possible approach would be to define a set of rules or prompts and evaluate pull requests against them. PRs that don’t meet those rules could be automatically flagged or potentially even closed.

As of today, I would say that 1 out of 10 PRs created with AI is legitimate and meets the standards required to open that PR. On 28 Jan 2026, at 18:41, Camilla Moraes ***@***.***> wrote:  Another possible approach would be to define a set of rules or prompts and evaluate pull requests against them. PRs that don’t meet those rules could be automatically flagged or potentially even closed. This is definitely something we’re exploring. One idea is to leverage a repository’s CONTRIBUTING.md file as a source of truth for project guidelines and then validate PRs against any defined rules. In regards to AI-generated code, have you seen cases where the code is AI-generated but still high-quality and genuinely solves the problem? Or is it alwaays just something you want to close out immediately? I'm curious because I'm wondering if an AI-detection mechanism would rule out PRs where AI is used constructively, but that's where we'd want to test this thoroughly and understand what sensible thresholds look like. — Reply to this email directly, view it on GitHub<#185387 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABBWEYEKF6WLNDKE376L3GD4JDYFXAVCNFSM6AAAAACS7B7C7OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRTGEZTMMI>. You are receiving this because you commented.Message ID: ***@***.***>

Disable PRs entirely

PLEASE make this better than disabling issues: Imparticular, do not restrict access to previously opened PRs. Fine to hide the UI or even the ability to list them, but let people access them with a direct link. I'd also appreciate if that was done in repos where issues got disabled.

Context: Someone realizing that they no longer want to allow issues (or PRs) should NOT make any existing content disappear for good. Especially in cases where this content is referenced elsewhere and suddenly becomes a dead link...

The ability to delete a PR from the UI

Similar to my suggestion above, this should be limited in time. It's amazing to delete spam PRs. Hacktoberfest-cheating, Indian-Youtube-nonsense, and the likes. But if there is a controversy around a PR, which has happened numerous times before e.g. due to highly unpopular decisions by repo maintainers (Minio comes to my mind), then they should NOT be able to permanently delete at PR just because it's inconvenient or shows their true face.

My suggestion would be to have a (very) limited timeframe to delete a PR. Maybe a week in case of low activity (e.g. a spam PR the maintainers did not see), much less in case of high activity. Having an exception for "quiet" PRs (no meaningful amount of comments) and allowing to delete those for longer would be perfectly fine of course so someone who rarely checks their repo can delete spam even when they notice it late.

PS: Yes, I'm aware that deleting individual comments on PRs and issues is already possible. But that's a hassle compared to being able to nuke the whole thing with two clicks.

Hey! I am from Azure Core Upstream and we have a lot of OSS maintainers who mainly maintain repositories on GitHub. We held an internal session to talk about copilot and there is a discussion on the topic where maintainers feel caught between today’s required review rigor (line-by-line understanding for anything shipped) and a future where agentic / AI-generated code makes that model increasingly unsustainable.

below are some key maintainer's pain points:

1. Review trust model is broken: reviewers can no longer assume authors understand or wrote the code they submit.
2. AI-generated PRs can look structurally “fine” but be logically wrong, unsafe, or interact with systems the reviewer doesn’t fully know.
3. Line-by-line review is still mandatory for shipped code, but does not scale with large AI-assisted or agentic PRs.
4. Maintainers are uncomfortable approving PRs they don’t fully understand, yet AI makes it easy to submit large changes without deep understanding.
5. Increased cognitive load: reviewers must now evaluate both the code and whether the author understands it.
6. Review burden is higher than pre-AI, not lower.

1. I have a problem with the following statement. It is very leftish. The GitHub has no rights to impose such limitations. You have to configure your repo and TTL of a PR:
   limited timeframe to delete a PR. Maybe a week in case of low activity

2. Regarding the next statement, you can delete a PR when you close it. How different is close and delete?
   Next question, why you mentioned low-quality PRs? I hope you do not want to employ AI to determine what low quality means! We, maintainers, have to determine it.
   The ability to delete a PR from the UI - This provides maintainers with the ability to remove spam or low-quality PRs directly from the interface to improve repository organization.

3. Who is an external contributor?
   Example, you mean a situation when XLibre developers are removed from Xorg?
   Restrict PRs to collaborators - This provides more granular access control, allowing contributions exclusively from existing collaborators while blocking external contributors.

4. This would segregate the maintainers and we don't want it. We have flags on the PRs to indicate what to do with them.
   If the AI is leveraged to this job, we have segregated the maintainers again in the Open Source. But the rule is that we are all equal, and this might be a problem if one is notified and the second guy is not. You may not totally trust the AI due to finally the result may change without the second guy or the quality would be bad without his opinion since he does not attend the review.
   Improved triage tools - Potentially leveraging AI to evaluate contributions against project guidelines and standards to identify which contributions maintainers should focus on reviewing.

For the long term horizon: Implement a reviewer LLM that first does an initial scoring of the PRs? Critique is far easier than creation of a correct result. That automated pre-moderation should give the edge needed to handle. Depending on whether you just use rich prompting or fine-tuning, you can even start building an "oracle vox" for your project, which acts as a reasonably informed, reasonably on point virtual representative for the project/organization.