Code Review in the Age of AI Agents

Your team just got a colleague who writes 500 lines an hour, never sleeps, never argues, and occasionally invents a package that does not exist. Coding agents that autonomously plan, write, test, and iterate are delivering real throughput - 3-10x on well-scoped tasks - and they have quietly moved the constraint in every engineering organization to the same place: review. I have written about this in depth at TechDebt.guru's agentic coding guide; here is what code review has to become to keep up.

The 10x Output Problem

The math is uncomfortable and unavoidable: if an agent writes 500 lines an hour and a human reviews 100 lines an hour, full review coverage costs five reviewers per agent. Teams respond in one of three ways. They rubber-stamp, and ship code nobody read. They queue, and the agent's speed evaporates into review latency. Or they redesign review itself - which is the only answer that survives contact with reality. The goal is not reviewing less; it is making review effort proportional to risk instead of proportional to line count.

100% Review, Variable Intensity

The standard worth adopting: every line of agent code gets human review, but not every line gets the same review.

• Mechanical changes - renames, migrations, pattern applications - get a pattern-compliance check: does this match the established shape, yes or no.
• Security-touching code, business logic, and new features get full line-by-line review, same as a junior engineer's first month.

The core principle is not negotiable: no agent-written code reaches production without at least one human confirming it belongs there. "Belongs there" is the actual review question now - not "is it syntactically fine" (it usually is) but "should this exist, in this shape, in this codebase."

What Agents Actually Get Wrong

Agent failure modes are not human failure modes, and review checklists built for humans miss them:

• Context amnesia: in long sessions, agents lose architectural decisions made an hour earlier and ship contradictory implementations across phases of the same task.
• Architectural drift: agents solve the immediate problem without internalizing team vision, introducing a second, third, and fourth competing pattern over time.
• The test coverage illusion: AI-written tests tend to verify implementation rather than behavior - coverage numbers look good while actual confidence in the code stays low.
• Dependency hallucination: agents reference packages that do not exist, which is a typo-squatter's dream and a genuine supply chain attack surface.
• Ownership erosion: agent-written modules become code nobody fully owns - legacy on the day it merges.

The Five Guardrails

Constraining agents beats banning them. Five guardrails do most of the work:

1. Agent instruction files. CLAUDE.md and .cursorrules encode architecture, naming, and constraints - the team vision the agent cannot infer.
2. Human review at boundaries. New files, new dependencies, new APIs, and schema changes always gate on a human - boundaries are where drift and hallucination live.
3. Small reviewable units. Maximum diff sizes and incremental commits, enforced. A 3,000-line agent PR is not a PR; it is a liability with a merge button.
4. Agent-specific metrics. Track churn rate, time-to-first-bug, and architectural conformance on agent code - the failure modes are different, so the dashboards must be too.
5. Mandatory understanding. The developer merging agent code must be able to explain it. If they cannot explain it, they should not merge it.

This Is Not Your Old Tech Debt

Traditional technical debt accumulates in places teams learn to expect: the module everyone avoids, the TODO comments aging like unpaid invoices. Agentic debt is structural and architectural, and it compounds faster - because the code volume is higher, the patterns drift silently, and the person who "wrote" it cannot be asked what they were thinking. A human's shortcut is at least consistent with how that human thinks; an agent's shortcuts vary run to run. That is why the answer is not banning agents - the productivity gains are real - but constraining them. Treat agent output the way you treat any high-throughput, low-context contributor: valuable, supervised, and never the architect.

Keep the Humans Growing

The quiet casualty of agent-heavy teams is the junior engineer, who historically learned the codebase by writing its boring parts - exactly the work agents now absorb. If review is where human judgment lives, then review is also where the next generation of judgment gets built. Rotate juniors through agent-code review with a senior alongside; make the mandatory-understanding rule their curriculum. Explaining agent code before merging it is precisely the comprehension exercise that used to come from writing it. Teams that skip this wake up in three years with seniors who can supervise agents and nobody on track to replace them.

Review Differently, Not Just More

The deeper shift: human review time should migrate up the stack. Agents are better than humans at syntax and worse than humans at judgment, so spend human attention where agents are weakest - does this belong in the codebase, does it match the architecture, do the tests assert behavior or just echo the implementation, is every dependency real. A reviewer who spends an hour checking semicolons on agent code is doing the one job the agent already does well, and skipping the five jobs only a human can do.

Start Here

To put this in place this quarter:

1. Write the agent instructions file first - every convention you document is a review comment you stop making.
2. Define your two review intensities and the boundary list that always gets a human.
3. Set a hard diff-size limit for agent PRs and hold it.
4. Add churn and time-to-first-bug for agent code to the dashboard next to your DORA metrics.

Agents changed who writes the code. They did not change who is accountable for it. Review is where your team's judgment gets applied at scale - redesign it deliberately, or the 10x output becomes 10x debt.