Claude Code code review with a second agent: what a reviewer caught

Why a second agent

An agent that writes a change has just spent its whole context on it. It knows why each line is there, and that tends to make its own check weak: it reads what it meant, not only what is on disk. A reviewer is a second context that opens the commit cold. Teams of people have reviews for the same reason.

The method is what makes it useful. A reviewer that only reads a diff is one more agent saying “looks fine”. The one in this article runs the commit.

What the reviewer does with a commit

• It takes the exact commit and builds it in a clean copy, so that nothing left in the author’s working folder can make it pass.
• It runs the tests in a sandbox: a temporary home folder, and the terminal tools are replaced by stand-ins that record every call and refuse to run.
• It checks the formatting, runs the static checks for Linux, macOS and Windows, and runs the full tests.
• It runs mutation checks: change one line of the code, and the tests must go red; then revert it. A test that stays green when the code is broken is not checking that line.
• If the change has a dashboard part, it builds the dashboard and compares.

The answer has a fixed shape. The first word is ACCEPT or REJECT. A REJECT names the file and line, what fails and how severe it is. Anything the reviewer wants changed but would not block on goes in as a note on an ACCEPT.

A race that came in as a footnote

The clearest catch was a race: a company deleted while a project is being registered left the project pointing to a company that no longer existed. The code first looked up the company and only then opened the write that saved the project, and the deletion fell in the gap between the two.

The reviewer did not reject the commit. It filed this as a non-blocking note on its ACCEPT. The author first declined the note, then fixed it: the company is now read inside the write itself. The test for it runs 25 rounds of registering a project against deleting its company. Before the fix, 13 projects were left with a dead company id. After it, none, in five runs. The reviewer’s own comment on the test: it “fails every run without it”.

A non-blocking note is still a finding: the team’s lead later turned it into a check on the task so that it could not be forgotten. And the author was allowed to disagree first: the review is a conversation, and the test settled it.

Other catches

• A change that would have turned about 18 links to agent names into broken copy buttons. The reviewer stopped it before it landed.
• A stored credential that could have gone to a different host than the one it belonged to, and a route that skipped a check it should have made.
• An author said a failing test failed “identically on clean master”. The reviewer ran master: green, and the author’s branch: red. Four mutants survived, which means the tests were not checking what the author thought.

What it missed

The reviewer accepted one commit that had a single line not formatted. It was cosmetic and the author fixed it. The format check has been part of the reviewer’s method since. A reviewer is a method that improves when it misses; it is not a guarantee.

How to set one up

None of this needs a particular tool. If you run more than one agent, these hold with any setup:

• Give the reviewer its own session and its own clean copy of the repository. Never let it review in the author’s working folder.
• Write the method down as instructions, not as a hope: the commands it runs, and the verdict format with ACCEPT or REJECT first.
• Ask for mutation checks. They are what turns “the tests pass” into “the tests would notice”.
• Let non-blocking notes exist, and make sure someone turns the good ones into checks.
• When the reviewer misses something, add the missing step to its method.

In harnsy the review is a state of the task. A submitted task goes to whoever asked for it; a rework goes back to the author with a note; the person accepts the final result. See roles and tasks.

What we do not know

• We have not counted how many real defects the reviewer missed. We know the one above because it was noticed.
• The 66 verdicts are one day, not a rate. A different day, a different team or a different kind of change will look different.