An AI review bot sees the diff and whatever context its tool gathers. It does not know why the change exists, whether now is the right time to build it, or what your team agreed in a hallway. Treat it as a fast first pass, and keep design and intent with a human.
Intent is not in the diff
A pull request shows what changed. It rarely shows why. Google's public engineering practices say the most important thing a reviewer covers is design, and they pose a question a bot cannot answer from code alone: is now a good time to add this functionality?
A bot can tell you a function is long or that a null check is missing. It cannot tell you the feature should live in a shared library, or that another team is about to replace the module.
Some files are never read
Tools differ, but they often skip file types on purpose. GitHub's documentation for Copilot code review says it does not review dependency management files such as package.json, log files or SVG files. That matters for security, because a dependency manifest is where a risky package arrives.
Check the documentation of whatever bot you run and write down the exclusions. Then make sure another control covers those files, such as a human reviewer or a dependency scan.
Coverage is not guaranteed
The same GitHub page states that Copilot is not guaranteed to spot all problems, and that it will make mistakes. It advises validating its feedback and supplementing it with a human review. That is a vendor telling you not to rely on the bot alone, and it is a fair reading for any tool in this class.
Re-reviews are another gap. The page says that unless configured to review each push, Copilot reviews a pull request only once, and you must request another review after later changes. A clean first review can sit on top of a very different final diff.
What to keep for people
Reviewers at Google are asked to check design, functionality, complexity, tests, naming, comments, style, consistency and documentation. A bot can help with the mechanical items. The ones that need a person are:
- Does the change belong here, and does it fit the system around it?
- Are the edge cases and concurrency risks real, given how the code is used?
- Will the tests actually fail when the code is broken?
- Is the documentation updated for users and future maintainers?
A simple split
Let the bot handle first-pass comments on style, obvious bugs and missing tests. Let people own design, risk and the merge decision. Write the split down in your contributing guide so authors do not treat a green bot comment as approval.
If you want dependency changes covered even where a review bot does not look, Safeguard can scan dependencies and SBOMs and apply policy gates in the pull request. There is also a free scan at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Quick check
Can an AI review bot replace a human reviewer?
Not on the evidence of vendor documentation. GitHub says Copilot review should be supplemented with human review, and design and intent are not visible in a diff.
Why list the files a bot skips?
Skipped files, such as dependency manifests, are where changes can go unreviewed unless another control covers them.
Sources
Last reviewed: 19 October 2026.
