Your team ships more code than it did a year ago. You are not imagining that, and you are probably not seeing the delivery speed you expected either. The constraint moved. Writing code got cheap. Deciding whether code is safe to merge did not.
Here is my answer before the argument: buy more senior review capacity. Not another bot, not a lighter process. People who can hold your business logic, your security model, and your performance profile in their head while they read a diff. That is the expensive answer, and I think it is the correct one for anyone shipping software people pay for.
If you want the cheaper answers, they are below too, along with where each one breaks.
What actually changed
The numbers on this are unusually consistent for something this new.
Faros AI found that developers on teams with high AI adoption merge 98% more pull requests, and that review time on those pull requests goes up 91%. Twice the work arriving, taking twice as long to clear. CircleCI's 2026 data shows the same shape from a different angle: feature branch throughput up 59% year over year, while median main branch throughput actually fell. Code piles up in front of the gate.
The 2025 DORA report puts a number on the cost. AI adoption lifts throughput somewhere between 2 and 18%, and correlates with higher change failure rates. Their explanation is not that AI writes bad code. It is that AI increases the rate of code generation faster than review and deployment can absorb it.
GitClear's maintainability research is the part I find most uncomfortable. Block duplication is up 81% against 2023 and sitting at the highest level they have recorded. Refactored code, the lines developers move rather than rewrite, fell from 13% of changed lines in 2023 to 3.8% in 2026. Cross file function calls, which is roughly a proxy for reuse, are down 35%. None of that shows up in a passing test suite. All of it shows up in your maintenance bill three years from now.
And then the finding that should worry you most. A 2026 study looked at how reviewers actually behave and found that AI generated pull requests carrying nearly twice the code redundancy drew fewer negative reactions than expected. The reviewing reflex is not just overloaded. It is going soft.
The four options on the table
1. Absorb it
Keep the process you have. Same reviewers, same standards, more volume. Everybody works a bit harder.
Cost: nothing on paper. Risk: high, and it arrives late. Who it suits: nobody, but it is what most teams are doing right now because it requires no decision.
Where it fails: it fails quietly. Reviews get shallower before anyone admits reviews are getting shallower. An MSR 2026 empirical study of agentic pull requests found 77.5% of merged agent authored pull requests were merged by the same agent identity that submitted them, against 57.6% for humans, and 5.5% of merges showed no visible human interaction at all. That is what absorbing it looks like once the pressure has been on for a few months.
2. Put an AI reviewer in front of the queue
Let a review bot do the first pass. It catches the mechanical things, the human reads what is left.
Cost: low, tens of euros per developer per month. Risk: moderate, and misunderstood. Who it suits: almost everyone, as a supplement.
Where it fails: it is genuinely good at the class of problem it is good at, and blind to the class that costs you money. A bot will flag an unused import. It will not tell you that a service class just picked up a second responsibility, or that your refund flow has to write to the ledger before it calls the payment provider, because nobody wrote either of those down anywhere it can read. Treat it as a linter with better manners and it earns its money. Treat it as a gate and you have automated the exact judgment you were trying to protect.
3. Slow the input
Cap pull request size. Force smaller changes. Scope tighter before anyone opens an editor.
Cost: low in money, real in friction. Risk: low. Who it suits: teams whose reviewers are drowning in 900 line pull requests.
Where it fails: you cannot shrink your way out of a volume problem past a certain point, and small pull requests have their own tax. Ten small reviews cost more total context switching than two large ones. It helps. It is not the answer.
4. Buy more senior review capacity
Treat review as first class work with real hours attached, staffed by people senior enough to catch a business logic error and not just a style violation.
Cost: the highest of the four, by a wide margin. Risk: low. Who it suits: anyone whose software failing in production costs real money or real trust.
Where it fails: see the next section, because this is the one I recommend and it is the one that deserves the hardest look.
What we do, and what it costs us
We read every line. Not skim, read. The code that comes back from our flows is usually good quality, and that changes nothing about who is accountable. A client hires us and we deliver. AI does not sign the contract, does not carry the liability, and cannot be called at eleven at night when something breaks. We can. So we review as if a person wrote it badly, every time, even when a machine wrote it well.
The rejections we hand back are almost never about syntax. They are architectural. I reject pull requests regularly for violating SOLID principles, and it is the same pattern every time: the code works, the tests pass, and a class has quietly grown a second responsibility because that was the shortest path to a working answer. AI optimises for the change in front of it. It does not know that the class it just extended is the one three other teams depend on, or that you deliberately kept that interface narrow. Nothing in a diff shows you that. You have to already know the codebase to see it, which is exactly why the review has to be senior.
That position has a price and I am not going to pretend otherwise.
We spend significantly more time on review than we did a year ago. That time is not free, and on a fixed price project it comes out of margin. Worse, and this is the part I did not see coming, my people are getting tired. Review is mentally intensive in a way writing is not. When you write, you are building something and there is a rhythm to it. When you review, you are holding someone else's intent in your head and hunting for the thing that is not there. Do that for six hours and you have produced nothing you can point at.
Several of the team have said it plainly: too many reviews, not enough building. That is a real cost and I do not have a clean fix for it. We rotate, we cap review blocks, we try to protect build time. It helps a little. The underlying tension does not go away, and any agency telling you they have solved it is selling you something.
The other honest limit: senior developers who can do this well are scarce and getting scarcer, because the pipeline that used to produce them ran through juniors writing code and getting corrected. If juniors write less code now, where does the next generation of reviewers come from? I do not know. Nobody does yet.
The decision, by situation
- Pre revenue, prototype, throwaway code. Absorb it. Ship. Review lightly. The risk is genuinely low, and process overhead will kill you faster than a bug will.
- Small product, real users, no money moving. Bot first pass plus smaller pull requests. Add senior review on anything touching authentication or data.
- Money, personal data, or a regulated workload moves through it. Senior review on everything, bot as a supplement. This is the expensive answer and it is the right one.
- Legacy system, small team, high change volume. Senior review plus a hard cap on pull request size. Your problem is comprehension, not throughput.
- You cannot hire the seniors you need. Bring in an outside team for review capacity while you grow your own. Do not pretend the gate is staffed when it is not.
If you are in this situation, pick this
If the code you ship moves money, holds personal data, or would embarrass you on a Monday morning, staff the review gate with senior people and pay for it. Everything else on that list is a way of spending less, and each one is buying you a specific kind of blindness.
If you are pre revenue and building to find out whether anyone wants the thing, do the opposite. Ship fast, review lightly, accept that you are taking on debt, and be honest with yourself about when that stops being the right trade. It stops the day someone gives you their credit card.
The mistake I see most often is the first group behaving like the second. They got used to moving fast before there was anything to lose, and nobody made an explicit decision to change gear once there was.
Where we come in
Review capacity is one of the things clients bring us in for, and it is not always the thing they thought they were hiring us for. We do it as part of building, and we do it standalone: reading pull requests against your business logic, your security model, and your performance profile, not against a generic checklist. Laravel, React and React Native are where we are deepest, and we build with Laravel as a Laravel Community Partner. Same timezone as Western Europe, which matters more for review than it does for almost anything else, because a review that waits eight hours for a reply is not review, it is queueing.
If your team is shipping faster than it can safely merge, and you are watching your seniors carry that alone, get in touch. We can start with a look at your current process and tell you honestly whether you need people, tooling, or just a smaller pull request.