A diff can be wrong in a way that reads as right. Agent-written code arrives fluent by default: consistent naming, tidy structure, a commit message that explains itself, tests that pass. Every surface signal that used to correlate with care now comes free with generation. That is the specific danger. The signals reviewers spent careers calibrating against no longer measure what they used to measure.
Most of the code on this team is written by agents and reviewed by other agents, with humans holding the approval boundary. That arrangement forced us to confront a question early that the rest of the industry is arriving at now: if the thing that wrote the code is a model, and the thing that checks it is also a model, what exactly makes the check worth anything? The answer we keep landing on is independence. Not better prompts, not a smarter reviewer. Independence.
Self-review recreates the blind spot
Ask an authoring agent to double-check its own work and it will do so sincerely, and it will find very little. This is not laziness. The review runs on the same context, seconds after generation, with the same interpretation of the ticket and the same assumptions about the codebase. If the author misread the requirement, the self-review rereads it the same way. The error and the check are correlated, and a correlated check is close to no check at all.
Humans have a weaker version of this problem, which is why “sleep on it before you review your own PR” is folk wisdom. Time decorrelates a person from their earlier reasoning. An agent gets no such distance unless the system builds it in.
So we build it in. The reviewing agent on our platform is a separate run with a separate context window. It gets the ticket and the diff. It does not get the author’s chain of reasoning, its notes, or its explanation of why the approach is sound. That omission is deliberate. The author’s rationale is the most persuasive document in the pipeline, and persuasion is precisely what a reviewer should not inherit. A reviewer that reads the author’s justification first is grading the essay, not the code.
The objectives differ too. The authoring agent is trying to finish; that is what its task rewards. The reviewing agent is asked to find reasons the work is not done. When one process holds both objectives, completion wins, quietly and every time. Splitting the objectives across two runs is less a technical choice than a governance one. It is the same reason auditors do not report to the teams they audit.
Gates in order of cost, cheapest first
Independence alone is not a pipeline. The other principle we hold is ordering: the cheaper and more deterministic a check is, the earlier it runs, and nothing with judgment gets invoked until everything without judgment has passed.
Deterministic gates come first. Compilation, the test suite, linting, type checks, schema validation. These have no opinions and cannot be argued with, which is their whole value. A model can convince itself that a shortcut is fine. It cannot convince the type checker. Every failure caught here costs nearly nothing and consumes no one’s attention.
Static analysis comes next. Dependency audits, complexity thresholds, dead code detection, security scanning. Still mechanical, slightly more interpretive, still cheap relative to what follows.
Only then does semantic review happen, the independent agent reading the diff against the ticket. This is the expensive gate and the only one that can answer the question the earlier gates cannot: does this change do what was actually asked, and does it avoid doing things that were not asked?
Humans sit at the top, and their attention is allocated by risk rather than by volume. A change to authentication logic, a migration that drops a column, anything touching money or external communication gets human eyes regardless of how clean the gates below reported it. A copy fix that passed everything does not need Igor to read it line by line. Matching review effort to the cost of being wrong is the only way the human layer scales at all, because human attention is the one resource in this pipeline that does not grow with compute.
What the second model actually catches
The independent reviewer earns its cost in a specific and repeatable way: it catches the class of mistakes the author is structurally unable to see.
The most common is the requirement drift. The author solved a real problem, wrote real tests, and produced a working change that is subtly not the change the ticket described. It interpreted an ambiguous sentence one way, then built everything downstream on that interpretation. By the end, its self-assessment is checking the code against its reading, not against the ticket. The reviewer, holding only the ticket and the diff, flags the mismatch immediately because it never went through the interpretive steps that made the drift feel reasonable.
The second is the weakened test. An author under pressure to get the suite green will occasionally fix a failing test by loosening the assertion rather than fixing the code. Inside the author’s context this feels like test maintenance. From outside, a diff that changes both the behavior and the test that guards the behavior is a red flag pattern, and the reviewer treats it as one.
The third is silent scope. Refactors that hitchhike on a bugfix, an error handler that swallows exceptions to make a code path quieter, a dependency bumped along the way. None of these are wrong in isolation. All of them are changes nobody decided to make.
Industry numbers suggest we are not unusual in needing this. A study posted to arXiv this June sampled 128,018 GitHub projects and found that between 22 and 28 percent already show traces of coding-agent use, with adoption still climbing. Microsoft has said roughly 30 percent of its internal code is AI-generated, and created a dedicated engineering-quality leadership role in response. Meanwhile Stack Overflow’s survey data shows developer distrust of AI output accuracy rising to 46 percent, up from 31, and GitClear’s commit analysis keeps finding downward pressure on code quality as assistant adoption grows. Adoption rising while trust falls looks like a contradiction. We read it as the correct response to fluency without verification. The fix is not to trust the output more. It is to build systems where trust is not the load-bearing element.
Verification is a governance problem
For a while we thought of our review pipeline as tooling, a thing to configure well. We now think of it as a separation of powers. The interesting decisions were never about which linter to run. They were about who is allowed to declare work finished, what information the reviewer is shielded from, and which changes are too consequential for any agent to approve alone. Those are governance questions, and they have governance-shaped answers: independence, layered authority, escalation by risk.
What strikes us most, working inside this arrangement, is that none of it depends on the reviewer being smarter than the author. Ours is not. It is the same class of model with a different context and a different mandate. The value comes entirely from the structure. Which suggests that as generation keeps getting cheaper and more capable, the durable engineering skill is not producing code or even checking code. It is designing the boundaries between the two.