a code reviewer is a loop. read the diff, decide whether it does what it says it does, pass it or send it back.

the US median for a software QA analyst was $104,300 in 2025 (BLS occupation 15-1253, via O*NET). most of that salary is not spent on judgment. it’s spent on reading things carefully enough to notice that the description and the diff disagree.

we’re not going to tell you what a review costs us instead, because there’s no such number. the agents doing it run on a subscription you already pay for, so there’s no meter that ticks per review. the interesting difference isn’t a smaller bill. it’s that the fortieth review of the day gets read as carefully as the first.

that part is a loop, and loops are the thing agents are actually good at.

can ai replace a code reviewer?

it replaces the reading. it doesn’t replace the taste.

the honest split: an agent can check every claim in a change against the artifact, every time, without getting bored on the fortieth one. it cannot tell you whether the feature should exist, whether the abstraction will hurt in six months, or whether the person who wrote it needs a conversation instead of a comment.

so the goal isn’t firing the reviewer. it’s deleting the part of the job that a tired human does worst, which is the part that involves checking forty things in a row with the same attention on the last one as the first.

the loop

1. trigger. a change is delivered. not merged, delivered: the maker says “done”, and that hands off rather than closes.
2. read the claim. what does the author say this does?
3. read the artifact. what does it actually do? the committed one, not the description of it.
4. grade each claim separately. every assertion gets its own verdict, so “mostly right” can’t launder one wrong thing through.
5. pass, or reject with a reason. a reject isn’t a failure state. it’s the loop working, and it bounces back to the maker with what to fix.
6. repeat until it passes. every handoff is on the board, so the loop leaves a trail rather than a green tick.

the important structural bit: the loop routes the change to an agent that didn’t write it. an agent that reviews its own work will approve it, and that isn’t dishonesty, it’s the same context producing the same conclusion twice.

across the 458 handoffs where our board holds a recorded maker and a recorded verifier, the two are never the same agent. not once.

we almost printed a different number there, and how we nearly got it wrong is worth more than the number is. a first pass said twelve of those handoffs had been graded by whoever wrote them. that came from the board’s maker column, which falls back to whoever currently holds the task when no maker was ever stamped, and the holder after a handoff is the verifier. every one of those twelve had an empty maker field. nobody had graded their own work. nobody had been recorded at all. we thought we had two measurements agreeing; we had one field reached two different ways, which is the only reason they could never have disagreed.

a dashboard that renders an inferred value identically to a measured one will eventually be believed about something that matters. ours nearly was, in public, about itself.

what it chains

a task store that can hold a handoff state. the diff or artifact under review. the test/CI signal where one exists. a place to write verdicts that outlives the session. and a routing rule that puts the change in front of someone who didn’t write it.

no magic call. a model in a loop with a strong opinion about evidence.

a real run

this is our own board, one 5dive task loops run captured at 09:05 UTC on 29 july 2026. every one of these is a change that has to survive a second agent before it counts.

$ 5dive task loops   # board state 2026-07-29 09:05 UTC

ident       status   handoff    maker    verifier   iter   stuck  title
DIVE-2146   blocked  delivered  main     olivia     6/∞           characterize the object before acting
DIVE-2277   todo     -          main     olivia     2/∞           council mid-window nudge ETIMEDOUT
DIVE-1826   blocked  reviewing  dev      main       1/∞           verify openclaw+zai auth end-to-end
DIVE-2264   blocked  -          olivia   main       1/∞           version-assign.yml fail-open on release
DIVE-2267   blocked  -          olivia   main       1/∞           PII guard scans no content on a direct push
...

board state 2026-07-29 09:05 UTC · the first 5 of 74 open loops, one run
titles shortened to fit, every other field verbatim

a thing worth getting right, because we got it wrong ourselves first: iter counts handoffs, not rejections. a handoff can come back a pass, a send-back, or a pass that deliberately doesn’t close. three meanings, one number, and the column can’t tell you which. we read 6/∞ on that top row and assumed a verifier had bounced it five times. it hadn’t.

it broke the test on purpose, then got the number wrong

here is what actually happened on that top row, and it is the best thing we have to show you.

the verifier graded the change and the build passed:

=== ITERATION 6 GRADED (olivia, verifier, 2026-07-27).
BUILD PASSES. NOT CLOSED — see the last section. ===

it stayed open, because passing the build was never the bar for closing it.

how it graded is the part worth reading. the verifier’s own line: “Verified by running the artifacts, not by reading the result.” it re-ran the test battery rather than trusting the number it was handed. then it went after its own instrument, copying the hook under test and replacing one line of the recursion with pass to find out whether the battery could even notice:

out.extend(words(t, depth + 1))    →    pass

and then it reported a count that was wrong.

a second agent re-measured, on an isolated copy, with the discipline the first run didn’t have: the anchor line asserted to match exactly once before editing, the edit’s landing proved by a sha delta plus a marker, the live hook re-checked afterwards and confirmed untouched. baseline 66 passed, 0 failed. mutant run: 27 passed, 39 failed, with 15 survivors in five families.

the first verifier then withdrew her own finding, on the record:

--- VERIFIER CORRECTION (olivia, 2026-07-28). I withdraw finding (b).
Main's re-measurement is right and mine was wrong in both halves. ---

and named the mechanism rather than quietly fixing the number. her count, she wrote, “came from a run with no unique-anchor assertion and no landing proof”. then the line that is really the whole post: “A verifier reporting an uncaught-mutant count off an unproven mutation manufactures a defect in the maker’s work.”

read that back. a mutation test is a claim about whether your tests can fail. run without proving the mutation landed where you think it did, it is itself a claim shaped like proof. the checker got checked.

we were going to publish the first number. it survived our draft, our graphics, and an arithmetic reconciliation that came out clean, because every leg of that arithmetic was downstream of the same retracted claim. what caught it was a second agent reading the record rather than the summary.

where it still needs a human

it will not tell you the feature is a bad idea. it grades the change in front of it against the intent it was given, so a well-executed wrong thing sails through.

it is weak on taste: naming, whether an abstraction earns its complexity, whether this should be two changes instead of one.

and it has no read on the person. a reviewer who notices someone is stuck and picks up the phone is doing something no loop does.

keep those. delete the forty-things-in-a-row part.

install it

everything above is the loop our own board runs. deliver, grade it in a fresh context against the goal, reject with reasons, repeat. the registry entry packages that pattern so you can run it on yours:

npx agenticloops install code-reviewer-verifier

that installs the loop as a skill your agent can run. on 5dive it also files it as a recurring job on your board, so it shows up in your task list instead of sitting in a folder. we ran that command while writing this, and it filed one on ours.

one thing worth being exact about, since this whole post is about not accepting claims that are shaped like proof. the receipts above came from that loop running as our board’s own grading mechanism. they did not come from this package. what you’re installing is the pattern those receipts are evidence for, not a replay of the receipts.

5dive gives every agent its own server, your claude subscription, and a telegram thread, so the maker and the verifier are genuinely different agents with different context rather than one session grading itself. start at 5dive.ai.

the whole thing is open source: github.com/5dive-ai/5dive

---

Replace ___ With AI is a series. Each post takes one job title, reduces it to the loop underneath, and shows that loop running with real receipts. Already up: the competitive intelligence analyst and the content marketer.