… they were already broken…
LinkedIn is full of engineers who have just discovered that pull requests are impossible to review at the pace AI agents produce code.
Pull requests as a bottleneck. Imagine that.
Now they are searching for new ways of working to solve this brand new problem. New frameworks. New tools. New triage agents. New rituals.
There is nothing new about it.
I keep writing this argument in different shapes , so let me just say it plainly here. AI is an amplifier. It amplifies what you already do. If what you already do is slow and broken, you now have fast and broken. The queue was always there. Slow input was hiding the cost. Speed up the input, and the cost becomes visible overnight.
That is most of the story. Everything below is about why teams keep refusing to see it.
The cost was always there
A batch of work sitting in a review queue for three days at best, two weeks at worst, was never healthy. Some of us have been saying this for almost twenty years. The teams that listened are now watching the AI surge with mild interest. The teams that did not are panicking and reaching for tools.
I want to be careful here, because pull requests are not the villain. They were a perfectly good answer to a different question.
GitHub-style PRs were designed for a specific situation: a contributor I have never met, who does not share my Slack, my standup, or my goal, sends me a patch over the internet. I do not know their intent. I cannot ask them a question and get an answer in the next ten seconds. I need a structured artifact, an audit trail, and a place to write my comments down. The pull request is excellent at all of that. It is one of the most successful pieces of social engineering in the history of software.
The problem is not the tool. The problem is that teams who do share a Slack channel, a standup, and a goal decided to behave like strangers throwing patches over a wall.
Once you operate that way, the dynamics are predictable. The reviewer either skims and stamps, because the queue is full and trust is high, or they go deep and become a martyr, because the queue is full and trust is not high enough. Neither outcome is good engineering. The PR was working as designed; the design was imported into a context where it does not pay rent.
Martin Fowler made this argument long before AI showed up. Pre-integration review has real cost: bigger batches, slower integration, deferred merges, more painful refactors. He cites a client who spent 130,000 hours in 2020 waiting on pull requests that received zero comments. Zero. Not “few”. Zero. The review never happened. The wait did.
Why the new tools cannot fix it
I am not against tooling. I have spent most of my career building it. But the current wave of “AI code review at scale” pieces are largely answers to the wrong question.
Look at where the energy is going. Cloudflare deploys seven specialized reviewer agents per merge request. Anthropic estimates roughly twenty-five dollars per AI review. Vendors compete on agent count, prompt sophistication, and policy coverage. None of this is unreasonable on its own terms.
It is also a remarkable amount of effort spent paving over an architectural choice that was already wrong before AI showed up.
You are not solving a review problem. You are managing a queue you should not have. And the bottleneck moves, it does not vanish. If your humans cannot review fifty PRs a day, you bring in an AI reviewer. The AI reviewer flags fifteen of them as needing human attention. Now your humans are the bottleneck on a smaller batch with less context. Congratulations.
I wrote earlier that the bottleneck moved. This is what that actually looks like in the wild. And if you have read the post on Theory of Constraints , you already know the punchline: improving anything that is not the real constraint produces no real improvement at all. The real constraint here is not review throughput. It is the design choice that put a queue between writing code and integrating it.
The objections are real, and they are not arguments for PRs
When I make this case, four objections come back, every time. They are real. I am not waving them away. They are arguments for designed collaboration , not for shipping work over a wall.
Compliance and four-eyes. The audit requirement is that two pairs of eyes touch the change. Two engineers writing the code together, with commit history showing both authors and CI logs showing the test runs, satisfies that just as cleanly. A signed pair commit is a stronger audit trail than a tired “LGTM” left at 6:47 pm by someone who scrolled to the bottom. (I know which one would hold up better in a postmortem.)
Distributed teams. This deserves nuance. If your team has two or three hours of overlap, pair in that overlap and use the rest for solo deep work. Short-lived branches that integrate daily, plus recorded async pairing, beat a week-long review thread on most measures. If your team has zero overlap, you have a deeper problem PRs cannot fix. The honest answer is to fix the team topology, not to industrialize the queue around an awkward split.
Junior engineers need room to attempt things on their own. They do. I agree. Pairing is not surveillance. Let the junior drive. Let them struggle out loud with someone who can coach in the moment, instead of writing a thousand lines that get rejected in a comment thread three days later. A correction in real time builds independence. A delayed comment on a variable name builds delay.
Audit trails. Already covered, but worth restating: trunk-based development with pair commits and CI logs produces a richer audit trail than a stamped PR. The audit is in the work, not in the wrapper around it.
None of this is anti-PR. It is anti using PRs as a substitute for talking to each other.
What hasn’t changed in twenty years
The advice is not new. That is the entire point.
Pair, mob, ensemble. Whatever you want to call it. Produce code and review it while you produce it. Adopt test-driven development so the code arrives with its own evidence. Integrate continuously into trunk in small steps. Trunk-based development has a perfectly good handbook and has had one for years.
What changes when you do this is not subtle.
AI stops being a queue filler. It becomes a third navigator. The pair points it at the problem, watches what it produces, and accepts or rejects it on the spot. The conversation that used to happen three days late in a PR comment now happens in the moment, while context is fresh, before the tired-eye approval.
Throughput stops being terrifying. Two engineers and an AI agent producing code together can ship a remarkable amount of work in an afternoon, and they have already reviewed it. There is no second shoe to drop. The queue does not exist because the review already happened.
Reviews stop being choke points. They become conversations.
Tests catch what tired eyes cannot. This is the bit that most reliably catches AI drift. If your test suite is real, not the kind that passes by reflex but the kind that actually constrains behavior, then code arriving with passing tests carries real evidence with it. I have written before about verification debt , the gap between what you ship and what you have actually validated. The most reliable way to keep that gap small is to write the test before the code, and to do it together. I have since written about why hand-rolling your schemas, interfaces, and tests matters more than people think , and how the slowness of typing was doing load-bearing QA work nobody invoiced for.
What this would have looked like
Imagine a team that had quietly removed pull requests as the default flow five years ago. Pairs and mobs. Trunk. Continuous integration. TDD. Lots of small commits. Lots of conversation.
That team is having a different 2026 than the rest of us.
For them, AI showed up and slotted in as another voice at the keyboard. Their integration cadence did not change. Their review cadence did not change, because the review was already happening continuously. The volume of work shipped per pair went up; the cost per change did not. They did not need a triage agent. They did not need a review queue dashboard. They did not need a multi-agent orchestration framework with a budget line in next quarter’s planning.
They are not running ahead because they predicted AI. They are running ahead because they took the friction out of integration before there was a tidal wave to absorb.
The teams in trouble are not in trouble because of AI. They are in trouble because they took an old problem, wrapped it in a new label, and built tools to manage the mess the previous tool created.
(I have seen versions of this play out before. Every “new” engineering problem of the past decade had an answer that someone had already written down in 2003. The answer was usually unfashionable.)
A return, not a discovery
I am not trying to be a contrarian about PRs. They are useful in the contexts they were designed for. If you are running an open source project, keep them. If you are accepting external contributions, keep them. If your team is genuinely composed of strangers throwing patches over a wall, well, you have a different problem worth naming, but PRs are still your tool.
For everyone else, AI is doing you a favor. It is making visible a cost you had been quietly absorbing for years. Three-day review latency. Half-read approvals. Review threads that resolve nothing. Refactors deferred because nobody wants to merge a wide diff. None of that started in the last twelve months. AI just turned the volume up until you could no longer ignore it.
The fix is not a new workflow. The fix is the workflow we already knew worked.
It is not a discovery. It is a return.