GitHub shipped something genuinely useful last week: maintainers can now cap how many concurrent open PRs an outside contributor can have at once. AutoGPT called it life-changing. Homebrew said it was the fix they'd been waiting for.
They're right. It's a good feature.
It also solves the intake problem. Not the triage problem. And those are two completely different things.
What just shipped, and why it matters
For open source maintainers dealing with AI-generated PR floods, the new cap is real relief. GitHub's own numbers tell the story: merged pull requests went from 25 million per month in January 2023 to 90 million per month in March 2026 — a 3.6x increase in three years, almost entirely driven by AI-assisted code generation.
One maintainer in the GitHub community discussion put it bluntly:
"1 out of 10 PRs created with AI is legitimate and meets the standards required to open that PR."
So yes — reducing the volume of incoming noise is valuable. If contributors can only have 2 or 3 open PRs at a time, they have to be selective. The junk-to-signal ratio in the queue goes down.
But here's what the PR limit doesn't change: once a PR is open, you still have to figure out which one to look at first.
The problem nobody is talking about
There's a different PR crisis happening in parallel, and it affects teams that aren't drowning in AI slop at all.
Faros AI analyzed teams that adopted AI coding tools and found something uncomfortable: they were generating 98% more pull requests while experiencing a 91% increase in PR review time. The perception gap was 39 points — developers estimated they were 20% faster with AI, while actually performing 19% slower when you measured end-to-end cycle time.
The bottleneck wasn't writing code. It was reviewing it.
And the PR limit does nothing here. If your team of 4 engineers is generating twice as many PRs with Copilot, capping outside contributors to 2 open PRs doesn't help you decide whether to review the 400-line refactor or the 12-line bug fix first.
That decision — which PR to look at right now — is where most developer time actually goes. Silently, invisibly, every single day.
What triage actually looks like without tooling
Here's the honest version of what happens when a developer opens GitHub and sees 23 open PRs across 4 repos:
- They scan titles. Titles are unreliable. "Fix bug in auth module" could be a one-line typo fix or a complete rewrite.
- They open the ones that look familiar or important. This is vibes-based prioritization.
- They get halfway through a complex PR, realize it depends on another PR that's blocked, and context-switch.
- They come back later and start again from the list.
This process takes time not because the developer is inefficient, but because the information needed to make a good prioritization decision is buried inside each PR — and you can't see it without opening it.
The signals that actually matter are almost never visible from the default list view:
- Is CI passing right now, or did it pass when the PR was opened and then fail?
- Has the author been responding to comments in the last 48 hours, or is this effectively abandoned?
- Does this PR touch files that overlap with another open PR — making them dependent even if they don't look it?
- Is the diff size proportional to what the description claims?
None of these require AI to compute. They're deterministic signals. But they're invisible from a flat list.
What it looks like when you surface these signals
This is what a prioritized PR inbox looks like when those signals are made visible before you open anything:
![PR Focus Pro inbox — PRs prioritized by hybrid risk score. Top PR: Risk 87, CI failing, 9 days old. Second PR: Risk 48, CI pending, 4 days old. Each card shows an AI summary of what the PR actually does.]
PR Focus Pro — the first PR (Risk 87) has failing CI and touches auth. It needs attention today. The second (Risk 48) has pending CI and is a cache layer change. It can wait. You knew both of these things before opening either.
The risk score combines:
- CI status at triage time (not just at merge)
- File types touched (auth, config, DB migrations score higher)
- PR age vs. author activity
- Scope-to-size ratio (a 400-line "minor fix" is a flag)
The AI layer adds plain-language summaries — what the PR actually does, independent of its description. But the priority order comes from deterministic signals, not from AI. That distinction matters for reliability: you need to trust your triage tool every single day.
The two-layer problem
What's actually happening in 2026 is a two-layer problem, and GitHub is solving layer one:
Layer 1 — Intake: Too many low-quality PRs entering the queue. GitHub's new limits, configurable permissions, and PR deletion features address this. ✅ Good.
Layer 2 — Triage: Once PRs are in the queue, developers still need to decide what to review first, how much attention each PR deserves, and which ones are likely to waste time even if they look legitimate. ❌ Mostly unsolved.
The reason layer 2 gets less attention is that it's less dramatic. A flood of AI-generated slop from a bot account is visible and infuriating. A developer spending 90 minutes doing implicit mental triage before starting their first real review is invisible — it just looks like "slow" work.
But the cumulative cost is enormous. If 4 developers spend 45 minutes doing mental triage before every review session, that's 3 hours a day of unrecorded productivity loss. Across a week, it's a full developer-day gone.
Where AI actually helps (and where it doesn't)
There's a temptation to throw AI at the triage problem entirely. GitHub is exploring this — their community discussion mentions "potentially leveraging AI to evaluate contributions against project guidelines."
AI is genuinely useful for one specific thing in PR triage: generating a plain-language summary of what a PR actually does, independent of what its description claims. That's valuable context before you open the diff.
Where pure AI triage falls short:
Consistency — if your tool gives a different risk score for the same PR on different days, you stop trusting it. Deterministic signals are reproducible. LLM scores aren't always.
Speed — calling an LLM for every PR in a 20+ queue adds real latency. Deterministic scoring is instant.
Reliability on your specific codebase — LLMs don't have reliable intuition about which files in your repo are critical paths. A config file in one codebase is noise; in another it's the most dangerous thing to touch.
The architecture that works: deterministic signals set the priority order, AI provides context for why. Not the other way around.
GitHub's 2026 roadmap — and the gap
GitHub's current direction covers:
- ✅ Intake controls (PR caps, collaborator restrictions)
- ✅ Moderation (PR deletion, low-quality flags)
- 🔄 AI transparency (attribution for AI-assisted PRs — in exploration)
- ❌ Triage tooling for the PRs that do deserve review
That last one is the gap. It's too workflow-specific and too team-context-dependent for GitHub to solve at the platform level. It has to be solved at the tooling layer — where the signals are accessible via API, the computation is cheap, and the presentation lives in the context where developers already work.
Why this matters now
The PR flood problem gets attention because it's visible. Bots submitting 30 PRs to your repo is dramatic. But the quieter problem — good developers spending significant chunks of their day doing invisible mental triage — is costing engineering teams more in aggregate.
GitHub's new PR limits are a genuinely good first step. They reduce the noise coming in. But they don't help with the queue that already exists, and they don't help teams whose PR volume is growing because their own developers are more productive, not because of external spam.
Layer 1 is getting solved. Layer 2 is still mostly manual, mostly invisible, and mostly expensive.
I've been thinking about this long enough that I built something to solve it: PR Focus Pro uses exactly the hybrid approach described here — deterministic signals for the priority score, optional AI summaries for context, 100% local (BYOK — OpenAI, Groq, Mistral, or Ollama). Freemium, $9.50 one-time for Pro, no subscription. But this piece is about the problem, not the product — the triage gap exists regardless of what tool you use to close it.
Maintaining repos and found other signals that help? I'd genuinely like to hear them — drop a comment or find me on GitHub.
Top comments (4)
PR caps solve the visible queue, not the hidden review cost. The part I would want next is maintainer intent encoded into contribution paths: small docs fixes, bug reproductions, security reports, and feature work should not all enter the same review lane. A limit helps, but triage shape matters more than raw count.
The "contribution paths" framing is exactly right, and it's something
GitHub's current permission model doesn't really capture.
Right now the only meaningful distinction is "collaborator vs. external"
— but a security report and a typo fix from the same external contributor
have completely different review costs and completely different urgency
profiles. Treating them identically at the intake layer means you're
still doing the differentiation manually at triage time.
The signal I've found most useful for this: file types touched. A PR
that only modifies
.mdfiles has a fundamentally different risk andeffort profile than one touching auth middleware — even if both come from
the same contributor with the same commit history. It's a rough proxy for
contribution path, but it's available immediately without any additional
tooling or contributor metadata.
The harder version of what you're describing — maintainer intent encoded
upfront, before the PR is even opened — is where things get interesting.
An "issue-first" requirement with typed issue templates (bug / security /
docs / feature) would give you that shape before review begins. A few
projects are doing this manually; GitHub seems to be moving toward making
it configurable. Would change the triage problem significantly.
Exactly. The intake layer needs to carry shape before a maintainer spends judgment on it. A typo fix, repro case, security report, and feature proposal should not arrive as the same object with the same urgency. Even a few explicit lanes would remove a lot of hidden triage cost.
Exactly — you've put your finger on what I think is the next frontier for code review tooling.
"Carry shape before a maintainer spends judgment on it" — that's the phrase I've been missing. Right now, GitHub treats a typo fix and a security patch identically at the intake layer. The judgment starts after the PR is opened, which is exactly when you want it to be less expensive, not more.
What this looks like in practice:
If a PR arrives tagged as
security(via issue template → PR template), the review lane would:If it's
docsortypo, the lane would:The shape is carried forward from the issue, not inferred at review time.
A concrete signal I've found useful:
In PR Focus Pro, I weight file types touched. A PR that only touches
.mdfiles is treated differently than one touchingauthordb. It's not perfect, but it's available immediately — no extra metadata required.The issue-first approach you're describing would be even better because it captures intent, not just code surface area. Have you seen any project implement this well in practice? I'd be curious to see examples.
Also, small note: I think this is the next logical step for GitHub's roadmap — they've already moved from "PR caps" to "AI transparency"; "typed contribution lanes" feels like the obvious next layer. If they don't build it, maybe the tooling layer will.