Reviewing changes in Cursor exists in three layers, and they do not replace one another. A local review in the agent looks at the branch or the uncommitted edits and returns findings straight into the conversation - before anything has gone into the shared repository. Automated review works on the pull request, takes updates and existing comments into account and leaves remarks with suggested fixes. The human remains the owner of the architecture, the product intent and the acceptance of risk - of everything not written down in the code.
The naive model treats these layers as competitors and picks one. In practice they cover different windows of time, and the cost of a finding differs in each window. Local review is the cheapest: the edit is not published, the history is not rewritten, nobody has spent time reading it. Automated review catches what is visible only on the change as a whole: inconsistency between files, a forgotten branch of logic, stray leftovers that slipped into the set. The human sees what neither of them sees: alignment with intent and whether the risk is acceptable for the product.
It helps to lay the layers out in a table once: what goes in, what comes out and when the layer belongs. Below is that map - from local review to human review. It answers the frequent question of why we need both: because their input and their moment differ, and so, therefore, do their findings.
| Layer | Input | Output | Best moment |
|---|---|---|---|
| Local agent review | The branch or uncommitted changes | Findings in the conversation | Before pushing to the shared repository |
| Automated review | The pull request diff and comments | Inline remarks and a check status | On every update or on request |
| Security check | A pull request or the codebase at rest | Security findings and issues | Before merging or on a schedule |
| The human | Intent, changes, evidence and context | Approval, requested changes, a deliberate exception | Before merging and deployment |
Automated review has details worth knowing before you build a process on it. It can be started manually by a comment, and its result is neutral by default - that is, by itself it does not block merging over findings. For a review to actually stop a merge, a separate organizational setting is required that fails the check on unresolved remarks. Without it a green or neutral mark does not mean everything is clean; it means only that the check ran.
That is the main warning: a green check is not completeness. Success of an automated review means the absence of new and unresolved remarks by its own rules. It does not prove that all tests passed, that the threat model has been considered, that performance did not regress and that the product agrees with the change. Taking it for a general sign of readiness is the most common way to miss a problem nobody was looking for.
The practical sequence builds itself. Local review before pushing - so as not to carry the obvious into the shared repository. Automated review on the pull request - to get a fresh look at the whole change. A specialized security check where authorization, trust boundaries or data handling change. And a human before merging - always, because the decision to accept risk cannot be automated.
On a single change this looks unremarkable. You edit the handling of uploaded files, run the local review and get two findings: an unclosed stream and an error handler that swallows an exception. Both are fixed in a minute, and they never reach the shared repository at all. On the pull request the automated review spots a third one - that the new branch of code bypassed the shared permission check, because it sees the change as a whole. And the human asks a fourth question nobody asked: is this upload needed at all, when a similar mechanism already exists next to it. Four findings, three different layers, and none of them found what the others did.
Hence a way to tell which layer you are missing: look at where defects are found. If the remarks on pull requests are mostly small and obvious, nobody is using local review, and human attention goes to what should have been filtered out earlier. If problems surface after merging and they are misunderstandings of the task rather than of the code, the human layer is formal: changes are approved without being checked against the intent. And if what surfaces in production is something no layer was looking for, then the specialized check is missing, and its absence is worth admitting explicitly instead of assuming that review replaces it.
The engineering conclusion is simple: the layers add up rather than compete. Each is cheap on its own, and together they give different coverage. Dropping any layer costs exactly what that layer used to catch - and that usually becomes clear not at the moment of dropping it but several months later, in a specific incident, when the connection to the decision is no longer obvious.
The typical failures are predictable. Replacing human review with an automated one and considering the matter closed. Taking a neutral check result as confirmation of cleanliness. Running a heavy review where a local one before pushing would have been enough. Debating on a pull request what is caught in a minute on your own machine. And not enabling the organizational setting while expecting the check to block a merge.