Scrubby for Open Source Maintainers

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.

The asymmetry problem

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. The cost of review is roughly the same as it always was, while the cost of contribution has dropped to nearly zero. The math doesn't work for maintainers anymore.

Why generic AI reviewers don't fix this

There's a tempting answer: just point an AI reviewer at every incoming PR and let it do the first pass. Tools like CodeRabbit help. But they have the same blind spot 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.

That's the class of problem that's actually killing maintainers. A typical example reads something like "this code runs, but it's three abstraction layers deep into a part of the project where you've been actively trying to reduce abstraction, and merging it is going to set you back six months of refactoring."

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 — your patterns, not 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 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 — a missing co-change, 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.

Free for open source

What it doesn't do

Scrubby is not going to replace your judgment on the architectural direction of your project. It's not going to tell you whether a feature should exist. It's not going to make the decision about whether a contributor's design is the right one. That's still on you, and that's still where the real work of maintainership lives.

What Scrubby does is take the mechanical part of review off your plate. The "is this in the right place" and "did they update the test" questions get answered automatically, so the human review you do is concentrated on the parts that actually need human judgment.

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 — defenses that match the speed of AI generation with the speed of context-aware review.

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.