Reviewing code written by a colleague is different from reviewing code written by an agent.

Work with someone long enough and you pick up their habits — one person loves reduce, another always misses edge cases. An agent has no habits. Every output depends on the session context.

Here are the checkpoints I’ve built for reviewing agent code.

First: did it touch things it shouldn’t have?

The agent’s biggest problem isn’t writing wrong code — it’s not controlling itself. It might fix one bug and casually modify a config file next to it, or rename a function that had nothing to do with the task.

Every change in the diff that’s outside the task scope is a red flag.

Second: did it handle the edges?

Claude’s happy path code is usually beautiful. The problem is when user input is empty, the network times out, or permissions are denied — those branches often go untested.

I scan every if/else and every catch block during review. Is it actually handling the error, or just logging and moving on?

Third: are the tests real tests?

This is where agents cut corners most often. The test passes, but look closer — it mocked the entire function, asserted a hardcoded value, or tested a condition that can never fail.

I have a trick: swap the test data. If the test fails with different data, it was testing fake logic.

Fourth: does it match the project style?

Agents have a default style. The code might be technically correct but feel foreign in your project.

Naming conventions, error handling patterns, even blank line habits — inconsistencies won’t cause bugs, but they’ll make maintainers miserable. If you spot style drift, add one rule to CLAUDE.md. Next time it’ll be right.

Fifth: is it over-engineered?

Agents love to make things “perfect.” You ask for a filter feature and it builds a full filtering framework with multi-condition combination, sorting, caching — when all you needed was a simple dropdown.

During review, ask: will this code be useful in the next three months? If not, it’s over-engineering.

Bonus: Writer/Reviewer pattern with two sessions

For important changes, use two Claude sessions:

• Session A (Writer): implements the feature
• Session B (Reviewer): reviews Session A’s diff in a fresh context

Session B only sees the diff and review criteria. It doesn’t know about the reasoning that produced the change. This catches blind spots baked into the original approach.

Claude Code’s built-in /code-review command does exactly this — it spawns a subagent to review the current diff and report issues in a clean context.

One rule for reviewing agent code: don’t lower your standards just because it’s an agent. Check harder, not easier. You don’t know where it went off track.

Article Link: