Your Code Review Process Was Calibrated for Humans

Most engineering leaders I talk to have settled on a comfortable position about autonomous coding agents: they're very fast junior developers. Their diffs flow through the same pull request funnel, hit the same CI pipeline, get the same human approval, and land in the same repo. The gates are author-agnostic. Tighten sandboxing, add a few pre-execution checks, watch the token spend, and the existing system absorbs the new author class without structural change.

The story is tidy, and it's wrong in a way that will cost more than most organizations realize. Code review, quality gates, and accountability norms are not author-agnostic. They were designed, tuned, and staffed around assumptions about human authorship, and those assumptions don't survive contact with an agent running in a loop. The failure isn't loud, either. A working system converts into a rubber stamp while everyone congratulates themselves on how much throughput has gone up.

Here's what actually breaks.

The review SLA assumed human authorship rates

Reviewer-to-author ratios, PR-per-day norms, and the informal "I owe you a review by end of day" culture were all calibrated to human output. A human engineer produces some bounded number of substantive PRs per week, and reviewers were staffed against that rate.

An agent in a loop is not bounded the same way. Point it at a backlog of small refactors and the volume it generates is limited by compute and cost, not by cognition or fatigue. The human review side does not scale to match, because reviewer capacity is fixed by headcount, attention, and the cognitive cost of context-switching between unrelated diffs.

What happens next is predictable, and it isn't a character flaw. Review quality degrades under load. The first several diffs get real scrutiny, the later ones get skimmed, and by the end of a heavy day LGTM has become a coping mechanism. The gate is still there on paper. It has converted to a rubber stamp.

If you are measuring agent ROI in merged PRs per week without also measuring the review depth those merges received, you are measuring the wrong thing. You moved the bottleneck rather than eliminating it, and its new location happens to be the place where quality was previously enforced.

Quality gates were built to catch human error modes

Linters, type checkers, and test suites are a fossil record of the mistakes humans make. Off-by-one errors. Unhandled nulls. Typos in variable names. Forgotten edge cases. The gate catalog reflects decades of pattern-matching on the residue of human cognition.

Agents fail differently. They produce plausible-looking code that uses an API incorrectly in a way the type system accepts. They import dependencies that don't exist. They expand the scope of a task well beyond what was requested. They back out of dead ends badly, leaving partial changes that pass tests but do the wrong thing. These are recurring failure modes in current agent behavior, not edge cases.

None of that shows up in a linter. Type checkers don't flag "this is technically valid but the agent misunderstood the ticket." Test suites written by humans catch the things humans worry about. And if the agent writes its own tests — a common suggestion — you have asked the author to grade its own paper.

There's a reason purpose-built agent-verification tooling is starting to appear: snapshot testing of agent outputs, pre-execution allow/deny gates, dependency verification. A new gate category is emerging because the existing one was shaped for the wrong error distribution. If your quality gate stack looks exactly like it did two years ago, and a meaningful share of your commits are now agent-authored, you are catching a shrinking share of the actual defects.

Author accountability was a social loop, not a signature

The most misunderstood part of code review is what it's for. Catching bugs is a benefit. The primary function — the thing that makes review worth its cost — is a social feedback loop that shapes future work. A reviewer's comment on Tuesday changes what an engineer writes on Friday. Over months, the team internalizes a shared bar, and that bar is what "engineering culture" actually refers to when the term isn't being used as marketing.

Agents don't participate in that loop the same way. They have no reputation to protect and no persistent memory of last week's review across a new session. You can feed prior feedback back into the context, and fine-tuning and prompt libraries can encode some of it, but that is a different mechanism with a different half-life. The social pressure that produces better future work has no surface to act on.

This changes what code review is for when the author is an agent. It shifts toward being purely a defect-detection gate, which is the least efficient possible use of senior engineering time, and the compounding cultural benefit that partly justified the cost stops accruing. If you keep spending the same reviewer hours per diff without acknowledging that, you are subsidizing a mechanism whose main return has changed.

The audit trail assumed a coherent author with intent

Git blame, incident postmortems, and compliance frameworks like SOX and SOC 2 all rest on the same implicit assumption: you can find the author of a change and ask them why they made it. The audit trail is a pointer to a human who, in principle, remembers their reasoning and can be held to account for it.

An agent trajectory is not that. It's a sequence of tool calls, context windows, retrieved documents, and mid-run decisions. There is no single "why." Ask an agent weeks later why it chose a particular library and you will get a plausible narrative that may or may not correspond to what happened in the run.

For internal engineering this is inconvenient. For regulated environments it's a structural problem worth getting ahead of. Compliance frameworks were written for a world where accountability terminates in a named human with intent. Auditors have not yet standardized on how they want agent-authored changes evidenced, and the answer will vary by framework and industry. Most organizations haven't hit that boundary yet. Some will, and the ones that captured agent trajectories, tool calls, and context state in a defensible form will have a much easier conversation than the ones that didn't.

Blast radius controls were sized for a human's mistake rate

A developer who runs a destructive command in the wrong directory does it once and stops. Their hands leave the keyboard. They call a colleague. The blast radius is bounded by the rate at which a human can make mistakes before noticing.

An agent in a loop has no such bound. It can execute the same destructive action many times in quick succession, and it can walk through a permission surface that was sized assuming any given actor would only touch a small fraction of it before someone noticed something was off.

Every containment primitive in a typical development environment — filesystem permissions, network egress rules, secret scoping, resource limits — was implicitly sized for the human mistake rate. When large AI labs write publicly about securing internal systems against capable, imperfectly aligned agents, they are acknowledging this in institutional language. Agent infrastructure is a new surface, and the defensive posture in most organizations was designed for a different threat model.

The counterarguments, and what they get right

There are honest counterarguments here, and they deserve engagement.

The first is that agents are still limited on the hard parts. They handle the engineering, not the architecture, and humans still own the decisions where accountability matters most. That's partially true today. How long it stays true is uncertain, but planning as if it will stay true indefinitely is a bet against the trajectory of the tooling, and I wouldn't make that bet.

The second is that the tooling ecosystem is adapting — purpose-built agent gates are shipping. This is real, and it's why I'm not arguing for a moratorium. I'm arguing that adopting agents without adopting the corresponding new gate category is the actual mistake. The old gates and the new gates catch different things. They are not substitutes.

The third is that human review was already broken: LGTM culture, rubber-stamping, and gate fatigue all predate agents. This is the argument I have the most sympathy for. Agents do expose pre-existing rot. But "the gate was already weak" is not an argument for loading a multiple of the volume onto it. It's an argument for fixing it first.

The fourth is that accountability can be re-anchored to the operator: whoever dispatches the agent and clicks merge is the author for all legal and organizational purposes. I think this is where most organizations will end up, and it's defensible. But it requires an actual policy decision, communicated clearly, with the operator understanding what they're signing up for. Most organizations haven't made that decision. They've drifted into it, which means the operator often doesn't realize they're the accountable party until something goes wrong.

What I would actually do

If I were re-calibrating an engineering organization for meaningful agent authorship over the next year, this is the sequence.

Re-cost review capacity against agent throughput. Before scaling agent usage, calculate the reviewer hours per merged PR you currently spend and the depth of review that buys. If agent PR volume rises significantly, then either reviewer capacity goes up, review depth goes down, or the scope of what agents are allowed to author narrows. One of those three will happen. The only question is whether you choose it or drift into it.

Separate the two functions review was doing. Defect detection and cultural feedback are different products. For agent-authored code, invest in automated defect detection sized for agent-shaped failures: semantic checks, dependency verification, scope-drift detection, behavioral snapshot tests. Reserve human review time for the changes where architectural judgment is at stake, and stop pretending the two are the same activity.

Name the accountable operator, in writing. For every agent deployment, one human is the author of record for compliance, incident response, and organizational purposes, and they understand this before they dispatch the agent. This is a policy question rather than a tooling question, and it belongs at the CTO level.

Build the audit trail you will plausibly need at your next external audit, not the one that satisfies today's. Capture agent trajectories, tool calls, and context state in a form that is defensible to an auditor who asks why a change was made. The tooling to do this is emerging, and the organizations that adopt it before it's required will have an easier conversation than those that wait.

Size sandboxes for loop rates, not human rates. If an agent in a bad state can execute a destructive action many times before a human notices, the sandbox is undersized. Resource limits, egress controls, and kill switches need to assume the actor is faster than the human oversight loop.

None of this is exotic. It's the same pattern that shows up every time a new class of actor enters a system that was calibrated for something else. The organizations that treat agents as a new author class and re-calibrate deliberately will get the throughput gains without eroding the gates. The organizations that treat them as fast juniors will get the throughput number on the dashboard and discover, one incident at a time, what they gave up to get it.

The execution gap on agentic coding is not in whether the agents can write the code. They increasingly can. It's in whether the review, quality, and accountability systems around them still do the job they were built to do. In most organizations right now they don't, and nobody has had a reason to check.