GitHub helped open the floodgates to AI-written code with its Copilot. Now it’s considering closing the door, at least in part, for the short term.
GitHub is exploring what already seems like a controversial idea that would allow maintainers of repositories or projects to delete pull requests (PRs) or turn off the ability to receive pull requests as a way to address an influx of low-quality, often AI-generated contributions that many open-source projects are struggling to manage.
Last week, GitHub product manager Camilla Moraes posted a community discussion thread on GitHub seeking feedback on the solutions that it was mulling in order to address the “increasing volume of low-quality contributions” that was creating significant…
GitHub helped open the floodgates to AI-written code with its Copilot. Now it’s considering closing the door, at least in part, for the short term.
GitHub is exploring what already seems like a controversial idea that would allow maintainers of repositories or projects to delete pull requests (PRs) or turn off the ability to receive pull requests as a way to address an influx of low-quality, often AI-generated contributions that many open-source projects are struggling to manage.
Last week, GitHub product manager Camilla Moraes posted a community discussion thread on GitHub seeking feedback on the solutions that it was mulling in order to address the “increasing volume of low-quality contributions” that was creating significant operational challenges for maintainers of open source projects and repositories.
“We’ve been hearing from you that you’re dedicating substantial time to reviewing contributions that do not meet project quality standards for a number of reasons — they fail to follow project guidelines, are frequently abandoned shortly after submission, and are often AI-generated,” Moraes wrote before listing out the solutions being planned.
AI is breaking the trust model of code review
Several users in the discussion thread agreed with Moraes’ principle that AI-generated code was creating challenges for maintainers.
Jiaxiao Zhou, a software engineer on Microsoft’s Azure Container Upstream team and maintainer of Containerd’s Runwasi project and SpinKube, for one, pointed out that AI-generated code was making it unsustainable for maintainers to review line by line for any code that is shipped.
The maintainer lists several reasons, such as a breakdown in the trust model behind code reviews, where reviewers can no longer assume contributors fully understand what they submit; the risk that AI-generated pull requests may appear structurally sound while being logically flawed or unsafe; and the fact that line-by-line reviews remain mandatory for production code but do not scale to large, AI-assisted changes.
To address these challenges in the short term, Moraes wrote that GitHub was planning to provide configurable pull request permissions, meaning the ability to control pull request access at a more granular level by restricting contributions to collaborators only or disabling PRs for specific use cases like mirror repositories.
“This also eliminates the need for custom automations that various open source projects are building to manage contributions,” Moraes wrote.
However, the specific suggestion on disabling PRs was met with skepticism.
A user with the handle ThiefMaster suggested that GitHub should not look at restricting access to previously opened PRs as it may lead to loss of content or access for someone. Rather, the user suggested that GitHub should allow users to access them with a direct link.
Moraes, in response, seemed to align with the user’s view and said that GitHub may include the user’s suggestion.
In addition, GitHub is also mulling the idea of providing maintainers with the ability to remove spam or low-quality PRs directly from the interface to improve repository organization.
This suggestion was met with even more skepticism from users.
While ThiefMaster suggested that GitHub should allow a limited timeframe for a maintainer to delete a PR, most likely due to low activity, other users, such as Tibor Digana, Hayden, and Matthew Gamble, were completely against the idea.
The long-term suggestions from Moraes, which included using AI-based tools to help maintainers weed out “unnecessary” submissions and focus on the worthy ones, too, received considerable flak.
While Moraes and GitHub argue that these AI-based tools would cut down the time required to review submissions, users, such as Stephen Rosen, argue that AI-based tools would do quite the opposite because they are prone to hallucinations, forcing the maintainer to go through each line of code anyways.
AI should reduce noise, not add uncertainty
Paul Chada, co-founder of agentic AI software startup Doozer AI, argued that the usefulness of AI-based review tools will hinge on the strength of the guardrails and filters built into them.
Without those controls, he said, such systems risk flooding maintainers with submissions that lack project context, waste review time, and dilute meaningful signal.
“Maintainers don’t want another system they have to second-guess. AI should act like a spam filter or assistant, not a reviewer with authority. Used carefully, it reduces noise. Used carelessly, it adds a new layer of uncertainty instead of removing one,” Chada said.
GitHub has also made other long-term suggestions to address the cognitive load on reviewers, such as improved visibility and attribution when AI tools are used throughout the PR lifecycle, and more granular controls for determining who can create and review PRs beyond blocking all users or restricting to collaborators only.