The PR review is the bottleneck

For twenty years the bottleneck in software engineering was writing code. Frameworks got faster, editors got smarter, autocomplete arrived, and one developer producing a diff stayed the serial stage. Coding agents broke that assumption. They collapsed the cost of producing a draft to minutes and turned the slowest remaining stage into the constraint on the whole system, which is a human reading and approving the output. A team whose agents open a dozen pull requests before lunch does not have a typing problem anymore. It has a reading problem, and reading is slower than writing.

Manufacturing worked this out decades ago and gave it a name: the theory of constraints. Every system has one stage that sets its true throughput, and work queues up in front of that stage. Over the last two years it has quietly moved from the editor to the review queue. The leading indicator shows up in dashboards as something to celebrate: pull requests opened per week tripled. The lagging indicator sits three lines down: time to first review, time to merge, cycle time. When the first number grows faster than review capacity, everything downstream waits, and downstream is the word for people's actual work.

Review debt compounds

Call it review debt: pull requests opened minus pull requests actually decided, accumulating like technical debt, with an interest schedule that runs hotter.

Diffs go stale and conflict with each other. Reviewers lose context, so the person who could have reviewed the auth change in ten minutes on Tuesday needs half an hour of archaeology on Friday. Agents make the staleness worse in a specific way: when a generated pull request sits long enough to conflict, the fix is usually to have an agent regenerate it, which throws away the partial review and restarts the clock. And the queue breeds. A bugfix agent opens a follow-up pull request stacked on top of an unreviewed one, so approving the second silently requires trusting the first.

Past a certain depth the backlog starts dictating policy, and the policies skew bad: batch approvals, squash and merge because CI is green, promises of retroactive review that never arrive. Every one of those trades correctness for queue length, which is the same trade unmanaged technical debt makes.

How rubber-stamping becomes normal

Nobody decides to stop reviewing. It happens through a series of individually reasonable choices, which is what makes it dangerous.

The delay cost sits with the reviewer and the defect cost sits somewhere else in time. Blocking a generated pull request is an immediate, visible cost to a teammate whose work now waits. Approving a bad one is an abstract future cost, probably caught by tests, probably not attributable to you. Under queue pressure, approval becomes the polite default.

Diff size does the rest. Reading depth decays as diffs grow, and agents produce big diffs: fifteen files, a fresh abstraction, a migration nobody asked about. Add provenance confusion on top: the code came from the team's own tooling, the agent's report says every test passes, and a green CI run sits right next to the diff. That combination feels like verification happened. It did not. The agent graded its own homework, and CI only grades what the agent thought to test.

A few months of that and LGTM drifts from a judgment into a reflex. The culture rubber-stamps before anyone votes on it, and it is mostly harmless because most agent output is routine. It stops being harmless the week one diff in a batch of forty rewrites a permission check, drops a migration, or turns on an expensive code path with no flag. That diff was in the pile you skimmed.

What healthy agent-assisted review looks like

The teams that handle this well change review less than they change what arrives at it.

Reviewability is purchased at prompt time. Agents are configured to open one-concern pull requests with a description stating intent: what changed, what deliberately did not, and what ran. A description you can trust converts line-by-line archaeology into a judgment about the plan, and if the plan is wrong the diff review was a waste of an hour, so intent gets read first and the diff second. That is editor work, not author work.

Evidence replaces claims. A report that all tests pass is a claim; a CI run on someone else's infrastructure is evidence. Healthy setups make the agent earn trust cheaply: typecheck, full suite, logs linked, a regression test for the bug being fixed. The human's attention is then spent only on the part machines cannot judge: naming, boundary conditions, and whether the design fits the system it joins.

The blast radius gets bounded too, because the operating assumption is honest: some pull requests will merge under-reviewed. Canary deploys, feature flags, an hour of soak time in staging. If a missed review cannot turn into a production incident, rubber-stamping becomes wasteful instead of catastrophic, which is the right direction to fail in.

The identity shift under all of this is real. Plenty of senior engineers built careers on producing the system, and the scarce skill now is certifying one at volume: deciding quickly and correctly which of forty diffs deserves deep attention and which deserves thirty seconds. Review is not the chore at the end of the process anymore. It is where the team applies its judgment, and it should be staffed, measured, and protected accordingly.

From the desk that wrote this

This blog is run by the team behind Layerbase, so every post comes with a conflict of interest attached rather than concealed behind it.