There's a take going around that pull requests are dying. Cognition, OpenAI, half of AI Twitter — everyone seems to agree that PRs can't survive the age of coding agents.
I've been reading the research they're citing. The data is real. The conclusion isn't.
The bottleneck is real
Faros AI analyzed 1,255 engineering teams and 10,000+ developers. The numbers are hard to argue with: teams using AI coding tools merged 98% more PRs, but code review time went up 91%. PR size increased 154%. Bug rate went up 9%.
So yes — if your team adopted Copilot or Cursor or Codex and suddenly every engineer is producing twice the output, your reviewers are drowning. That part is true.
But "reviewers are drowning" and "PRs are dying" are very different statements.
What's actually broken
The problem isn't the pull request as a concept. It's that most teams never built their review process to handle variable throughput.
Think about it. Before AI tools, your team probably had an unspoken rhythm — maybe 2-3 PRs per developer per day, each one a few hundred lines. Reviewers could keep up because the input rate was roughly constant. Nobody designed it that way, it just settled into a natural pace.
AI broke that pace. Now one developer can produce 5-8 PRs in a day, some of them 500+ lines. The review process didn't change, so it buckled.
But that's a process problem, not a format problem. You don't throw away email because you got too many of them. You build filters, labels, priorities. Same applies here.
Three things the "PR is dead" crowd gets wrong
1. They assume every team has this problem.
Faros studied high-AI-adoption teams — the ones pushing the hardest on agent-driven development. Most engineering teams in 2026 are not there yet. They're using autocomplete and chat, not autonomous coding agents producing hundreds of lines unsupervised. For them, PRs work fine. The bottleneck doesn't exist.
The "PR is dead" narrative takes a frontier problem and projects it onto the entire industry.
2. They ignore compliance.
In fintech, healthcare, defense, and any industry with SOC 2 / ISO 27001 / HIPAA requirements, human code review isn't optional. It's a regulatory checkbox. You can make it faster, you can augment it with AI, but you can't eliminate it. An AI agent approving another AI agent's code doesn't satisfy an auditor.
Nobody in the "kill the PR" camp mentions this. Probably because most of them work at AI startups where compliance means adding a checkbox to the settings page.
3. They understate the cost of alternatives.
Devin is $500/month per seat. Running a Managed Agent is $0.08/hr plus token costs. OpenAI's Symphony requires Elixir infrastructure and a team that understands agent orchestration. Specification-driven development with BDD requires rewriting your entire planning process.
These aren't free upgrades. For a 5-person startup or a 20-person agency, "just adopt Devin Review and Symphony" is not a realistic answer to "my PRs take too long to review."
What actually works
I've been running an open-source MCP server that handles dropshipping automation — product sourcing, imports, supplier replacement, pushing to Shopify. It generates structured, deterministic output from well-defined tool calls. When my AI agent calls dsers_replace_mapping, the result is a JSON payload with confidence scores, variant matches, and blocking reasons. A reviewer can scan that in 30 seconds.
Compare that to a coding agent that rewrites 400 lines of business logic. The review burden is completely different.
The pattern I keep seeing in teams that don't have a review bottleneck:
Smaller PRs. Not because of policy — because the tools produce focused, scoped changes. MCP tools, well-structured agent tasks, single-responsibility operations. If your agent is producing 500-line PRs, your task decomposition is the problem, not your review process.
Machine-checkable constraints. Architecture rules in linters, type systems, CI checks that catch structural issues before a human ever sees the diff. Can Boluk showed that just changing the editing format improved 15 LLMs by 5-14 percentage points. The right harness reduces review load more than any review tool.
Human review for intent, not syntax. The OpenAI Harness Engineering experiment got this right — engineers review the plan, the spec, the acceptance criteria. The code is validated by machines. But this doesn't mean PRs go away. It means the PR contains a spec + test results + a diff, and the human reviews the first two.
The actual future
PRs will evolve. They'll carry richer metadata — agent confidence scores, test coverage deltas, architectural impact summaries. The diff will become one section of a larger review artifact, not the whole thing.
Some teams will move to trunk-based development with post-merge verification. Some will adopt tiered review where low-risk changes get auto-merged with monitoring. Some will keep traditional PR review because their domain requires it.
What won't happen is a universal replacement. The "after the pull request" framing assumes there's a single successor. There isn't. There's a spectrum of review strategies, and teams will pick based on their risk tolerance, compliance requirements, and team size.
The Kevlin Henney quote keeps getting thrown around — "describing a program in unambiguous detail is programming." It's true, and it's exactly why specification-driven development won't replace code review either. Writing a perfect spec is as hard as writing perfect code. We'll need review at every level of abstraction, just with different tools.
If your review process is drowning, fix your review process. Break PRs into smaller pieces. Add machine checks. Move intent review upstream. But don't throw away the mechanism — it's one of the few things in software engineering that actually works at scale across every team size and industry.
PRs survived waterfall, survived agile, survived microservices. They'll survive AI agents too. They just need better tooling around them, not a funeral.
What's your team's experience — are you actually hitting the review bottleneck, or is this still a theoretical problem for you?
