Can AI Agents Really Review Each Other’s Work?

If an AI agent writes the code, should another AI agent be trusted to review it? It’s a reasonable concern. AI can produce code that looks convincing, follows familiar patterns and passes automated tests while still containing mistakes. A second agent might simply agree with the first, or miss the same problem.

Our view is that agent review isn’t enough on its own, but it becomes useful inside the right structure: reviewers with different responsibilities, a step that challenges what they find and an engineer who makes the final decision.

We’ve been testing that approach at Studio Graphene. Our agentic development workflow uses multiple agents to examine changes from different angles, challenge review findings and correct issues before the work reaches a developer. Human review stays in place. The checks leading up to it become more consistent.

‍Reviews That Depend on Someone Remembering

Teams have always layered their assurance. Developers test their work, automated checks catch failures and other engineers review changes before they’re merged. AI-assisted coding can help with each layer, but in our experience consistency was the weak point. Asking AI to review a change, look for security problems or check against the project’s rules meant another prompt each time, and it only happened if someone thought to ask.

In our agentic workflow, those checks are part of the process. Once the code is written, an automated quality gate checks that it builds and meets the project’s coding standards. If the new code causes a failure, the workflow tries to fix it before moving on. That gives review a consistent starting point, although passing automated checks only goes so far.

‍Three Reviewers, Three Perspectives

Three review agents then examine the completed changes independently, each with a different remit. One looks at correctness: logic, error handling and whether the change respects existing contracts. Another looks at security, including access controls, ownership checks and potential data exposure. The third checks the change against the project’s engineering rules.

Splitting the work this way means a change can pass one review and fail another. Code can do exactly what was intended while opening a security gap or breaking a convention elsewhere in the system. The reviewers are asked to report only genuine defects, each with a specific failure scenario, rather than a long list of suggestions, and an empty list is an acceptable result. AI reviewers can also be wrong, which is where the next step comes in.

‍Who Reviews the Reviewers?

Finding a potential issue doesn’t prove it exists. Automated reviews can produce false positives, flag intentional behaviour or recommend changes nobody needs.

So each reported finding goes to three sceptic agents, who try to establish whether it’s real. A finding only goes forward if at least two of the three agree. A separate agent fixes the ones that survive, the changes go back through review and the loop runs for a maximum of two rounds.

Adding more agents to look at the code achieves little by itself. What helps is giving them different jobs and making findings stand up to challenge, rather than accepting the first automated assessment.

‍What About Shared Blind Spots?

This approach has limits. Three agents agreeing isn’t independent evidence if they share the same blind spots, and a mistake one agent tends to make may be one its reviewers tend to miss.

That’s why agent review is one layer among several. Tests also run in the project’s automated pipeline, and a person approves the plan before work begins and the changes before they’re merged. None of this guarantees every defect is found, but it creates additional opportunities to identify problems while keeping people responsible for the final decision.

‍What Does This Look Like on a Real Ticket?

We’ve tested this on real development work, including a change to a food safety and sustainability platform that involved both backend and web applications.

The ticket had 13 acceptance criteria. The workflow reproduced the reported issue and prepared a plan for human approval. It then made changes across both applications and created tests based on the acceptance criteria. The automated review process completed, with draft pull requests opened and supporting evidence added to the original ticket for human review.

The recorded run reported 8,840 backend tests and 13,127 web tests passing. These were passing tests across the two applications, not the number of new tests written for this change. Passing tests also don’t rule out every possible defect.

As we explored in AI Means More Output. Does It Mean Better Work?, counting what’s produced says little about whether it’s any good. What the workflow gives the reviewing engineer is a record of the plan, the checks that ran and the evidence behind them, which makes the final decision better informed.

‍Accountability Still Matters

Passing these checks doesn’t show that the right feature has been built or that every risk has been addressed. Engineers still need to understand the evidence and decide whether the changes are ready to merge. That connects to the changing role of developers we looked at in When AI Agents Write the Code, What Do Developers Actually Do?.

Our approach to AI-native product development is built around that balance. Automation can make quality checks more systematic, while responsibility for the software stays with the people delivering it.

The question isn’t whether AI agents can replace code reviewers. It’s whether they can give us a more consistent, better-evidenced review process, with engineers accountable for the final decision.