Key takeaways

Volume beats capacity. When an agent closes three tasks per hour and a reviewer closes one, review debt appears: the queue grows, standards slip, and a green CI replaces an actual look at the change.

AI is a strong first-pass skeptic and a weak sole judge. Models catch style issues, obvious defects, missing tests, and local inconsistencies. Architecture, tenancy, irreversible operations, domain correctness, and risk acceptance stay with a human.

After an agent diff, judge intent, boundaries, and evidence — not “pretty code”. Does the change match the task? Did secrets or data leak? Do tests assert the right behavior, or only a happy path the model also wrote?

Process beats hero reviewers. Smaller PRs, mandatory human gates on high-risk paths, AI as an independent critic, and explicit light/deep review rules scale better than “ask a senior to read everything.”

Generation speed without review economics accelerates incidents. Ties to testing, agentic engineering, and AI security decide whether the agent becomes an accelerator or a source of hidden debt.

Why review broke under agent change volume

Classic review assumed a bounded patch from an author, a full read by a reviewer, discussion of trade-offs, and comments. That model worked while write speed and read speed stayed comparable.

Agents broke the balance. Cursor, Copilot, background runners, and CLI agents can touch dozens of files in one loop, add tests “until green,” and open a PR with a confident description. The reviewer no longer gets a small colleague patch — they get a machine-assembled change set faster than a human can reconstruct intent.

Review debt accumulates: unread or skimmed code. Symptoms are familiar: two-minute “LGTM”; comments only about style; merge under sprint pressure; incidents framed as “it passed review and CI.” Debt does not show up in throughput dashboards — it shows up in rollbacks, hotfixes, and loss of trust in the process.

The nuance: the problem is often not that the model writes badly. It often writes acceptably. The problem is that generation throughput grew faster than responsibility throughput. Teams optimized input and left the bottleneck on the exit.

For the mechanics behind inflated diffs, see how AI IDEs work with code — why an agent expands a change set easily, and why a human remains the owner of the merge.

What AI can check — and what humans must still own

Separate the roles explicitly. Otherwise teams either ban AI review (and drown in queue) or trust it for everything (and ship confident, blind merges).

Strengths of the model as a first pass

Models work well where the signal is local and the pattern repeats:

• repository style and conventions;
• obvious defects: null dereferences, dead branches, crude type errors;
• missing imports, dead code, duplication;
• “is there at least some test on the changed path?”;
• mismatch between PR description and file list;
• naming and documentation hints.

That saves human time on noise. It is not proof that the change is safe.

Human ownership zones

Humans must own risk classes where the cost of error exceeds review time:

Architecture and module boundaries. Agents love convenient imports through a neighbor service’s internals, a shared “just in case” utility, and hidden coupling. The reviewer asks: does this respect boundaries or blur them?

Security and threat model. Authorization, permissions, input validation, unsafe deserialization, access-control bypasses. A model can “add a check” that looks right and fails to close the real attack path.

Tenancy and data. Leaking tenant_id, a shared cache without a tenant key, a query without an owner filter — classic agent patches in SaaS. Looks like a small bug; costs like a company-level incident.

Irreversible operations. Database migrations, data deletion, queue schema changes, flags that cannot be rolled back without downtime. “Tests are green” is not enough: you need a rollback plan and a clear risk window.

Domain correctness. Tax formulas, order states, approval rules — knowledge that is not in the model’s generic weights. The agent confidently reconstructs “how it’s usually done”; the business may require otherwise.

Risk acceptance. Merge is a decision, not a button. Someone must be authorized to say: “not like this in production.”

Checklist after an agent diff

A working order for reviewers. You can shorten it for low risk; you cannot skip items on high risk.

1. Intent match

Open the ticket and the PR description before the code. Then ask: does this change solve the stated problem — or a neighboring one the model found “similar”?

Typical failure: task is “fix pagination,” agent also rewrites the cache and renames an API. The diff is large and “nice,” but intent is blurred. Either revert the extras or split into two PRs.

Check exclusions: what the task explicitly did not ask for. Agents tend toward scope creep dressed as “improvements.”

2. Boundary leaks

Watch imports, new dependencies, direct access to foreign tables and internal APIs. Look for:

• bypassing a module’s public contract;
• copy-pasted logic instead of an existing extension point;
• new environment variables without docs and without a secrets store;
• attack-surface growth: new endpoint, new webhook, new MCP tool.

Related context: secure AI development.

3. Tests that assert the right thing

A green CI after an agent is a weak signal. Models often write tests that confirm their own implementation: overly broad mocks, assertions on internals, no negative paths.

The reviewer checks:

• is there a regression test for the original bug;
• are there edge cases and failure paths;
• does the test assert observable behavior rather than internal structure;
• are checks disabled behind “temporary” flags.

The economics of false calm are covered in testing economics and the cost of failure.

4. Secrets, logs, and data leakage

Look for keys, tokens, config dumps in fixtures, logging of request bodies with personal data, prompts and traces shipped to an external service. The agent is not “malicious” — it optimizes debug convenience and often logs too much.

Also: did internal instructions, repo rules, or fragments of other tickets leak into user-facing output or public artifacts?

5. Prompt and data paths in LLM systems

If the change touches RAG, agents, or chat: check context isolation, input filters, and tool execution without authorization. Prompt injection in production is not exotic; see prompt injection in production and AI guardrails.

6. “Looks green” but brittle

Signs of a fragile change package:

• flaky tests, CI reruns “until it passes”;
• tests only on the happy path;
• no up/down migration check;
• codegen changes without checking consumers;
• drive-by dependency updates without changelog risk review.

Redesigning the review process for agents

A checklist without process does not scale. You need systemic redesign.

Smaller volume per pull request

Rule: agents may generate fast, but merges should be small increments. One PR — one testable hypothesis. Migration separate from feature. Refactor separate from behavior. Reviewers keep working memory; rollback stays cheap.

Practice: in agent rules (AGENTS.md, skills) cap file count and forbid “while you’re here, clean the repo.”

Mandatory human gates on high-risk paths

Not everything needs the same depth. Some paths always need a human:

• auth, billing, payments, personal data;
• schema migrations and deletion scripts;
• access policies and multitenancy;
• infrastructure and secrets;
• public APIs with backward compatibility.

Mechanically: CODEOWNERS, required reviewers, a high-risk label, blocked auto-merge.

AI as skeptic, human as final

A useful loop:

1. Author (human or agent) prepares a change package with evidence.
2. An AI reviewer runs as an independent critic with a different prompt and, when possible, a different model: risks, test gaps, mismatch with the task.
3. A human reads the risk summary + critical files and decides on merge.

Antipattern: the same model that wrote the code “reviews” its patch in the same chat. Shared assumptions pass both layers. Independence matters more than cleverness.

Queue and review-debt metrics

Measure more than time-to-merge:

• age of open PRs;
• share of “LGTM with no comments” on high-risk paths;
• rollbacks and hotfixes after agent changes;
• average files per PR.

If generation sped up and these metrics worsened, you bought speed with debt.

Separately, fix the culture of PR descriptions. A template — what changed / how verified / what was not verified / how to roll back — reduces reviewer load more than any “smart” bot. An agent can draft the template; a human must confirm the truth in the “not verified” and “rollback” fields.

See also agentic engineering in 2026 and where code generation ends and engineering begins.

Team playbook: light vs deep review

Teams need an explicit contract. Otherwise every reviewer invents a standard under queue pressure.

When light review is enough

All of the following:

• local change (1–3 files, one module);
• no auth, tenant data, migrations, secrets, or public contracts;
• a targeted behavior test exists;
• the AI skeptic raised no high-severity findings;
• the author is a human who knows the area, or an agent under a strict task template.

Light review: read description and full diff, run the intent/boundaries/tests checklist, merge. The goal is not heroics — it is not spending senior time on low risk.

When deep review is mandatory

Any trigger:

• more than N files or multiple subsystems;
• security-sensitive paths;
• contract, schema, or queue changes;
• agent ran without hard directory bounds;
• tests generated by the same agent without negative cases;
• urgency (“needed yesterday”) — a reason to go deeper, not to rush the merge.

Deep review: critical paths line by line, threat model on the change, assertion quality, rollback plan, second human on high-risk when needed.

Roles

Author owns the package: intent, boundaries, evidence, known gaps. “The agent did it” does not remove responsibility.

AI critic owns first-pass completeness and explicit escalation.

Human reviewer owns the verdict and that dangerous classes were not skipped.

Tech lead / area owner owns light/deep routing rules and CODEOWNERS.

Links to testing, agentic engineering, and security

AI-era review cannot be isolated from neighboring loops.

Testing. If tests are cheap and tell the truth about risk, reviewers can trust green more. If tests are expensive, rare, or confirm the agent’s implementation, review becomes the only defense line and collapses under volume. See testing economics.

Agentic engineering. Review quality starts before the diff: task framing, directory bounds, done criteria, least privilege. A bad task births a patch that cannot be reviewed honestly. See agentic engineering.

Generation vs engineering. Typing speed is not production readiness. Review is where that difference becomes explicit. See where generation ends.

AI security. New surfaces — prompts, tools, RAG, model logs — need the same human gates as classic auth. See secure AI development, prompt injection, guardrails.

Clean code. Agents often write “readable” code while breaking cohesion and abstractions. Classic principles still help reviewers smell trouble — see the Clean Code summary.

Common team mistakes

Treating green CI as review. CI answers “did we break known checks?” Review answers “should we merge this?”

Asking the same model to approve its own patch. No independence — no second opinion.

Reviewing only style. After an agent, style is often already aligned by rules. Real risk sits in boundaries and data.

Banning agents after one incident. Shadow use remains, without rules. Prefer gates and risk routing.

One review SLA for everything. Either the queue kills speed, or high-risk slips through. Split light and deep.

Not requiring an author risk list. Agents do not leave a note on “what was not verified.” A human author must.

Merging a giant refactor “because the agent handled it.” It handled generation, not responsibility for the system.

Confusing patch-acceptance speed with value-delivery speed. Code merged and rolled back a day later is negative velocity. Review that prevented an incident accelerates the product even if it “delayed” one PR.

What to do today

A practical minimum for one to two weeks:

1. Define two review routes in writing: light and deep, with triggers.
2. Add CODEOWNERS / required reviewers for auth, billing, migrations, tenancy.
3. Constrain the agent in rules: max files, no “while you’re here,” mandatory evidence list in the PR description.
4. Add an AI critic as a separate step (different model or prompt), not in the generation chat.
5. Paste the checklist from this article into the PR template (author + reviewer).
6. Measure review debt: PR age, no-comment share on high-risk, rollbacks after agent merges.
7. Run one calibration review of a large agent diff with the whole team.

You do not need a perfect process. You need to close the most expensive error class next week.

FAQ

Further reading

• How Cursor and other IDEs work with code
• Agentic engineering in 2026
• Where code generation ends and engineering begins
• Testing economics and the cost of failure
• AI guardrails in 2026
• Prompt injection in production
• Secure AI development
• Clean Code: key ideas

Conclusion

In the agent era, code review is not a politeness ritual or a debate about braces. It is a harm-limiting system under sharply higher generation speed. A human does not need to read every line with equal attention — they must not hand the machine risk classes where the cost of error is systemic.

Do one concrete thing this week: write light/deep review triggers in the repo and block auto-merge on dangerous paths. Everything else is contour growth: independent AI critic, small increments, honest tests, and review-debt metrics.

Lab method in one line: a verifiable result beats a confident patch — see Chemistry of Code.