Your review SLA is making quality worse
A four-hour review target puts a number on the one variable you should let float. There is always a way to hit the clock, it is called approving, and under agentic volume that is exactly what the target buys you.
Almost every engineering organisation I speak to has one, and they are proud of it. All pull requests picked up within four hours. Reviewed same day. Some teams put it on a dashboard with a percentage next to it, green when compliant.
The intent is sound. Review latency blocks people, blocked people context-switch, context-switching is expensive, so put a target on the latency. That reasoning was correct when a reviewer’s realistic options were “review it now” or “review it after lunch”.
My position: under agentic volume the target does active harm, because there is always a way to meet a review deadline and it is called approving. The SLA does not create review capacity. It specifies the cheapest available way to comply, and the cheapest way to comply is not review.
What a target does to a variable you cannot control
A reviewer facing a four-hour clock has three levers. Review faster, which has a floor set by how quickly a human can understand a change. Review less, which means skipping the parts that take longest to understand. Or approve.
Only the last two scale. The first has a hard limit, and that limit is the whole problem.
So as inflow rises, the SLA does not distribute pressure across those levers evenly. It pushes everything onto the two that give. And it pushes silently, because nothing in the system distinguishes a fast approval from a thorough one. The dashboard stays green the entire way down.
That is the classic shape of a metric that specifies its own defeat. The target is on time, quality is unmeasured, so quality is the variable that absorbs the pressure, and the measurement improves as the outcome degrades.
The numbers show it happening already
LinearB’s 2026 benchmarks give the shape of this. Pickup time on agentic pull requests roughly 5.3 times longer. Median review duration up over 400 percent. And pull requests merged with zero review up about 31 percent.
Read the first two together and you get a queue under strain: things wait longer and take longer once picked up. Read the third and you get how the strain resolves. Some fraction of the queue is not being reviewed at all.
Now add Stack Overflow’s 2025 finding that developer trust in AI output fell from around 40 percent to 29 percent. Trust down, scrutiny not up. That gap is not a culture problem. It is people responding rationally to a system that measures whether they responded, not whether they looked.
An SLA in that environment does one thing reliably: it makes the pressure to clear the queue explicit and personal, at exactly the moment when clearing the queue and reviewing the queue have come apart.
Put the limit on admission instead
The fix is not to remove all constraints. Latency does matter, and a team with no expectation at all ends up with changes sitting for a week, which is its own failure.
The fix is to move the constraint from the output side to the input side. Cap the review queue rather than timing its drain.
Concretely: a limit on how many changes can be open awaiting review at once, per team. When the queue is full, nothing new enters. That sounds like it just moves the wait upstream, and it does, which is the point. The wait becomes visible before the change is written rather than invisible after, and visible waiting produces a conversation about priorities instead of a quiet approval.
The second move is to put a time expectation on the author side rather than the reviewer side. How long until a change is reviewable, meaning small enough, described well enough, tied to a criterion. That is a target the author can hit by doing better work, which is the property a good target has and a review clock does not.
The third is to publish queue depth and unread merges as the health metric rather than latency. Depth tells you whether the system is in balance. Latency tells you how quickly people are clicking.
Time SLA on the reviewer
- Compliance always achievable by approving
- Quality is the unmeasured release valve
- Pressure rises exactly when capacity is shortest
- Green dashboard through a failing system
Admission control on the queue
- Compliance requires the queue to actually drain
- Overload surfaces upstream, before work is generated
- Pressure becomes a prioritisation conversation
- Depth and unread merges are visible
What to do if you cannot remove the SLA
Most people reading this cannot simply delete a target that a VP announced last quarter. Two things help without a policy fight.
Exempt by risk, not by size. Changes touching money, identity, data migration or an external contract come off the clock entirely and are explicitly allowed to take days. That is a small carve-out, easy to justify, and it protects the changes where a fast approval is most expensive.
And publish one number next to the compliance percentage: the share of merged changes with no substantive review comment. You do not need permission to compute that, and it reframes the dashboard from a single flattering figure into a pair that have to be read together. A team at 98 percent SLA compliance with half its merges unremarked is telling a very different story than the one number alone tells.
Where this breaks down
Without a clock, review does starve. The strongest objection, and it is not theoretical. Review is everyone’s second priority, and in the absence of an expectation it loses to whatever is first. Teams that removed review targets and put nothing in their place have ended up with worse latency and no better quality. I am arguing for replacing the constraint, not removing it, and the replacement is harder to implement than the thing it replaces.
Queue caps make you unpopular in a way SLAs do not. A cap that blocks new work is visible to product, immediately, and reads as engineering choosing to go slower. That argument gets lost in most organisations. The counter is that the alternative is going equally slowly while pretending otherwise, but it is a harder case to make in a room.
I have no evidence that removing time targets improves quality. I have a mechanism and a set of numbers consistent with it, which is not the same thing. Nobody has published a controlled comparison, and this piece should be read as an argument from how incentives work rather than a finding.
Comment-based measures are gameable too. I have just recommended counting substantive comments, and any metric attached to consequence degrades. Reviewers who need to produce comments will produce comments. That failure is at least noisier and more visible than a silent approval, but I am swapping one imperfect proxy for another and should not pretend otherwise.
And plenty of teams run time SLAs perfectly well. Small teams, high context, changes they all understand, modest volume. If your reviewers are not under queue pressure, none of this applies, and the target is doing exactly what it was designed to do.
The takeaway
A review SLA measures whether someone responded, in a system where responding and reviewing have come apart. It puts a number on the variable with a hard floor, leaves the variable with no floor unmeasured, and the second one absorbs the pressure.
Constrain admission instead. Cap the queue, put the time expectation on making changes reviewable, and publish depth alongside unread merges. The constraint that cannot be satisfied by a click is the only one worth having.
If you take one thing into next week: put your review SLA compliance percentage next to the share of merged changes with no substantive review comment, on the same slide. If the first is high and the second is not low, you already know what your target is buying.