Miguel Grinberg Closes the Door on LLM-Generated Pull Requests

Miguel Grinberg, the Python educator behind the Flask Mega-Tutorial and a long list of widely used open source libraries, published a pointed reflection on June 12, 2026, about what LLM-assisted contributions have done to the experience of maintaining open source. The short version: he is changing how he accepts contributions, and the change is restrictive by design.

What changed

Grinberg has been consistent that he does not use LLMs in his own work. A generative AI notice sits at the bottom of his blog stating he uses no LLMs, agents, or other generative tools for writing, coding, or images. That position has not moved. What moved is the volume and character of the contributions arriving at his projects.

The number of pull requests he receives has gone up, and he says nearly all of them are now produced with LLMs. In the pre-LLM era, an unexpected PR meant a stranger had spent real time and effort to improve a shared project. He describes that as a source of excitement and pride. Today the same event reads differently. A typical submission, in his telling, is someone who prompted a code generation tool to bend a project toward their personal need, attached a long machine-written description full of bullet points and emojis, and sent it over without much thought about how the change affects other users.

The cost lands entirely on the maintainer. Someone has to read the diff, work out whether it makes sense, and separate a genuine fix from what Grinberg bluntly calls slop. He frames this through Cory Doctorow's idea of the reverse centaur, a human positioned to serve a machine rather than the other way around, "frail and vulnerable people being puppeteered by uncaring, relentless machines." Grinberg's worry is that reviewing extruded code all day is exactly that role, and he refuses to occupy it.

The new contribution policy

The practical answer is an issue-first workflow, now written into the contribution guidelines across his projects:

If you are interested in contributing a change to this project, please first introduce the change you wish to make to the maintainer in an issue. Pull requests that are submitted without a previous discussion in an issue may be closed at the maintainer's discretion. Once the maintainer accepts your proposed change and allows you to work on it, feel free to submit a pull request.

The logic is straightforward. A conversation in an issue surfaces intent before anyone, maintainer or contributor, sinks time into a diff. Grinberg gets to understand the proposal and the person making it, and only then does code enter the picture. He calls this a win for both sides because it caps the wasted effort on a change that was never going to land.

Unsolicited PRs still arrive, which tells him plenty of submitters, or their tools, never read the guidelines. His triage is fast: his first job on a new PR is to decide whether there is a person behind it. If he sees no proof of human involvement, the PR is closed immediately, no questions asked. He acknowledges this will occasionally cost him a real bug fix, and he accepts that trade. The review labor only felt justified, he says, when every contribution carried a person's effort behind it.

His advice to anyone who can only produce a change with an LLM is to skip the PR entirely. Open an issue, describe the problem in your own voice, plainly, without the generated chapters and bullet lists, and let him do the work. He adds, only half jokingly, that the tokens you save could go toward a donation that might move your issue up his priority list.

Why this matters beyond one maintainer

Grinberg's post is one data point, but it names a pressure that many maintainers are feeling at once. The marginal cost of generating a plausible-looking patch has dropped to near zero, while the cost of reviewing one has not. That asymmetry pushes work onto the maintainer, who is usually an unpaid volunteer, and it scales in the wrong direction. A project that gets more popular now attracts more low-effort automated contributions, not fewer.

The issue-first model is one of a few defenses being tried in practice. Some projects gate contributions behind prior discussion, as Grinberg now does. Others add explicit AI-contribution disclosure rules, and a few have experimented with outright bans on machine-generated patches. Each approach trades openness for the maintainer's time, and there is no settled consensus on where the line belongs.

The deeper question Grinberg raises is whether open source still matters in the way it did. He admits he is sharing less of what he builds, keeping recent projects private rather than publishing them, and he senses a broader decline in interest in coding as a craft. His read is that the thing he loves about programming, the challenge of it, is precisely what many people are now happy to hand to a model. He stops short of predicting where that ends, noting only that he hopes it does not end with machines doing all the coding while humans review the output.

For maintainers reading along, the concrete takeaway is small and adoptable: write down an issue-first policy, state plainly that undiscussed PRs may be closed, and reserve review time for contributions with a person clearly behind them. Whether you share Grinberg's stance on LLMs or not, the workflow protects the scarcest resource a project has, which is the maintainer's attention.

Grinberg's projects and writing remain available through his blog, his GitHub, and his SQLAlchemy 2 In Practice book.