AI Code Review Process: Three Layers per Pull Request
Summary: On VAON projects that follow our 10-step workflow, every pull request passes three reviews in a fixed order. The author re-reads the change, AI reviews it against the project's own criteria, then a second engineer approves and the team lead decides the merge. The main branch is protected, and you can see the review records.
Contents
- What is three-layer pull request review, and why does the order matter?
- Why does the author review before AI does?
- What is AI review good at, and why is it not the last layer?
- What are the second reviewer and the team lead accountable for?
- Which review records can you see?
- When are three layers not enough?
- FAQ
1. What is three-layer pull request review, and why does the order matter?
Three-layer pull request review at VAON means the same change is read three times, each time by a different party with a different purpose. A pull request (PR) is a request to merge a code change into the main branch.
The order is self-review, AI review, then a second human. It runs from the person who knows the context best to the person whose time is scarcest. Each layer clears work for the next, so the last can focus on one question: does the code do what the business needs?
| Layer | Who | Good at | Weak at | Leaves behind |
|---|---|---|---|---|
| 1. Self-review | PR author | Knows the task, spots out-of-scope edits | Own blind spots | PR description and reason |
| 2. AI review | Claude, using project criteria | Reads every line evenly, catches pattern issues | False alarms, misses, no business context | Comments saved in the PR for a person to filter |
| 3. Second human | Another engineer; team lead decides merge | Checks the spec, judges design | Limited time, skims large PRs | Comments, approver name |
Three-layer review is one step of our Claude Code development workflow, which VAON applies to most projects, not yet all. Branch protection and client-visible review and test records apply to every project.
2. Why does the author review before AI does?
The PR author reviews first because they are the only person who knows what the change is meant to do. With Claude Code, this is often the first time a human reads the whole change.
The question is simple: can I explain every part of this? A block the author cannot explain does not move on. AI review at that point only adds comments to code nobody understands.
Self-review also catches a common AI habit: changing more than was asked. For example, the AI tidies a shared file while it is there. The author, who knows the scope, sees it at once.
The author also reads the tests in the PR; see AI-generated tests in the pull request.
3. What is AI review good at, and why is it not the last layer?
AI review sits second because AI reads fast and evenly, but only helps with specific criteria. At VAON, Claude reviews each change against the project's review criteria, not a generic "please review this" prompt.
AI is good at what tired people miss: a swallowed exception, a new endpoint with no permission check, a call to an API that does not exist. What a human should check in AI code is covered in how to review AI-generated code.
AI review is not the last layer for two reasons. It raises false alarms that a person must filter. It can also miss things, especially code that is technically fine but contradicts the spec.
With small issues cleared first, the second reviewer spends their time on what only a person can judge.
4. What are the second reviewer and the team lead accountable for?
The second reviewer is accountable for checking the change against the spec, and the team lead is accountable for the merge decision. Here a named person owns the decision.
The second reviewer did not write the code and does not share the author's assumptions. They see what both the author and the AI missed. An illustration: the spec says orders cancelled after delivery get a partial refund. Code that refunds in full still runs, and tests written from the code still pass. Only someone who read the spec sees the error.
"No approval, no merge" is enforced by the platform, not by goodwill. On GitHub, branch protection lets you require a set number of approving reviews before a pull request can merge. Once enabled, nobody merges without approval, even on deadline.
5. Which review records can you see?
Every VAON project keeps review and test records the client can see. Per pull request, they show:
- What changed and why (the PR description).
- Review comments and how each one was handled.
- Who approved and who decided the merge.
- Automated gate results: secret scanning, dependency scanning, static analysis.
In 2026, "Who checks the code that AI writes?" was one of the three questions clients asked VAON most. A tool name does not answer it. A real pull request does: you open it and see who read it, who approved it, and which gates ran. Our CTO and a Tech Lead are involved in every project, so someone with authority can explain any merge.
Record formats differ between projects, so raise any specific need at kickoff. Before release, each version also passes a separate gate, described in pre-release security review for AI code.
6. When are three layers not enough?
Three layers reduce escaped defects, but VAON does not treat them as a guarantee. Three cases are worth knowing.
- You have not allowed code into AI tools. AI review does not run; the other layers and gates remain.
- The pull request is too large. Reviewers skim. Smaller PRs fix this.
- The spec is not locked. The second reviewer has nothing to check against.
For very small changes, like one line of text, earlier steps are shortened, but branch protection and automated gates stay. Review does not replace acceptance testing against your checklist.
7. FAQ
Can AI review replace a human reviewer? No. At VAON, AI review is an extra layer, not a replacement. AI reads evenly against the project's criteria, but it raises false alarms and can miss business logic errors, so a person always filters its comments. The merge decision belongs to the team lead, after another engineer has approved.
What if I do not allow my code to go into AI tools? If you have not given permission, VAON does not put your code into AI tools and the AI review layer does not run. Each pull request still gets self-review, a second engineer's approval and the team lead's merge decision. Automated gates still run on every PR, and the main branch stays protected.
Where can I see the review records? Every VAON project keeps review and test records, and you can see them. The code can live in your own repository from day one. Per pull request you see the description, review comments, approver and gate results. If you need a specific format for internal audit, tell us at kickoff.
Do three review layers slow the project down? Each pull request takes extra reading time. In return, defects are caught while they sit inside one small change, before they mix with other work. The order cuts waste: the author and AI clear what they can, and the second human focuses on business logic. VAON does not promise a specific time saving.
Who is responsible if a defect gets past all three layers? Responsibility is defined in each project's contract. VAON does not treat "the AI wrote it" as a reason for responsibility to change. AI-written code goes through the same review and testing as code written by people. When an incident happens, the review record shows both sides which change caused it, who approved it and which gates ran.
One thing you can do today: ask your development team to open a recently merged pull request and point to three things. Who re-read it, which AI comments were dismissed and why, and who approved it. If nobody can, the review lives in memory, not in a record.
To see how three-layer review would work on your project, book a free 60-minute consultation. Our CEO joins, you need no documents, and there is no commitment.
