Yes, when AI review is one layer among several and not the only gate. An AI reviewer can read every pull request at any hour and catch missed cases, unsafe patterns and unclear code. It can also be wrong or be misled, so the safe setup keeps tests, branch protection and a person for risky changes around it.
What AI review does well and what people do better
| Task | AI reviewer | Person |
|---|---|---|
| Spotting missed edge cases and small mistakes | Strong | Good, but tires |
| Checking every change against your rules, every time | Strong | Varies from day to day |
| Judging whether the change is the right product decision | Weak | Strong |
| Noticing a risk that is not in the code, such as a contract or a deadline | Weak | Strong |
Use that split to decide where a person must stay involved. Routine checks go to the AI. Judgment calls stay with people.
Five layers around every pull request
No single check should carry the decision. A safe setup stacks layers that each catch something the others miss, and the pull request has to pass all of them in order.
- Automated checks: lint, build and tests give a pass or fail that nobody can argue with.
- Reviewer agents: separate agents read the change and comment on what looks wrong.
- Fix loop: findings go back to a fixer, and the checks and reviewers run again.
- A person: someone you named approves changes in the areas where a mistake is costly.
- Branch protection: your code host enforces required checks and reviews, whatever any agent says.
The risks to plan for
- A false approval: the reviewer says the change is fine when it is not.
- Being misled: text hidden in a ticket, a comment or a file can try to steer the reviewer. OWASP lists prompt injection as the first risk in its list of risks for applications built on large language models.
- Too much access: a reviewer that can read secrets or change production can do harm if it is misled.
- Marking its own homework: an agent that reviews the code it wrote tends to agree with itself.
A safe setup, step by step
- Separate the author from the reviewers. The agent that wrote the change never approves it, and more than one reviewer is better than one.
- Let reviewers comment, not edit. Findings go back to the author to fix, so every change has one owner.
- Keep automated checks as the gate. Tests, type checks and quality checks must pass again after every fix. On GitHub, branch protection can require passing checks and approving reviews before anything merges.
- Limit access. Run the agents in a sandbox with no production secrets and only the permissions the work needs.
- Choose where a person must approve, such as sensitive areas of the code and the production release.
- Keep a record. Every review comment, fix and approval should be visible on the pull request.
A worked example: a refund endpoint
An illustrative ticket, PAY-301, "Add a refund endpoint": an agent builds it and opens a pull request. This is what each layer does with it.
| Layer | What it did | Result |
|---|---|---|
| Automated checks | Lint, type check and tests ran. A test for a negative refund amount failed. | Sent to the fixer. One commit later the second run passed. |
| Reviewer agents | One reviewer noticed that the endpoint never checks that the user may refund this payment. Another tried to break it and found that a refund could be larger than the original payment. | Two findings, written as comments on the pull request. |
| Fix loop | The fixer added the permission check and the amount limit. The checks ran again and the reviewers read the new version. | Both findings closed, every check green. |
| A person | The change touches the payments folder, which is on the approver list. The approver sees the findings, the fixes and the passing checks in one place. | Approved, or sent back with a comment. |
| Branch protection | Your code host still requires its checks and its review. | The merge is allowed only because all of them passed. |
Notice that the reviewers never edited the code, and that no single layer approved the change alone. In a case like this, the two findings are the kind a tired person skims past on a Friday afternoon.
What happens inside the fix loop
A finding goes to a fixer agent together with the exact comment or failing log. The fixer changes the code, the checks run again and the reviewers read the new version. This repeats until everything is green.
Two safeguards keep the loop honest. If a fix stops getting closer to green, or the risk of the change goes up, the run stops and asks a person instead of trying again. And a test that fails at random is retried and repaired automatically, so one unreliable test does not block a good change.
How Dutopilot does it
In Dutopilot, separate Dutopilot virtual team members, who did not write the code, read each pull request. What they find goes to an automatic fix step, and the tests and quality checks run again before anything merges. The code is processed in a sealed sandbox, and your own branch protection and required reviews keep applying unchanged.
People decide the architecture before code is written and the production release, and you can add approvals anywhere else. Every run leaves a trail in your pull requests. See which steps need a person's approval for how to choose.
What reviewers are allowed to do
- They read the change and the code around it, and they write comments. They do not push code.
- They run in a sealed sandbox with no production secrets.
- They are different Dutopilot virtual team members from the one that wrote the change, so none marks its own homework.
- A single reviewer opinion never merges anything alone. Approvals and merge happen only where you chose, and the automated checks and your branch protection decide.
What you set up
- Branch protection on your main branch, with the checks you already run marked as required.
- A list of approvers, and the parts of the code, such as payments or sign-in, that always need one.
- The strictness you want: which kinds of problem reviewers should block on and which they should only mention.
What your Forward Deployed Engineer does
Every Dutopilot customer gets a Forward Deployed Engineer: an engineer from Dutopilot who works with your team. They do not write your product code. They make review fit your codebase and your habits.
- They tune what the reviewers look for in your codebase, such as your security rules and naming conventions.
- They choose with you which parts of the code need a named approver.
- They read the first month of review results with you: what the reviewers flagged, what people flagged afterwards and what slipped through.
- They tighten or loosen approvals based on that record, and keep tuning as your code and team change.
How to tell whether it is working
Keep a simple record for the first month. For each pull request, note what the AI reviewer flagged, what a person flagged afterwards and whether anything slipped through to a later fix. If people keep finding real problems the AI missed, tighten the setup. If the AI findings are mostly noise, adjust what you ask it to look for before you trust it with more.
Start small and widen
Begin with AI review on a low-risk part of the code, with a person still approving every merge. After a few weeks, look at how often the AI found real problems and how often it missed one that a person caught. Loosen approvals where the record is clean, and keep them where it is not.
Frequently asked questions
Should AI review replace human review?
Not for changes that are costly or hard to undo. Let AI catch the routine problems so people spend their time on judgment, such as whether the change is the right one.
Can an AI reviewer approve and merge on its own?
Only where you choose, and only for low-risk changes. Approvals and merge happen only where you chose them, and a single reviewer opinion never merges alone: the automated checks and your branch protection stay the gate. Start strict and loosen only after you have seen the results.
What about secrets and customer data?
Keep them out of the reviewer's reach. In Dutopilot, code is processed in a sealed sandbox, we never keep a copy of your repository, and run logs and check results are deleted after 90 days.