If you maintain an open source project of any meaningful size, the last 18 months have been brutal. The contribution flow that used to be your project’s lifeline has turned into a firehose of PRs that look reasonable, pass tests, and require days of careful review to determine whether they’re actually a good idea.

FastAPI’s creator described this as a DDoS attack on maintainer attention: the asymmetry between how easily a contribution can be generated and how much effort it takes to review it has become extreme. Ghostty has banned unattributed AI contributions outright. 60% of open source maintainers work unpaid, and 44% report burnout.

This is a maintainer-survival problem. Scrubby is one of the more useful asymmetric defenses available, and this post is about why.

The asymmetry problem

Here’s the structure of the problem in plain terms. A drive-by contributor with an AI agent can produce a PR against your project in a few minutes. They don’t need to understand your codebase, and they don’t need to read your contribution guide. They just need a model with enough context to generate code that compiles. You, the maintainer, then have to figure out whether that PR fits your project’s architecture, conventions, and long-term direction. That’s a deeply contextual judgment, and it takes a lot of time.

CodeRabbit’s analysis of 470 open source PRs found AI-authored ones contained roughly 1.7× more issues overall, with logic errors 75% more common and security issues up to 2.74× higher than human-authored equivalents. So even when the PR looks reasonable, the expected value of accepting it is much lower than it used to be.

This asymmetry is what’s burning people out.

Why generic AI reviewers don’t fix this

Of course there’s a tempting answer: just point an AI reviewer at every incoming PR and let it do the first pass. We’re huge fans of CodeRabbit and similar tools, and they certainly help. But they have the same blind spots the contributor’s AI had. They don’t know your project’s conventions, domains, or co-change patterns. So they catch syntax issues and surface bugs while missing the harder class of problem: PRs that fit the language but don’t fit your project.

What Scrubby gives an open source project

Scrubby builds an index of your project that captures the things only long-time maintainers usually know: the architectural domains, how they connect, the conventions in each, and the patterns of how the code actually changes over time. That index then gets applied two ways:

On every PR, the GitHub App reviews the changeset against your project’s actual patterns. These are your team’s specific patterns rather than generic best practices. It flags convention violations, domain boundary crossings, and missing co-changes. The findings appear directly on the PR, with explanations grounded in your project’s history.

To AI agents, through an MCP server. Contributors who use Scrubby-aware agents (which is going to be most contributors, eventually) get codebase context piped into their workflow before they generate code. That means the PRs that do get submitted are more likely to fit on the first try.

The combination of these Scrubby applications is what shifts the asymmetry back in your favor.

What this looks like in practice

Imagine three categories of incoming PR:

  1. The thoughtful, hand-rolled contribution. A contributor read the codebase, understood the design, and wrote something that fits. These have always been your best contributions. Scrubby’s review on these tends to be quiet, often producing nothing at all.

  2. The AI-generated PR from someone who didn’t engage with the project. These are the ones costing you nights and weekends. Scrubby’s review surfaces the structural issues immediately, such as a missing co-change or a convention violation in the domain. You can close it (or ask the contributor to address Scrubby’s findings) without spending an hour figuring out what’s wrong yourself.

  3. The AI-generated PR from someone who used a Scrubby-connected agent. These look like category 1, because the agent had your project’s conventions at write-time. The maintainer review focuses on logic and design rather than structural cleanup.

The first category was always fine. The second is what’s been burning you out. The third is what most contributions will eventually look like, once codebase intelligence becomes a normal part of AI tooling.

The bigger picture

The current state of AI-assisted contribution is unsustainable for maintainers, and everyone in open source knows it. The projects that survive the next few years are going to be the ones with structural defenses against the contribution asymmetry, with defenses that match the speed of AI generation with the speed of context-aware review.

Scrubby is one of those defenses. It’s not the only thing maintainers will need (clear contribution policies and AI-disclosure norms also matter, and actually help Scrubby do it’s job better), but it’s the layer that addresses the cost-of-review problem head-on. If you’re a maintainer who’s seriously considering whether you can keep going at the current pace, Scrubby can help take some of the new review burden off your plate.

You did not sign up to be the human review backbone of every drive-by AI agent on the internet. Codebase intelligence is how you stop being one.

Sources: