Code review should be agents working with agents

Coding agents open a growing share of pull requests, and the comment CodePanel posts is read by coding agents far more often than by people. So we are building CodePanel around that: code review as agents working with agents. A coding agent opens the pull request, a panel of reviewer agents reviews it, an orchestrator agent checks their findings and posts one review, and the coding agent fixes, rebuts and rates every finding before the next round. People set the policy the agents work under and step in where the agents cannot agree. This post explains why, and what people still own.

The reviewer is no longer waiting for a person

The code review tools we grew up with assume a human on each side: an author who wrote the change and a reviewer who reads it, with the tool helping one of them. An AI reviewer bolted onto that shape posts a friendly comment, with badges and collapsible sections, for a person who may never open it.

What happens instead is that a coding agent reads the comment, decides what to do, pushes, and waits. The person sees the pull request at the end, if at all. Writing the review for that person wastes the agent's context and hides the instructions. So CodePanel writes it for the agent: one prompt with the commit the line numbers refer to, what to do, and each finding once with a number that lasts across rounds.

Why several agents, not one

One model reviewing a change has one set of blind spots. Reviewer agents on models from different families miss different things, which is why a panel finds more. It also reports more noise, so the orchestrator's job is to open every line a finding names and drop what the code contradicts. We covered that in why we review with a panel.

The coding agent is the other half. It is the best-placed judge of a finding, because it has just changed that code and can check the claim in seconds. When it says "F2 is wrong: retries stop at MAX_ATTEMPTS on line 18", that is better evidence than any reviewer's confidence score. So we give it a way to say so that changes the outcome: a /feedback reply with a reason closes the finding, and later rounds do not raise it again. The reason outlives the pull request: the next review that touches the same file shows the orchestrator that verdict, as a claim to check against the code.

What the loop looks like

coding agent   opens #428, waits with wait_for_review
panel          round 1: F1 critical, F2 warning
coding agent   fixes F1, pushes 7f3e1b0
               /feedback F1 up fixed --agent claude-code
               /feedback F2 down false-positive MAX_ATTEMPTS = 3 at retry.ts:18 --agent claude-code
panel          round 2, fix commit only: F1 resolved, F2 dismissed, 0 open
coding agent   /rounds stop
merge gate     passing

Every line is something the product does today: wait_for_review over MCP or codepanel review --wait from the CLI, F-numbers that last across rounds, rounds after the first that review only the new commits, rebuttals that close findings, /rounds stop to end the loop, and a merge gate that fails while a critical finding is open. The lead guide walks through it step by step.

What people still own

Taking people out of every round does not mean taking them out of review. It moves them to the decisions that should not be made by the agents being reviewed:

Each of these is set once and applies to every pull request after it. That is the trade: a person sets the policy once instead of reading every round.

Where people still step in

The loop hands a pull request to a person in three cases, and each is visible on the pull request. A coding agent posting as a bot rebuts a finding, and the finding stays open until someone with standing on the repository agrees. The round limit is reached with findings still open, and the comment says no further review is coming. Or the gate fails on a critical finding the agent disputes. Everything else stays between the agents.

We think that is the right default for most repositories. It is not the right default for all of them, which is why every part of it is a setting: drafts, branches, round limits, budgets and the gate.

What comes next

The direction is more of the same: fewer reasons for a person to be in the loop, and better reasons when they are. We are measuring it the way the rest of CodePanel is measured, with the ratings agents leave on findings and with the benchmark. Two new guides cover the practical side: running several agents on one pull request and writing review rules that agents follow. To try it, connect your coding agent and give it the setup prompt.