It is Monday morning and there are sixty-one pull requests open. Eleven are from people. The rest were opened over the weekend by agents working through a backlog of small, sensible tickets: a dependency bump here, a null check there, a test that had been skipped since March.
Every one of them needs an approving review before it can merge, because that is the rule and the rule is a good one. There are four engineers on the team, and they also have their own work.
Nothing about this situation is a security incident. There is no attacker and no vulnerability. It is arithmetic, and by Friday the arithmetic will have quietly resolved itself in the only way it can.
Ask a team how they keep AI-written code safe and you will usually get the same answer within about ten seconds. A human reviews it before it ships.
It is a good answer. It is the right control in the right place. It is also, in a lot of organisations, no longer true in the way the speaker believes it is.
Not because anybody is lying, and not because reviewers are lazy. Because the volume changed and the process did not, and the resulting failure is completely invisible from the inside.
What changed
Review capacity is roughly fixed. A senior engineer can properly review some number of changes per week, and that number is set by attention, not by tooling. It was the same number three years ago.
What is not fixed is production. An agent does not get bored on the fourth refactor of the afternoon. It does not lose momentum before a holiday. The rate at which change arrives at the review queue has gone up substantially, and the rate at which it can be absorbed has not moved at all.
When arrival exceeds capacity in any queue, one of two things happens. Either the queue grows without limit, or service time falls to meet demand. Review queues do the second one, because the pressure to ship is immediate and the cost of a shallow review is deferred and unattributable.
Why this one is hard to see
Most control failures announce themselves. A backup that does not run produces an error. An expired certificate produces an outage. This one produces a healthy-looking metric, which is the worst possible property for a failing control to have.
It also resists the obvious fix. Telling people to review more carefully does not work, because they are not choosing to be careless. They are absorbing a queue. Adding reviewers helps briefly and then the same arithmetic reasserts itself, because agent output scales with licences and reviewers scale with hiring.
A control that depends on human attention has a throughput, and you can exceed it without anybody noticing that you have.
What it feels like from inside
The people doing the reviewing are usually the first to know, and the last to be asked. It is worth listening to how they describe it, because the language is consistent across very different organisations.
They talk about skimming for shape rather than reading for correctness. Looking at the file paths and the size of the change instead of the logic. Trusting a change because the tests passed, which tests are not designed to justify. Approving something at the end of the day on the basis that it can be reverted, which is true right up until it is not.
None of that is negligence. Every one of those is a rational strategy for clearing a queue that cannot be cleared properly. Given the same queue, you would do the same, and so would I.
This also explains why the problem is so rarely reported upwards. Nobody wants to be the person who says they are not really reading the diffs. The incentive is to keep absorbing until something breaks, at which point it is discussed as a single bad review rather than as a capacity problem that had been visible for months.
What to do instead
The useful move is to stop treating review as one undifferentiated thing. Not all change carries the same risk, and spending equal attention across all of it is what causes the shortfall in the first place.
Separate the reversible from the irreversible
Most changes can be rolled back in minutes and their worst case is an outage you fix. Some cannot: a schema migration that drops a column, a permission grant, anything that deletes or transmits data. These deserve categorically different treatment, and lumping them together with a copy change is how attention gets spent in the wrong place.
Make the risky category small and loud
If everything is flagged, nothing is. The value of a flag is inversely proportional to how often it fires. Define a deliberately narrow set of actions that always require a real human decision, keep it small enough that people still read it on the tenth occurrence, and let the rest through on the ordinary path.
Review the permission, not only the change
A reviewer looking at a diff sees what the change does. They do not see what the agent that produced it was able to do. Two changes that look identical can carry very different risk depending on the credentials in play. Reviewing what an agent may do, once, is far more efficient than inferring it from every diff it produces.
Put controls where attention is not required
The point of an automated control is that it holds when nobody is looking, which is most of the time. Anything that can be expressed as a rule should be a rule, precisely so that scarce human attention lands on the judgement calls a rule cannot make.
An honest measurement
This is measurable, and the measurement is uncomfortable in a useful way.
- Take last month's merged changes. Count them.
- Count the reviewers. Divide.
- For a sample of ten, check the time between the review being opened and approved.
- Ask, for those ten, whether the reviewer could have found a subtle problem in that time.
The last question is the only one that matters, and it is the one people avoid asking out loud. A median review time under two minutes on a change of any size is not a review. It is an acknowledgement, recorded as a review, and it will be presented to an auditor as one.
