Cursor Bugbot Review Guide

Cursor's June 2026 BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. update says average review time is about 90 seconds, down from about 5 minutes; Bugbot finds 10% more bugs per review and costs about 22% less per run. Cursor hasn't published Bugbot's underlying model. Verify before naming one, and treat these figures as perishable.

Knowing what shipped is the easy part. Turning Cursor BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. review into something a team relies on takes a few deliberate steps, mapped below.

1. 1Run BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. on real PR diffs, not as a replacement for tests or code owners.
2. 2Use /review locally before push when a change is risky or security-sensitive.
3. 3Configure model blocklists, effort and incremental review so findings match team risk.
4. 4Treat findings as review evidence; humans still decide what merges.

New capability comes with new ways to get it wrong. Keep these boundaries in place as you adopt it.

BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. is Cursor's AI code reviewer, integrated into GitHub and run on PRs. It is high signal-to-noise: it consistently resolves north of 70-80% of the issues it raises, flagging problems like exposed keys and proposing fixes.

Config knobs

• Which repos BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. operates on.
• Scrutiny level - how hard it looks.
• Per-PR automatic trigger vs manual trigger.
• Autofix on or off (surface-only).

Risk-rated PRs

Pair BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. with a PR-opened automation that classifies risk. Low-risk PRs (e.g. a title change) get auto-approved and merge easily. High-risk PRs require human review and get the right reviewers assigned automatically - the automation uses git blame to find the people who touched that code.

For leadership, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. exposes a 30-day dashboard: PRs reviewed, issues resolved and automatic fixes merged, drillable by repo and broken down by severity (high / medium / low). That is the central ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition. view that justifies running AI review at scale.

Make BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. the merge gate and tier the gating by risk. A finance team that builds inside the company mono-repo - in a dedicated section for accounting apps - runs Bugbot as an AI reviewer over every PR, then lets risk decide who else has to look.

That a machine pass found nothing it recognises. Which is a real saving, and it is not merge approval.

The clip below shows the opposite case, a run that does come back with findings.

The gap is intent. A reviewer, human or otherwise, can say a change looks safe; only the person who asked for it knows whether it is the change they asked for rather than a change that passes. That distinction does not get easier at volume, and it is the reason a clean run reads as a starting position instead of a verdict.

Accountability does not move either. When something merged breaks production, the person who clicked merge owns it.

The honest framing of the win is narrow, and still worth having. You start your read on a diff that has already been swept for the mechanical class of problem, which saves the first stretch of a review and none of the judgment at the end of it.

Tune it in the first week rather than the third month. A reviewer who has learned to skim past the bot's comments is worse off than one who never had it, because those comments now occupy the slot where reading used to happen.

Although tune is the wrong verb for what actually works here. You are not walking a dial toward some correct setting. You are teaching it two or three specific things about this repo and then leaving the rest alone, which is a much smaller job and a much better use of the first week.

Two levers do most of the work. Scrutiny level decides how hard it looks, and repo rules teach it the conventions a general-purpose reviewer has no way to know. Rules are the better lever for a finding that keeps coming back wrong, with the same discipline that applies to any rule: add one once you have seen the finding twice, and keep it short enough that it does not dilute everything else.

Incremental review is the setting I would turn on early. Reviewing only what changed since the last pass stops a second push re-litigating the first, and re-litigation is most of what makes a bot feel noisy, more than any individual wrong finding.

If findings still read as noise after both levers, the problem is probably the PR rather than the reviewer. A very large change hands a bot more surface to be pedantic about, and stacked diffs shrink that surface without touching a single setting.

Three moments, one reviewer's worth of attention between them. /review runs before you push, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. runs on the pull request, and a Vulnerability Scanner runs on a schedule against code that is already in.

The local pass is the cheapest habit on that list. /review and /review-security are available in Cursor 3Cursor's agent-forward interface (also called the agent window or Glass), built to run and supervise many agents at once rather than edit one file. Press Enter for the full definition..7+ and in the signed-in web app at cursor.com/agents, with CLI support still to come. /review-security compares your branch against the default base branch and includes uncommitted work, so say which branch you mean when your base is not the default.

The scheduled half is a different agent type rather than a BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. setting. Cursor's Security Reviewer takes git triggers and checks pull requests before they merge; the Vulnerability Scanner takes cron triggers and goes looking for what PR review never saw. Both run on Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., both need at least one tool or MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. to run at all, and usage bills to the team pool under a shared service account rather than to a person.

On a small team I would run the local pass and stop there. A scheduled scanner starts earning its keep once the codebase is older than the review habit, which is to say once there is a body of code nobody currently reading PRs ever reviewed.