Cursor Agent Review: Quick vs Deep Diff Review After Agent Edits

There are three ways to kick off a review, and they differ mainly in scope. You can run it automatically after every commit, on demand with /agent-review for the current session, or from the Source Control tab against your full local diff. Pick the trigger that matches how much work you want checked at once.

Leave the automatic setting off at first. It runs after every commit Agent makes, which on a normal afternoon is a lot of commits, and a review that fires on half-finished work returns findings about half-finished work. You learn to skim them, and skimming is how the one that mattered goes past. Switch it on once your commits are the size you would show somebody.

The Source Control run sits at the other end of that range. It compares every local change against your main branch, so it reads the feature the way a reviewer will rather than the way you built it, one commit at a time. Cursor's docs make that the point of it: catching issues across the full set of changes, not only the latest edit.

Match the depth to the risk. Quick is fast and cheap for formatting and small diffs you just want a sanity pass on. Deep costs more and runs slower, so save it for complex logic, security-sensitive code or a large refactor where a missed bug is expensive.

That table gives you speed and cost and leaves the actual decision alone. My read is that Deep earns its price whenever a miss would be expensive to discover later, which is a different question from whether the diff is large. A forty-line change to auth logic clears the bar. A four-hundred-line rename does not, because the compiler and the test suite already cover the failure you would be paying a Deep review to find.

On a small team, running Deep on everything and eating the cost is a defensible way to avoid a decision nobody has time to make. I used to think that scaled. It does not: once the bill reflects thirty people's habits rather than three, somebody has to write the cases down next to the rest of your review standards, so the depth call stops being made fresh by each engineer every time.

Agent Review loads repository rules from `.cursor/BUGBOT.md` (same family as BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. PR review). Keep team standards there: forbidden patterns, required tests, security checks. Agent Review is pre-commit/local; Bugbot still covers PRs on the remote. Use both when you want local self-review plus team-visible PR gates.

What belongs in that file is the material a reviewer would need to know your team to catch: the pattern you banned after an incident, the two directories where the old conventions still apply. What does not belong is anything a linter already enforces. A rules file that restates your ESLint config makes every review longer and none of them better.

Agent Review runs inside your IDE on local or just-committed work. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews pull requests on GitHub/GitLab with team policies and merge gates. Agent Review catches issues before push; Bugbot enforces standards for the whole team on shared branches.

The usual advice about AI code review, that you wire it in as a merge gate, does not describe this half of it. Agent Review has no merge button to hold. It runs on your machine, on work that has not left it, and its output is a list you are free to close. Treat it as the thing that stops you pushing an obvious mistake, and keep the gate on the pull request where the rest of the team can see it.

The trigger decides it for you. /agent-review reads the current session's changes before you commit, the automatic setting runs after each commit Agent makes, and Source Control reads everything against main whenever you ask. Committing first is not a problem here, since none of it has been pushed.

In the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. the commit happens in the review pane itself, including onto a branch you create at that moment. Those mechanics live on the Agents Window page rather than here. Land agent work on its own branch when the change is the kind you might want to abandon cleanly, which covers most of what an agent produces on a first pass.

Every agent change is inspectable through a review button that shows all edits made. The bet behind keeping that transparent rather than a black box is simple: the more code AI generates, the more of it needs reviewing, and that step becomes the constraint. Expect Cursor to keep investing in code review heavily. Always read generated code. It's also where you learn the most.

That framing has an uncomfortable edge to it. How much code you can safely ship now depends on how fast you can read, and reading speed is not a quantity that improves when you buy better tooling. The practical response is smaller diffs rather than fewer of them. A task scoped to one reviewable change is worth more than a task that succeeded and produced five hundred lines.