Let me open with a confession, because I think a lot of people are living this one and not saying it out loud.

I've been merging other people's code since Subversion was the exciting new thing on the block. And right now my team produces roughly three times the code it produced eighteen months ago, and yet our main branch is absolutely not moving three times faster. Some weeks, if I'm being honest with myself, I'm not even convinced it's moving faster at all.

For a good while there I just assumed we were doing it wrong. That there was some trick we'd missed. Then the industry data started rolling in, and it turns out we're doing it wrong in the exact same way as everybody else. CircleCI's State of Software Delivery report shows feature-branch throughput up 59% year over year, while main-branch throughput actually FELL. LinearB clocked PRs with agentic-AI involvement waiting 5.3x longer just to get picked up for review. And CodeRabbit's analysis found AI-generated code carrying roughly 1.7x the defect density of the human-written stuff.

Read those three numbers together, sit with them for a second, and the picture is honestly unambiguous. Generation is solved. Verification is not. The agents didn't make your team faster, they just moved the queue. It used to form in front of the keyboard. Now it forms in front of the reviewer.

Why is an agent diff so much harder to review than a human one?

This took me an embarrassingly long time to actually put into words, because line by line, the agent's code is usually fine. Often it's better than fine: consistent naming, defensive error handling, tests already included. The individual lines are genuinely not the problem here.

Here's the real problem. A diff is normally the residue of a conversation. When Dana sends me 400 lines, I already know Dana. I know she fights the ORM every chance she gets, I know exactly what she's been chewing on in standup all week, I know the design doc her change is quietly implementing. So half my "review" is really just pattern-matching against a person whose reasoning I've spent years calibrating myself against. The diff is only the very last mile of a decision trail I already mostly have in my head.

An agent diff, though, arrives with no trail at all. None. The "author" made forty tiny decisions along the way and can articulate exactly zero of them by the time you think to ask, because every one of those decisions got sampled inside a context that has already evaporated. So the reviewer stops reviewing and starts reconstructing. You are reverse-engineering intent out of a raw artifact, which happens to be the single most expensive cognitive activity in all of software engineering. We used to reserve that particular pain for legacy code written by people who'd long since left the company. Now we do it forty times a week, on demand, for code that was written twenty minutes ago.

And THAT is exactly why the LinearB pickup number doesn't surprise me even a little. Reviewers aren't lazy. They're rationally, sensibly avoiding the single most draining item sitting in their queue.

So what did we actually change?

Not a framework, I'll tell you that much up front. Four genuinely boring rules that survived contact with reality, laid out in the order we actually adopted them.

The machines review it before a human ever sees it. Everything mechanical got moved to a gate that runs before a human is even notified there's a PR: lint, types, tests, coverage deltas, dependency and license checks, a security scan, and a first-pass agent review that flags the boring 80% (the dead code, the missing error path, the test that quietly asserts nothing at all). And yes, I hear it, an agent reviewing an agent sounds like the setup to a joke. But it works, for precisely the same reason spellcheck works: it isn't smart, it's tireless, and it clears the noise so that scarce human attention finally lands on the actual decisions instead of the typos. The recursion has to stop somewhere, though, and where it stops is intent. A machine can absolutely verify that the code does what the code says. It cannot verify that the code should EXIST. That judgment is the whole job now, and arguably it's the last truly irreducible part of it.

The prompt ships attached to the PR. Every agent-produced PR now carries, verbatim, right at the top of the description, the exact task it was handed. The diff tells me what changed; the prompt tells me what was meant to change; and the gap between those two things is where every single interesting bug is hiding. Dirt cheap to require. Genuinely embarrassing how long it took me to think of it.

Small diffs, and I mean enforced with actual teeth. We cap the size of agent PRs in a way we somehow never quite managed to cap the human ones (turns out agents don't get offended when you send it back). Over the line, it goes straight back to be split. Review effort is superlinear in diff size, and we've all known this since that ancient IBM-era finding about defect-detection collapsing past a few hundred lines. The one thing that's genuinely changed is that agents make splitting the work nearly free, so there is simply no excuse left.

Review capacity is a budget, and we plan it like one. If a task is going to generate more code than we can actually verify this sprint, then the task does not start. And look, this one produced real arguments internally, because watching a perfectly good agent sit idle offends something deep and primal in the engineering soul. But I'll say it plainly: unreviewed code is not inventory. It's risk with a merge button attached. And that CodeRabbit number says the risk is running 1.7x the old baseline. Generating it early doesn't buy you anything except mounting pressure to review it badly.

And here's the part nobody actually wants to hear

There's a fantasy tucked quietly inside about half the "AI code review" pitches floating around out there: the idea that verification can somehow be automated on the same curve as generation, and that the human eventually just... exits the loop entirely. I don't buy it. And I want you to notice that I'm saying that as someone who builds agent tooling for a living and is therefore financially motivated to buy it.

Generation scales with compute. Verification scales with accountability, and accountability stubbornly, permanently refuses to be delegated. When the outage postmortem finally gets written, "the second agent approved it" is not going to be an acceptable sentence to have in that document, and you know it. Somebody with judgment, with context, with something real to lose, signs off on what enters main. The machines can shrink absolutely everything surrounding that signature (they already do, and they genuinely should). But the signature itself stays.

What HAS changed, and changed for good, is the actual texture of a reviewer's work. Less "does this loop terminate," because the machines have that one handled now. More "should this even exist, does it fit where the system is actually going, what does it quietly make harder for us three months from now." It's architecture review, at line-item granularity, all day long. It is genuinely higher-value work than the old kind. It is also, I'll be straight with you, more tiring per hour, which is a very real cost that shows up plain as day in the burnout numbers, and pretending otherwise is exactly how you lose your best reviewers one by one.

So here's where I land. The teams that win the next couple of years will not be the ones generating the most code. Everybody can generate infinite code now, and that's precisely, exactly why it's worth so little. The winners will be the ones who can VERIFY the most code without burning out the people doing the verifying. The throughput moved. The bottleneck is review. So go invest where the bottleneck actually is. That part of the job hasn't changed one bit since Goldratt wrote it down decades ago, it's just wearing a shiny new queue.