Code Review in an Agentic World

Traditional code review assumes humans write code at human speed. One developer, a few PRs per day. Reviewers can read every line, understand the context, catch bugs.

Agents break this assumption. They can produce more code, faster. If you try to maintain the same review process, you get:

• Review backlog: PRs pile up faster than humans can review them.
• Rubber stamping: Reviewers skim and approve to clear the queue.
• Reviewer burnout: Humans spend all day reading agent code instead of writing their own.

Some review tasks are mechanical. They follow rules. They can be automated completely. Humans should not spend review time on these categories.

A useful rule of thumb is harsh: if static analysis can catch it, static analysis must catch it. Teach humans to trust the process, and teach your process to be trustworthy.

If these checks pass, a human reviewer should not re-check them by hand. Humans should focus on things automation cannot catch.

Some things require human judgment. These are the high-value review tasks:

Agents can review code too. Not just linting, actual code review. An agent reviewer can:

• Summarize what the PR does
• Flag potential issues
• Check if tests cover the changes
• Verify the PR matches the spec
• Suggest improvements

You can run multiple reviewer bots with different jobs. Avoid using the same model, prompts, and tools for both author and reviewer roles.

This is agents reviewing agents. It sounds recursive but it works. The reviewer agent has a different job than the author agent. It is looking for problems, not building features.

Define which tier of review applies based on what the PR changes:

Implement this with CODEOWNERS and branch protection rules. Files in /docs have different rules than files in /src/auth.

Many teams think they used to read every line. In practice, they never did. They already triaged their attention based on risk and evidence.

This matters more in an agent world because diffs get larger. The job of your system is to help the reviewer focus, not to force them to hunt.

If work starts by assigning an issue to an agent, you can standardize the lifecycle and turn review into a set of checkpoints. The reviewer should arrive late, after evidence exists, not at the beginning.

A simple default is a status ladder that the agent must post back to the issue or PR:

• Env ready: the agent has a working environment and can run the project.
• Reproduced: if this is a bug, the agent reproduced it and attached evidence.
• Fix implemented: changes are made, with a clear description of what and why.
• Tests added: a repeatable check validates the change.
• Ready for human: the PR is ready for the right tier of human review.

Consequence: review becomes a pipeline with gates. It stops being a wall of diffs that humans must interpret from scratch.

When agents produce lots of code quickly, architectural drift happens fast. Small deviations compound. Suddenly your codebase has three different ways to do the same thing.