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

There are three ways to start a review. It can run automatically after every commit, on demand when you type /agent-review, or from the Source Control tab against all your local changes. Of the three, only the Source Control run has a scope that Cursor's docs spell out.

Leave the automatic setting off at first. Cursor's page says it runs after every commit in one section and after every agent task in another. Either way, a normal afternoon of agent work means a lot of reviews, 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 finding that mattered slips past. Switch it on once your commits are the size you would show someone.

Use the Source Control run before you open a pull request. It compares every local change against your main branch, so it reads the feature the way a reviewer will, instead of one commit at a time the way you built it. Cursor's docs give that as its purpose: catching issues across your full set of changes, not only the latest edit.

Match the depth to the risk. Quick is fast and low-cost, for formatting changes and small diffs that need a sanity check. Deep is slower and costs more, so save it for complex logic, security-sensitive code or a large refactor where a missed bug is expensive.

The table gives you speed and cost, but not the decision. In our view, Deep earns its price when a miss would be expensive to discover later, which is a different question from how large the diff is. A forty-line change to auth logic clears that bar. A four-hundred-line rename doesn't, because the compiler and the test suite already catch the failure you would be paying Deep to find.

On a small team, running Deep on everything and accepting the cost is a reasonable way to skip a decision nobody has time for. That stops working as the team grows. Once the bill reflects thirty people's habits instead of three, someone has to write down when to use Deep, next to the rest of your review standards, so each engineer stops making the call fresh every time.

Repository rules come from .cursor/BUGBOT.md files, the same files BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. uses when it reviews pull requests. Keep team standards there, such as forbidden patterns, required tests and security checks. Agent Review runs locally, before you push, and Bugbot still covers pull requests on the remote. Use both when you want a local review plus a pull-request gate the team can see.

Put in that file what a reviewer would need to know your team to catch: the pattern you banned after an incident, or the two directories where old conventions still apply. Leave out 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 Cursor 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 and the other code hosts it supports, with team policies and merge gates. Agent Review catches issues before you push, and Bugbot enforces standards for the whole team on shared branches. On The X SubscriptionThe subscription Cursor is sold through: one plan for Grok, Cursor and X, with Free, Plus, Premium, Super and Ultra tiers, per-seat Teams, a weekly included pool for Cursor models shared with Grok, and third-party models billed at API list price from prepaid credit. Press Enter for the full definition., Bugbot starts at the Premium plan.

The common advice to wire AI code review in as a merge gate doesn't fit Agent Review. It has no merge button to hold: it runs on your machine, on work that hasn't left it, and its output is a list you are free to close. Use it to catch an obvious mistake before you push, and keep the gate on the pull request where the rest of the team can see it.

The trigger decides it for you. The automatic setting runs after each commit, while /agent-review and the Source Control run start when you ask, before a commit or after one. Committing first does no harm here, because 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., you commit from the review pane itself, including onto a branch you create at that moment. The Agents Window page covers how. Land agent work on its own branch when you might want to abandon the change cleanly, which covers most of what an agent produces on a first pass.

The more code AI writes, the more of it someone has to review, so review becomes the step that limits how fast work ships. Cursor engineers made that case in webinars and said to expect Cursor to keep investing heavily in code review. In the product, every agent change can be inspected through a review button that shows all the edits made.

Their advice is to read generated code every time, because that is also where you learn the most.

That framing has an uncomfortable consequence. How much code you can safely ship now depends on how fast you can read, and better tooling doesn't make you read faster. 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.