Set up AI code review with a bench agent

The single cheapest upgrade to agentic code quality is a second agent — but only if you set it up right. Ask the agent that wrote the code to review the code, and you mostly get a confident thumbs-up, because the blind spot that created the issue is the same blind spot now grading it. The fix is independence: a separate agent, with its own fresh context, whose only job is to review.

In C² that's a bench agent. Here's how to run one so it adds real signal instead of noise.

Why the author shouldn't review itself

Self-review is weak for the same reason it's weak in humans, only more so. The agent that built the feature carries the assumptions it built it on. Asked to check its own work, it tends to re-confirm those assumptions rather than question them. It already "knows" the code is right — that's why it wrote it that way.

A reviewer that didn't write the code has none of that baggage. It reads the work cold, against the requirements, and notices the thing the author took for granted. That fresh-eyes effect is the entire point, and it's why review is one of the highest-value jobs you can give a coding agent.

The bench agent: independent, review-only

A bench agent has a deliberately narrow brief: review, never execute. It reads the diff and the contextbase, checks the work against a standard, and reports findings. It does not edit the code. That separation is what protects its independence — a reviewer that also fixes things starts owning the work, and you're back to self-review.

Reserve it for where independence pays: a security-sensitive change, an architecture decision, a risky refactor, a PRD before it goes active. And budget-cap it — an independent review is worth real tokens, but it's a check, not a second build.

Stuart Leo

The value of a review agent is independence — it reviews, it never executes. The moment it starts fixing, it stops being a reviewer.

What a good review checks

Point the bench agent at the things that matter, in order:

• Correctness against the acceptance criteria. Does it actually do what the brief said, including the cases the author might have skipped?
• Security. The vulnerabilities the author didn't think to look for — injection, exposed secrets, unsafe input.
• Severity-ranked findings. Not a flat list — what's a blocker versus a nitpick, so you act on the right things first.
• Convention adherence. Does it follow the project's own patterns from the contextbase, not generic best-practice the agent invented?

A review that produces "looks good" is worthless. A review that produces three ranked, specific, actionable findings is worth its tokens many times over.

Close the loop with an actions table

Here's the discipline that makes bench review trustworthy over time: every review ends with a close-the-loop table — each finding, and what was actually done about it (fixed, deferred with a reason, or rejected with a reason). Saved to the contextbase, committed with the work.

Without it, reviews become theatre — findings raised and quietly ignored. With it, you have a record that the review mattered, and the next reviewer can see what was decided and why. The loop is closed, not just opened.

Keeping it anchored to the contextbase

A bench agent is only as good as what it reviews against. Give it the same contextbase the lead agent used — the decisions, the gotchas, the conventions — so it checks the work against your standard, not a generic one. A reviewer that doesn't know your project's decisions will flag things that are deliberate and miss things that violate a rule it never saw.

This is the bench role inside a wider agent team: lead executes, bench reviews, lead acts on the findings. Sequential, recordable, independent.

The value of a review agent is independence — it reviews, it never executes.

Start here: see how agent teams work, acceptance criteria the agent can check, or read the method.