An AI reviewer works best before a human reviewer starts. It can catch routine bugs, point out missing tests and question risky changes while the author still has the code in mind.
It cannot approve product intent, accept risk for the team or prove that a change is safe. Keep a person responsible for the merge.
This workflow gives the AI a useful job without turning the pull request into a comment dump.
1. Open a reviewable pull request
The reviewer needs more than a diff. Give it a clear pull request description with:
- the problem
- the intended behavior
- the main design choice
- the risky parts
- the tests you ran
- any known limit or follow-up
Do not write “fixed login” and expect a model to recover the product rule. State whether sessions should expire, which users can log in and what should happen after a failed attempt.
Use the pull request description template if your team has no shared format. Large changes should be split before review. The guide to splitting AI-generated pull requests also works for large human-written changes.
2. Run deterministic checks first
Run the compiler, tests, formatter, linter, secret scanner and dependency scanner before the AI review.
These tools answer narrow questions with repeatable results. A model should not spend tokens finding a type error that tsc reports in a second. It also should not replace a dependency scanner that checks a known vulnerability database.
Publish the check results in GitHub. The AI reviewer and the human reviewer can then focus on behavior, missing cases and repository rules.
The AI code review versus static analysis comparison explains where these checks overlap and where they do not.
3. Give the AI repository context
A raw diff hides the code that did not change. The reviewer may need to read a caller, schema, shared type, test fixture or configuration default before it can judge the patch.
Use a reviewer that can search or index the repository. If the tool supports instruction files, add the rules that are specific to your codebase.
Good review rules name a condition and a place to check it:
Every query that returns workspace data must include
workspaceIdin the database condition.
Weak rules use broad phrases:
Follow security best practices.
The first rule can be checked. The second invites generic comments. See the natural-language review rules guide for more examples.
4. Request the AI review at the right time
There are three common trigger points.
Review the draft
Run a draft review when the author wants early feedback. This works well for a large refactor or a security-sensitive change. The branch may still move, so avoid a full review after every small push.
Review when the pull request is ready
This is the best default. The author has finished the first pass, the checks are green and the description is stable. Automatic review keeps the process consistent.
Review new pushes
Run another review after a major change, not after every typo fix. Some tools support incremental review and only inspect the new commits. That saves time and reduces repeated comments.
If you use GitHub Actions for the trigger, protect secrets from untrusted fork code. The GitHub Actions AI review guide covers token permissions and safe event choices.
5. Triage the comments
Treat each AI comment as a claim to check.
A useful comment should answer four questions:
- What can fail?
- Which code creates the failure?
- What repository evidence supports the claim?
- How can the author prove the fix?
Resolve comments in this order:
- correctness and data loss
- authorization and security
- compatibility and migrations
- reliability and error handling
- performance with a clear cost
- maintainability with a concrete future failure
Dismiss style comments that a formatter or team convention already handles. Ask the reviewer for evidence when a claim depends on code outside the diff.
Wrong comments need attention too. Record them so you can change instructions, filters or the tool. The post on AI code review false positives gives a process for this.
6. Check the proposed fix
An AI-generated fix can remove the symptom while keeping the bug. It can also break a caller that was not in the prompt.
Before you apply a suggestion, check:
- whether it preserves the intended behavior
- whether it handles the failure path
- whether it changes a public contract
- whether it needs a migration
- whether the test fails without the fix
Run the full relevant test set after the change. If the AI wrote both the code and the test, check that the test does not repeat the same assumption. The guide to reviewing AI-generated tests shows common weak patterns.
7. Hand the pull request to a person
The human reviewer should receive a cleaner pull request. It still needs human approval.
The person still needs to judge:
- product intent
- architecture
- acceptable risk
- rollout and recovery
- missing organizational context
- whether the change should exist at all
Keep required approvals in branch protection. An AI review comment is evidence for the human review, not an approval.
8. Measure whether the AI review helps
Review tools consume money and attention. Measure both.
Track:
- useful bugs found before human review
- wrong comments
- comments nobody acts on
- repeated comments after new pushes
- time from PR open to first useful feedback
- time a person spends checking AI claims
- escaped bugs that the AI had enough evidence to find
Check the numbers by repository. A reviewer can be useful in a backend service and noisy in a generated client library.
Start with a two-week trial on one or two repositories. Keep the tool if it removes work from human review without adding more investigation than it saves.
A compact GitHub workflow
Use this sequence as a starting point:
- The author opens a pull request with a real description.
- CI runs tests, types, lint, secret scanning and dependency scanning.
- The AI reviewer reads the diff and relevant repository context.
- The author fixes or dismisses each supported finding.
- CI runs again.
- A human reviews intent, design, risk and the final code.
- GitHub branch rules enforce the required approval and checks.
For an automated first pass, compare the best AI code review tools for GitHub. If you want a GitHub reviewer that you can host yourself, Scopy's quickstart covers the managed path and the self-hosting guide covers your own infrastructure.