Why I'm Closing Your LLM-Generated Pull Requests

Miguel Grinberg is implementing a strict policy against unsolicited, LLM-generated pull requests to avoid the burden of reviewing machine-made code. He now requires contributors to discuss and receive approval for changes via an issue before submitting any code. This move is a direct resistance against the trend of AI 'slop' that threatens the human element of open source development.

Key Points

• The author rejects the role of a 'reverse centaur,' refusing to spend his life reviewing code extruded by machines.
• Unsolicited pull requests are now viewed as red flags because they are often low-effort LLM outputs that ignore project context.
• New contribution guidelines mandate that all changes must be discussed and approved in an issue before a pull request is opened.
• The author prioritizes human involvement and genuine interest over the volume of contributions facilitated by AI.
• The rise of AI-generated code is making the author less interested in sharing new projects as open source.

Sentiment

The overall sentiment is sympathetic to the article's core complaint, with many commenters agreeing that low-effort LLM output creates real review debt and justifies stronger maintainer boundaries. The thread is not a simple anti-AI consensus, because a substantial minority argues for judging contributions by usefulness, context, and transparency rather than suspected provenance. The dominant mood is frustrated and wary, but constructive: most of the discussion converges on contributor responsibility, clear communication, small reviewable changes, and respect for maintainer time.

In Agreement

• Maintainers should not be expected to review pull requests that the submitter has not understood, tested, or framed with clear intent.
• LLMs lower the cost of generating plausible but poor code, which shifts effort from authors to reviewers and breaks the normal social contract of contribution.
• Drive-by AI patches are especially damaging in open source because maintainers are often unpaid and already overloaded.
• AI-assisted authors should use the tool to make work smaller, clearer, and easier to review rather than to produce large unreviewable diffs.
• The issue is not only correctness but maintainability, accountability, scope, and whether a human can stand behind the submitted change.
• Requiring prior discussion or closing low-context submissions is a reasonable boundary for project owners protecting their time.

Opposed

• Contributions should be judged by the quality and usefulness of the code, not by whether the author used AI assistance.
• Automatic rejection of suspected AI work can become gatekeeping and can unfairly punish contributors when AI detection is unreliable.
• AI can help newcomers, non-native English speakers, and people working in legacy systems communicate, refactor, and participate more effectively.
• A pull request can be useful as a prototype or concrete bug report even if the maintainer does not merge the implementation.
• Some commenters see the article as an overreaction rooted in nostalgia for an older open-source culture rather than a practical response to new tooling.
• The more important question is whether a submission reduces ambiguity or adds burden, not whether it was written with an LLM.