flowchart TD
    A[User prompt] --> B[Coding agent]

    B --> C{Tests, lint,
type checks pass?}

    C -- No --> B

    C -- Yes --> D[Spawn review agent]

    D --> E{Valid review
feedback?}

    E -- Yes --> F[Apply feedback]
    F --> C

    E -- No --> G[Ready for
human review]

The Problem

When a coding agent finishes implementing a change, the next step is usually a human code review. Unfortunately, that often means humans spend time finding mistakes that another AI could have detected first.

The Solution

Before handing the code to a human, instruct your coding agent (for example, Claude Code or Codex) to launch another coding agent in non-interactive mode to review the changes and automatically apply valid feedback.

This creates an AI feedback loop before human review. The result is code that is more likely to pass manual review on the first attempt, reducing reviewer time spent on obvious bugs, style issues, or missed edge cases.

A note on autonomy: in this workflow the agent applies any feedback it considers valid, including design-level changes. That is acceptable precisely because a human review still follows—nothing merges unreviewed, and the human remains the final safety boundary. If your human reviews tend to be quick sanity checks rather than thorough reads, tighten the loop instead: instruct the agent to flag security- and architecture-level suggestions in its report for your decision rather than silently applying them.

Why Use a Different Model?

If the original implementation was based on a poor prompt or an XY problem, asking the same model with the same conversation history to review it often leads to the same blind spots. Garbage In, Garbage Out (GIGO) still applies.

Using a different model increases the chance of catching incorrect assumptions, alternative implementations, or subtle bugs that the original model overlooked.

Why Use a Fresh Context?

A fresh context avoids context rot and eliminates unnecessary conversation history that may bias the review.

However, the reviewing agent still needs enough information to understand the project’s conventions and the motivation behind the change. Useful sources include:

• AGENTS.md (or equivalent project instructions).
• Git commit history.
• An issue or ticket describing the problem being solved.

These provide the reviewer with the “why” without forcing it to inherit the entire implementation conversation.

Tips

A good git commit message already explains why the change exists. Hopefully you are writing meaningful commit messages.

If the review is performed before the work is committed, consider providing the reviewing agent with:

• An issue or ticket URL.
• A short explanation of the problem being solved.

Without this context, even an excellent reviewing agent may produce only superficial feedback because it lacks the reasoning behind the implementation.

FAQ

Why not let a CI reviewer review the Pull Request (Merge Request)?

A CI reviewer is still valuable, but it operates in a much more constrained environment than a local coding agent.

Depending on the CI setup, it may only receive the diff instead of the full repository. It usually cannot inspect installed dependencies, examine sibling repositories in a monorepo or workspace, or verify assumptions by exploring the local development environment. In many cases, it also cannot execute arbitrary command-line workflows beyond those explicitly defined by the CI job.

A local reviewing agent has access to the complete working tree and can investigate the project much more thoroughly before the changes ever reach CI.

Why not run the reviewer manually?

You certainly can.

The benefit of making it part of the coding agent’s workflow is automation. While the agent performs the review, you are free to work on something else instead of waiting for the implementation to finish and remembering to launch a review yourself.

The review becomes another automatic quality gate rather than an extra manual step, reducing context switching and making the workflow easier to follow consistently.

CLAUDE.md Example

# Code Review

After working with any code, always:

1. Run a code review non-interactively.

```bash
codex --sandbox=read-only -c model_reasoning_effort="high" --strict-config review --uncommitted
```

(Codex CLI shown as an example; any coding agent with a non-interactive mode works.)

Tips:

- Use a **10-minute timeout** (600000 ms) on the Bash tool call for this command.
- Codex calls may be costly. Rerun the review on major changes or after fixing bugs, but not on minor fixes like typos. Set a hard cap tuned to your repository and budget—for example, 5 calls per session—and require explicit user approval beyond it.

2. Apply relevant suggestions.