A coding agent finishes a patch, runs the tests, reads its own diff, and tells you the change looks good.
That sounds efficient. It is also a subtle conflict of interest.
The problem is not that the model is dishonest. The problem is that the same context which produced the patch also contains the assumptions that justified it. When the agent reviews its own work, it is likely to reuse those assumptions instead of challenging them.
I have seen the failure mode look like this:
A fresh reviewer helps, but "add another agent" is not a complete design. If both agents receive a vague prompt and unlimited access to the repository, you have mostly doubled the cost and created two confident narratives.
Here is the review loop that has been more reliable for me.
The reviewer should know exactly what is being reviewed: a prepared diff, a commit range, or a small packet of changed files.
Treat that diff as the source of truth. Repository context can explain a finding, but it should not let the reviewer wander into a broad redesign. A bounded target makes the final report auditable: every claim can point back to a concrete change.
A timeout, unavailable file, stale hint, or truncated diff is not a clean review.
This sounds obvious, but review systems often collapse "I did not find a problem" and "I could not inspect the thing" into the same result. They are very different outcomes.
Coverage limitations should survive all the way into the visible report. If part of the target was not inspected, say so. Confidence should go down instead of silently turning green.
Launching a security reviewer, performance reviewer, architecture reviewer, and test reviewer on every patch looks thorough. In practice it creates duplicate findings, higher latency, and a new aggregation problem.
A specialist is useful when the primary reviewer has a concrete unresolved question:
Does this authorization check still protect the remote path?
That is much better than:
Review this code for security issues.
The assignment should be narrow, the expected evidence should be explicit, and the primary reviewer should still decide whether the answer is supported.
A third model should not rubber-stamp every clean review. That turns "independent validation" into a mandatory tax.
Call a judge when a potentially serious finding needs validation, two reviewers conflict, or the final recommendation is still low-confidence. Ask it to inspect the disputed claim, not to repeat the entire review.
The judge should be allowed to keep, downgrade, or reject a finding. Otherwise it is not a judge; it is another source of prose.
The review stage should be read-only.
Once an agent starts editing while it is still reviewing, the evidence changes underneath the report. It also becomes harder for a human to approve the actual remediation scope.
Produce the findings first. Let the user approve them. Then hand only the validated findings to a separate fixer that makes the smallest safe changes.
This structure does not remove the need for human judgment. It makes the judgment cheaper because the evidence, uncertainty, and proposed remediation are no longer mixed together.
I am building this loop into BitFun: the Deep Review orchestrator is read-only, missing evidence stays visible as a coverage limitation, specialist calls are bounded, the quality judge is conditional, and remediation is a separate stage.
The useful mental model is not "one agent writes and another agent reviews." It is:
one process proposes a change; a separate process tests the proposal against bounded evidence.
That separation is where most of the value comes from.