Detection is getting good tools.
GitHub says Copilot code review can inspect a full repository, identify issues, suggest fixes, and pass a suggestion to a coding agent. The extra context and tool use run through GitHub Actions. If that path is unavailable, the review still runs with fewer capabilities.[1]
Cursor launched a separate Security Review bot on September 23. Its announcement says the bot follows input into SQL, command, and template sinks. It also checks authentication, authorization, secrets, redirects, deserialization, and dependency changes. Cursor keeps style and code quality in another bot.[2]
That division is useful. A machine can apply the same detection routine to every pull request. Teams should use it. The mistake is treating that routine as the whole review.
A person can fail to understand the change.
John Allspaw argues that a reviewer's confusion carries information. The code may be too complex. The abstraction may be wrong. The intent may be missing. A system that can always produce an explanation does not reproduce the friction felt by the person who must maintain the code later.[3]
If an experienced reviewer cannot explain the change, the change has failed a maintenance test.
Google's review guide makes the same pressure concrete. It asks whether the change belongs in the codebase, whether now is the right time, whether the design fits the system, and whether every line is understandable. It tells reviewers to stop and ask for clarification when code is too hard to read.[4]
The missing part may live outside the repository.
A repository can hold code, tests, design notes, and recent incidents. It rarely holds every current agreement. A downstream team may be retiring an interface. Legal may have changed a logging rule. The service may have failed in a way that no test fixture records yet. A reviewer can connect the diff to that live context.
Automation can search the context it receives. It cannot discover an agreement that nobody wrote down. This is not a reason to keep context informal. It is a reason to capture the missing fact in the review, then move it into the repository or operating record.
Use the bot report as an input.
Run automated review early. Let it handle repeatable checks and candidate defects. Then ask a human to judge the change's purpose, shape, omissions, and owner. The human should be allowed to ask a question without first proving a bug.
The brake below turns that pass into a copyable question map. Selecting every lane means four judgments have been recorded. It does not mean the code is correct, the tests passed, or the change can merge.