An agent can write code faster than you can read it, so review becomes the bottleneck. In this video, we will give an agent a separate review task, combine findings from fresh reviews, and decide which findings deserve a fix.
In a previous video, we made passing CI checks a requirement for merging. Tests, type checks, and lint are formal tools, checking conditions we have encoded.
Agent review adds a fuzzy tool beside CI. The reviewer looks for problems our checks do not encode, such as code that differs from the spec, a missing error path, or a misleading name.
Authors are poor reviewers of their own work, and that includes the agent session that wrote the code. Its context already contains the reasons the code looked right, so it tends to approve its own choices.
Start a fresh session or a subagent with only the diff and the spec, without the author's conversation. Using a different model also changes the mistakes the reviewer makes, for example, having Codex review code written by Claude Code.
Give the reviewer the diff, the spec or issue, and what to look for. For example, ask it to check whether the implementation meets the requirements and handles failures.
Include your project's review checklist, checked into the repository, or package those instructions as a review skill. Rules such as "Never mock the database" and "Every endpoint checks authorization" are project decisions that a generic reviewer cannot know. Tell the reviewer to read those rules explicitly.
Because review is a fuzzy tool, another run can produce different findings on the same code. It is worthwhile to run several reviews, using subagents that each start with a fresh context and the same review brief.
Merge their findings and combine duplicates. Agreement between reviewers is useful evidence, but it does not establish that a finding is correct.
Ask the reviewer to rank findings by importance and by the difficulty or cost of fixing them. Require a concrete failure scenario for every finding, so you can judge both the consequence and the proposed work.
For example, the reviewer reports, "If saving fails, the app still reports success, and reloading loses the edits." That is a serious consequence, even if handling the error and adding a test is a small fix. Importance and effort answer different questions.
Claude Code has a built-in command, "slash code-review", for reviewing the current diff, or a pull request number or branch you supply. You can choose an effort level, from "low" through "max". The flag "dash dash comment" posts findings as inline pull request comments. The flag "dash dash fix" asks Claude Code to apply findings to the working tree after reviewing.
Claude Code also has "slash security-review" for checking branch changes for security vulnerabilities. In the Codex command-line interface, "slash review" starts a code review. Check the installed version's help for options, since these commands change.
Asking a reviewer for findings encourages it to find something, including problems that are not real. Verify each finding before acting, ideally by turning its failure scenario into a failing test.
For the save example, make saving fail and check that the app reports the failure instead of success. If that test exposes the bug, you have concrete evidence for the fix and a regression test to keep.
Keep reviewing and fixing separate: the reviewer reports, and you decide what to accept. A reviewer that applies its own fixes becomes a second author whose changes still need checking.
Agent review is useful for local bugs, missed edge cases, spec mismatches, missing error handling, and inconsistencies. It is less reliable at judging whether you chose the right feature or whether the change fits the architecture.
It also misses invariants in files it never read, and reading code does not establish runtime behavior. Security changes, data migrations, and public APIs still need a human reader.
Agent review helps you handle code arriving faster than you can read it all. Fresh reviews give you concrete findings to investigate, while you retain the decision about what to change and merge.
See you in the next video.