Getting Hundreds of PRs and No Time to Review Them? Open Source Needs PR Control.

You wake up to forty-seven GitHub notifications. Twelve are dependabot bumps you will merge if CI is green. Nine are drive-by typo fixes from first-time contributors. Six are ambitious refactors that touch half the tree. Four are clearly agent-generated: perfect commit messages, vague descriptions, and diffs that look plausible until you read the call sites. You have two hours before your day job starts. You are not behind because you are careless. You are behind because open source success now ships faster than human review scales.

The question every busy maintainer is already asking

“We get hundreds of PRs — how are we supposed to review them?” That is not laziness talking. It is math. A foundation with three volunteer maintainers cannot give a senior-quality pass to every line when weekly volume rivals a mid-size product team. The old playbook — read every diff, leave thoughtful comments, nurture every contributor — breaks the moment AI coding tools and goodwill floods multiply throughput.

Open source at scale is an enterprise operations problem

When we say open source should use Critique, we do not only mean a solo maintainer on a library with twenty contributors. We mean the foundation running fifty repositories, the package ecosystem every Fortune 500 depends on, and the platform team whose public monorepo sees more agent PRs in a week than some startups see in a quarter. Those orgs are customers — they need shared credits, policy across installations, delivery health, and passports an auditor can read.

That is the same product enterprises buy: Control Board for gate, policy, memory, and delivery; Change Passports per PR; Checkpoint before review spend; multi-model review with evidence contracts. Foundations are not a charity tier of a “real” product. They are often the hardest merge-boundary problem on GitHub.

Why “just use CI” is not enough

Continuous integration tells you whether tests passed. It does not tell you whether a pull request should merge. It does not remember that the same path was flagged last month. It does not block a well-formed PR from an unknown agent that weakens auth middleware. It does not give a foundation board a single artifact that explains why a risky change landed during a release week.

Open source projects especially feel this gap. Trust is asymmetric: you want contributions, but you cannot afford silent regressions in crypto libraries, CLIs developers pipe into shells, or governance contracts other repos depend on. You need merge-boundary governance — the same discipline platform teams call change control — operable at hundreds of PRs per week.

What PR control looks like on a real OSS repo

PR control starts before the expensive part. Critique Checkpoint / Agent Firewall can run in dry-run while you learn your repo’s shape, then warn or block PRs that fail contributor trust, path rules, or dependency-risk heuristics — before a multi-model review panel spends credits. That alone changes the economics of a flood: you stop paying attention to slop that should never have entered the queue.

When a PR deserves review, Critique routes it through scout and specialist lanes — security, tests, architecture — and a lead synthesis model that posts one evidence-backed verdict maintainers can verify. Findings tie to lines and policy, not vibes. Suppressions and incident learnings live in Findings Memory with an audit trail, so “we already decided this false positive” does not disappear into a maintainer’s head.

Each pull request gets a Change Passport: provenance, risk, evidence, policy decisions, and optional Remedy proof if you allow bounded automated repair. For a foundation asked “why did this merge during the incident?” the passport is the answer — not an archaeology project across check runs and Discord threads.

Agent PRs changed the maintainer job description

Coding agents do not just write features. They open pull requests — sometimes many per day — with confident diffs and thin context. A maintainer’s job is no longer “review code.” It is govern what enters the default branch: block the dangerous shape, sample the ambiguous shape, merge the proven shape, and document the decision for the next volunteer who was not in the thread.

That is why we describe Critique as an AI change control platform, not “another AI code review CI tool.” Review is evidence inside control. The product object in v4 is the passport per PR; the operator surface is the Control Board at /dashboard/control — gate, unified policy, memory, delivery, and learnings in one place instead of four forgotten admin URLs.

A practical first month (without scaring contributors)

Week one: install the GitHub App on one repo, run gate in dry-run, and publish a short CONTRIBUTING note that explains what Critique checks do. Week two: enable advisory review on all PRs; tag findings your team agrees are useful. Week three: promote gate to warn on known-bad patterns (generated slop, missing tests on critical paths). Week four: require Critique checks only on default-branch merges for sensitive directories — not on every typo PR.

The goal is not to automate away community. It is to protect maintainer attention for the PRs that need human judgment — design disputes, API promises, breaking changes — by automating the repetitive risk scan and the policy enforcement everyone already wished CI could do.

FAQ