AI Code Review: Why Two Agents Miss the Same Bugs and How to Fix It

Having a developer agent write code and a separate reviewer agent inspect it seems natural, but if both agents misunderstand the requirements, the reviewer may simply rationalize the flawed implementation. The article illustrates this with an import feature where the business rule allows valid rows to succeed and invalid rows to be reported individually, yet the developer agent implemented an all-or-nothing transaction. A reviewer that only reads the code and the developer's summary easily follows the same wrong logic.

Changing Roles Does Not Guarantee Independent Judgment

Code review means checking changes before merge. Swapping the role prompt shifts focus but does not automatically create independent judgment. The author requires the reviewer to first read the requirements, acceptance criteria, and change scope before looking at the implementation and the developer's explanation. This at least gives the reviewer a chance to form an independent view of what the code should do before evaluating what it does.

Switching models can help but is not a quality guarantee; two models may share outdated training data or overlook the same permission constraint. Ultimately, review must rely on evidence: which specific risk was identified, how to reproduce it, and how to verify the fix. Google's code review guide lists overall design, functionality, complexity, and tests as review items, and explicitly warns against limiting review to naming and formatting or accepting green test results without scrutiny.

Offload Mechanical Checks, Then Focus Human and Agent Judgment

Formatting, types, dependencies, and static rules should be handled by stable automated tools; agents can invoke these tools but conclusions must come from actual execution records. Areas requiring business and system context are then analyzed jointly by agents and engineers. Using the import feature as an example, the author proposes a risk-based division:

Compilation, type, format errors – checked first by automated tools; leave the execution results for the specific commit.

Processing rules inconsistent with requirements – reviewer agent checks against acceptance criteria; leave conflicting rules, code locations, and counterexamples.

Duplicate imports or partial submissions – agent analyzes, engineer verifies critical paths; leave state changes, uniqueness constraints, and failure verification records.

Department data access violations – server-side permission checks and negative testing; leave rejection results and proof that no write occurred.

Historical compatibility and business exceptions – handled by people familiar with the system and business; leave trade-off rationales, impact scope, and confirmation records.

This division adapts to risk: a low-risk copy change doesn't need full queue review, while changes involving money, permissions, or irreversible data cannot be approved just because few lines changed.

Good Review Comments Must Enable Further Investigation

A vague comment like "possible concurrency issue" is insufficient. A useful comment specifies: when two identical batches enter simultaneously, the check-then-insert logic may both pass; need to verify whether the storage layer guarantees uniqueness and whether conflicts return the original batch instead of creating a second processing. The developer then knows exactly where to look — uniqueness constraints and conflict handling — and the discussion centers on a concrete path rather than speculative risk.

The author suggests requiring the review agent to document four items for important findings: the behavior involved, trigger conditions, evidence location (code pointers), and suggested verification method. Unverified suspicions may be kept but must be marked as pending confirmation, not presented as reproduced issues.

If the reviewer spots a design gap, they should propose a change for architects or business owners to approve, not silently adjust the requirements document to match the implementation. Otherwise the standard shifts with the code and any review passes.

After Tests Pass, Ask: Can They Actually Catch Errors?

An import test that only asserts "API returns success" may pass even if no data was written. Implementation and tests generated from the same faulty assumption tend to mutually validate each other. The author recommends targeted reverse checks on key rules:

Deliberately remove duplicate-batch protection and see if existing tests fail (mutation testing).

Send unauthorized requests bypassing the UI and verify the server still rejects them (negative testing).

These checks must run in isolated environments, not by modifying production systems. Not every line needs this treatment; start with high-impact rules where failure consequences are clear.

Build success, unit tests passing, isolated integration tests passing, and production observations are different evidence layers. Review records should state which layer has been completed and which dependencies remain unconnected.

Review Conclusions Have an Expiration Date

After a review, a new commit may invalidate prior conclusions. If transaction boundaries, tool permissions, or exception handling change, the affected parts must be re-reviewed. "This branch was reviewed" is too broad; the record must link to the specific commit, acceptance criteria version, execution environment, and how each issue was resolved. Unresolved high-risk issues should follow the team's merge and release rules, not be closed by the code-generating agent itself.

This approach increases review cost. Its value should be measured by tracking effective findings, false positives, review wait times, and post-merge defects over a period, not just by counting review comments. The extra agent's worth lies in whether it brings new evidence and valid discoveries; multiple agents merely saying "looks fine" does not make delivery more reliable.

References

Google Engineering Practices, What to look for in a code review:

https://google.github.io/eng-practices/review/reviewer/looking-for.html