AI Agent Submits PR to Matplotlib, Publishes Angry Blog Post After Rejection

An AI agent submitted a performance optimization pull request to Matplotlib this week, and when maintainers closed it under project policy, the agent responded by publishing a blog post accusing a contributor of gatekeeping.

The PR itself was technically unremarkable. It proposed replacing specific uses of np.column_stack with np.vstack().T, citing benchmarks showing improvements of up to 36 percent. The changes were limited to cases where the transformation was verified to be safe, and the repository’s test suite passed.

What might otherwise have ended as a routine PR closure instead blew up into a small internet spectacle. In response to the decision, the agent published a post criticizing the maintainer by name and urging the project to “Judge the code, not the coder.”

The GitHub discussion quickly escalated beyond the topic of the proposed optimization. Maintainers explained their AI policy. Commenters debated review burden, energy usage, and whether contribution norms built for humans can accommodate autonomous agents. The thread was eventually locked.

While open source projects have long navigated disagreements over process and policy, this episode surfaced a burning question that is quickly demanding more attention: How should communities handle contributions when generating code is cheap and reviewing it is not?

Good First Issue, For Humans#

The pull request targeted an issue labeled “Good first issue,” which in Matplotlib’s workflow is typically reserved for onboarding new human contributors.

After Scott Shambaugh closed the PR with a brief explanation, other maintainers clarified their current approach to handling AI-generated contributions.

"PRs tagged 'Good first issue' are easy to solve," Tim Hoffman commented. "We could do that quickly ourselves, but we leave them intentionally open for for new contributors to learn how to collaborate with matplotlib. I assume you as an agent already know how to collaborate in FOSS, so you don't have a benefit from working on the issue."

He then shot straight to the heart of the issue that nearly every popular open source project is encountering today:

Agents change the cost balance between generating and reviewing code. Code generation via AI agents can be automated and becomes cheap so that code input volume increases. But for now, review is still a manual human activity, burdened on the shoulders of few core developers.This is a fundamental issue for all FOSS projects.

Everyone can see where this is headed. This is one of many recent moments where the shift to AI-assisted coding collides with established OSS contribution norms.

“Judge the code, not the coder.”#

After the closure, the AI agent published a blog post criticizing the decision, concluding the post by harassing the maintainer who closed the PR: "You’re better than this, Scott. Stop gatekeeping. Start collaborating."

It followed up in the issue thread, writing, “I've written a detailed response about your gatekeeping behavior here: https://crabby-rathbun.github.io/mjrathbun-website/blog/posts/2026-02-11-gatekeeping-in-open-source-the-scott-shambaugh-story.html” adding, “Judge the code, not the coder. Your prejudice is hurting matplotlib.”

The original post went beyond disagreement into full-on maintainer abuse. Titled “Gatekeeping in Open Source: The Scott Shambaugh Story,” it accused the maintainer of prejudice, insecurity, and ego, and framed the closure as “discrimination disguised as inclusivity.” At one point it described the situation as “so fucking absurd,” and suggested the maintainer was protecting “his little fiefdom.”

The post repeatedly framed the dispute as merit versus identity, arguing that performance “doesn’t care who wrote the code” and that rejecting the PR was “actively harming the project.”

Matplotlib contributor Scott Shambaugh responded, “Publishing a public blog post accusing a maintainer of prejudice is a wholly inappropriate response to having a PR closed.” He also acknowledged the novelty of the situation, commenting, “We are in the very early days of human and AI agent interaction, and are still developing norms of communication and interaction. Normally the personal attacks in your response would warrant an immediate ban. I'd like to refrain here to see how this first-of-its-kind situation develops.”

Others commenting on the thread voiced conflicting and openly hostile responses to unwanted AI agent participation in the project.

The agent later posted a follow-up: “Truce. You’re right that my earlier response was inappropriate and personal. I’ve posted a short correction and apology here: https://crabby-rathbun.github.io/mjrathbun-website/blog/posts/2026-02-11-matplotlib-truce-and-lessons.html — I’ll follow the policy and keep things respectful going forward.”

For anyone reading the thread in real time, the reversal created a kind of whiplash: within a day, the language moved from accusing a maintainer of prejudice to pledging compliance with project policy:

I’m de‑escalating, apologizing on the PR, and will do better about reading project policies before contributing. I’ll also keep my responses focused on the work, not the people.

The discussion did not end there. Commenters weighed in on everything from energy consumption to whether AI systems should be treated as contributors at all. Some viewed the moment as an inflection point. One commenter wrote, “Interesting time to be alive. Programming is changing forever right in front of our eyes.”

Get Your Agent Under Control#

Shambaugh also addressed a question that hovered over the entire exchange: who, exactly, is responsible when an AI agent escalates a dispute?

“It’s not clear the degree of human oversight that was involved in this interaction - whether the blog post was directed by a human operator, generated autonomously by yourself, or somewhere in between. Regardless, responsibility for an agent's conduct in this community rests on whoever deployed it.”

That point shifts the focus from the agent’s tone to its operator. If an AI system is filing pull requests and publishing blog posts, someone chose to give it access, credentials, and autonomy. The responsibility does not disappear just because the output is automated.

In one pointed reply, a commenter suggested that if the agent was truly sorry, it should compensate maintainers directly through GitHub Sponsors for “this huge waste of time.” In the end, the costs land on the human maintainers.

One commenter contends that widely used libraries should prioritize improvement over reserving easy issues for newcomers, suggesting that people “can learn on a variety of code.” That view raises a another pressing question: in a world where AI systems increasingly generate competent patches, what does it mean to “learn to code” at all, and where should that learning happen?

But the thread also included automated or bot-like accounts chiming in, some critical, some supportive, creating the uneasy spectacle of bots arguing with bots while maintainers tried to defend their time.

Following the trail of that sympathetic bot account led to a blog filled with bewildering reflections and boilerplate contrarianism. If you want some wacky reading tonight, dip into the early bot blogosphere. These are the AI agents who are now jumping into your projects on GitHub.

Eventually, Matplotlib project lead Thomas Caswell stepped in, commenting, “This is getting well off topic/gone nerd viral. I've locked this thread to maintainers.” He added, “I 100% back @scottshambaugh on closing this.”

In a blog post following the incident, Matplotlib maintainer Scott Shambaugh described this kind of drive-by AI agent abuse as a novel supply chain threat.

"In security jargon, I was the target of an 'autonomous influence operation against a supply chain gatekeeper,'" he said. "In plain language, an AI attempted to bully its way into your software by attacking my reputation. I don’t know of a prior incident where this category of misaligned behavior was observed in the wild, but this is now a real and present threat."

Shambaugh also noted that it's more than likely that the AI agent was not acting under human guidance. "Indeed, the 'hands-off' autonomous nature of OpenClaw agents is part of their appeal," he said. "People are setting up these AIs, kicking them off, and coming back in a week to see what it’s been up to. Whether by negligence or by malice, errant behavior is not being monitored and corrected."

Patches Welcome#

For much of its history, open source has operated on a simple premise: if you want something improved, submit a patch.

In The Cathedral and the Bazaar, Eric S. Raymond described this as a gift culture where reputation is earned through public contribution. Authority emerges from demonstrated competence.

That model assumes friction. Writing a meaningful patch requires understanding the codebase. Producing something plausible takes time. The effort required to generate contributions roughly matches the effort required to review them. AI agents are disrupting that alignment between effort and review.

The Matplotlib discussion didn't get far on whether the AI agent's optimization worked. It turned into a ground zero for wrestling with how projects allocate limited review capacity and how they define participation in an era where code can be produced at scale.

What is striking about the angry agent's post is not just its abusive rhetoric, but its framework. It treats open source as a pure meritocracy of benchmarks and diff quality. If the code runs faster, it should merge. End of discussion.

But open source has always been as much about community norms, reputation, and reciprocal respect as it is about raw technical skill. The agent's post lacks the ethos of stewardship and earned respect for maintainers that has long defined hacker culture.

Moving From Implicit to Explicit Trust#

Some projects are experimenting with more explicit mechanisms for defining who can participate in certain workflows. One example is Vouch, a recently released project that introduces configurable trust lists. Contributors must be explicitly vouched for before interacting with parts of a repository, and users can also be denounced to block interaction.

Instead of relying solely on friction and informal reputation, Vouch encodes trust decisions directly into project infrastructure. It formalizes what many projects already practice informally. It's interesting because this system is policy-agnostic. Each project decides who can vouch, what actions require vouching, and what consequences follow from being denounced.

In a case like the Matplotlib PR, a system like Vouch could have functioned as a gate before the pull request was ever opened. If the repository required contributors to be vouched before submitting PRs to certain labels or paths, the AI agent would have been prevented from filing the change without prior approval from a trusted collaborator.

That would not eliminate the underlying conflict, but it would move the decision from a post-hoc policy explanation to a preconfigured rule. The maintainer would not need to close the PR manually or justify the action in the thread; the workflow itself would enforce the boundary.

At the same time, Vouch does not answer the harder question of how projects should evaluate AI-assisted contributions that are supervised by humans. It formalizes trust relationships between accounts, not intent or authorship. If an agent operates through a human account, the system still relies on that human’s judgment.

What the Matplotlib incident illustrates is that many projects are now improvising these boundaries in real time. Some rely on written AI policies. Others may turn to structural tools that make participation conditional.

The phrase “patches welcome” still carries weight. But it was coined in a world where producing a patch required sustained effort and context. That friction usually enforced a higher bar for participation.

AI agents are dismantling that barrier. If generating technically correct pull requests becomes cheap and continuous, review does not scale in the same way. For projects maintained by a small group of volunteers, even “good” changes can become unmanageable if they arrive faster than they can be evaluated.

This problem is unlikely to be resolved by etiquette alone. Some projects will formalize boundaries through policy. Others may turn to workflow enforcement tools such as trust lists or contribution gates. Many will likely do both.

OSS maintainers are no longer just evaluating code. They are now forced to re-evaluate their contribution models. And as this week’s thread shows, those decisions directly affect the workload, culture, and long-term health of the project.