Tuning Cursor Bugbot to match what your senior reviewers say

Last checked: 21 Oct 2026. The product facts below come from Cursor's own Bugbot documentation, Bugbot release notes, AI code review guide and enterprise docs, with GitHub's branch protection documentation and DORA's capability pages for the review and measurement points.

Cursor Bugbot earns its place when it is tuned to flag the problems your senior reviewers already raise, and it becomes noise when it comments on things your team does not care about and is judged by how many comments it leaves. The order we recommend is to write one or two of your seniors' recurring review comments as Bugbot rules, check for a week whether its findings get fixed, and only then widen what it comments on. One point catches teams out: requiring the Bugbot check in branch protection proves the review ran, but on its default settings it does not stop a pull request merging with findings open.

What Bugbot does on a pull request

Cursor's docs say Bugbot "reviews pull requests and identifies bugs, security issues, and code quality problems". It reads the diff and leaves comments with an explanation and a suggested fix, running on each update to the pull request or when someone comments cursor review or bugbot run. It also reads the existing top-level and inline comments as context, which Cursor says lets it "build on prior feedback from reviewers" (Bugbot docs). Your senior reviewers' comments are therefore already an input.

On its code review page, Cursor says Bugbot looks for logic errors such as likely null pointer exceptions, race conditions, missing error handling and security issues, and leaves formatting and simple patterns to linters. That is Cursor's description of its own product, so test it on your code.

Sources: Bugbot docs, security agents docs and the release notes for the week of 5 Oct 2026. These labels changed within the last month.

Where automated review helps and where it creates noise

Cursor's AI code review guide (12 Aug 2026) says noise "comes from comments people do not want from a bot": style nags, vague requests to add tests with no failing test behind them, and rewrite suggestions that do not catch a bug. It places AI review on the residue other tooling misses, such as logic errors, race conditions and authorisation mistakes, and says it overlaps CI without replacing it.

In practice, automated review helps most with the bug a tired reviewer skims past, and frees seniors for design, product risk and system knowledge the model lacks. It creates noise when it comments on things your team has decided not to care about, or repeats what your linter and type checker already enforce.

Pull request size matters. Bugbot skips a review entirely when a pull request changes more than 100,000 lines or 3 million characters, and skips individual files that are too large (release notes, weeks of 31 Aug and 21 Sep 2026). DORA's guidance on working in small batches says "large changes are difficult to review, test, and integrate safely". For a comparison with another product, see what Claude Code's security review leaves for a person.

Setting Bugbot up

Start with one busy repository whose reviewers the team trusts, and check three things first.

• Plan and billing. Cursor's pricing page shows Bugbot on Premium, Super, Ultra, Teams and Enterprise, and not on Free or Plus. Bugbot is usage-based on Individual and Teams plans since the May 2026 pricing update, and Cursor publishes an average cost per review on its Bugbot billing help page. Cursor's pages do not say how Enterprise is billed for Bugbot, so ask your account team.
• Your editor rules do not carry over. Cursor project rules (the .mdc files in .cursor/rules/) are not used in Bugbot runs. Bugbot reads .cursor/BUGBOT.md files and rules set in Bugbot Automations.
• Data handling. Bugbot follows the same privacy handling as the rest of Cursor and does not read the contents of files that look like credentials, such as .env and private keys, though source code that hardcodes a key is still reviewed. Its region depends on where your repositories are hosted (data governance docs).

On contracts, Cursor's site footer now links subscription terms from SpaceX Super Intelligence (SpaceXSI) alongside Cursor's own, following Cursor's 14 Aug 2026 announcement that it had been acquired by SpaceX. Arrangements are still moving, so read Cursor's current Terms of Service and the linked subscription terms before you sign. Our guide to SpaceXSI for UK business explains how the products fit together.

Calibrating Bugbot against your senior reviewers

Cursor documents the parts of a calibration loop but not a sequence. The routine below is ours. Its basis is Cursor's own advice to run Bugbot for a week, see which comments are valuable, and start a rules file with "one or two issues that come up repeatedly in your reviews" (Cursor code review page).

1. Collect what your seniors actually say. Take recent review comments from the two or three reviewers the team trusts most and group them. Look for the points that recur, such as a missing permission check.
2. Write the top one or two as specific rules. Cursor notes that "follow best practices" produces vague feedback.
3. Put them in .cursor/BUGBOT.md. Bugbot reads the root file and any nested BUGBOT.md files on the path to the changed files.
4. Prove they loaded. Comment bugbot run verbose=true on a pull request. Bugbot posts a table of every rule it included and flags any that were truncated or left out.
5. Watch for a week. Cursor's guide recommends watching resolution for a week before deciding which categories deserve more volume.
6. Correct it in the thread. Cursor's post on learned rules (8 Apr 2026) names the signals Bugbot learns from: downvotes, replies explaining what was wrong, and human review comments that flag issues Bugbot missed. Ask seniors to downvote and reply rather than silently resolve.
7. Prune by acceptance. Rule analytics show issues found, pull requests reviewed, accepted issues and acceptance rate for each rule. Cursor does not say what a good rate is. A rule that is rarely accepted costs reviewers attention.

Commenting @cursor remember followed by a fact saves it as a learned rule. Learned rules build up, so review the list regularly. For how Bugbot rules relate to Cursor's other rules, skills and hooks, see our setup guide for engineering leads.

How the rule layers fit together

Each rule is cut off at 30,000 characters, and the combined rules for a review are capped at 100,000 characters, beyond which some may be left out. Where the learning switch exists, manual rules only apply while learning is on. Verbose mode is how you find out when either has happened (Bugbot docs).

Settings that change how much Bugbot says

• Effort. Low, Default, High and Smart levels trade reasoning time and usage against how many bugs Bugbot may find. They exist only on usage-based Bugbot plans.
• Incremental review. The docs describe reviewing only changes since the previous Bugbot review as the default. Cursor's June 2026 post described full re-review as the earlier default and said it could raise new flags on code already reviewed, so check the setting.
• Repository config file. On GitHub, Bugbot reads .cursor/config/bugbot.yaml. It reads the file from the branch the pull request merges into, so a pull request cannot change how Bugbot reviews itself, and Cursor suggests CODEOWNERS to control who edits it. The docs do not say the same of BUGBOT.md. We recommend putting that under CODEOWNERS too, so a senior reviewer signs off rule changes.

Making the Bugbot check count

Bugbot reports a status check (Cursor Bugbot on GitHub). When it finds issues, the default result is neutral, and Cursor's docs say: "Requiring the status alone does not block merges on findings because findings default to neutral." GitHub's protected branches documentation confirms that a required check passes with a successful, skipped or neutral status.

So requiring the check proves Bugbot ran. It does not make anyone deal with the findings. Cursor's docs add that where a fail-on-unresolved-issues option "is available for your organization", enabling it makes unresolved findings fail the check. They do not say where it is switched on or which plans have it, so confirm with Cursor before designing a process around it.

• Personal overrides. On Teams and Enterprise, members can set Bugbot to run on their own pull requests only when mentioned, and personal overrides rank above repository and team settings. We found nothing in Cursor's docs that lets an admin lock this off.
• Model restrictions. If Enterprise model settings block every model Bugbot can use, the review stops and the check finishes as neutral (model management docs). A model policy change can stop reviews without failing anything.
• Audit trail. Enterprise audit events record when a Bugbot rule is created, updated or deleted, and when Bugbot settings change (compliance and monitoring docs).

Enterprise teams also get a Bugbot API with a dry run that performs the full review without posting anything, a way to test a rule change against a known pull request (dry runs are billed like normal reviews).

Measuring whether it is working

Cursor's main measure is resolution rate: whether a flagged issue was fixed by the time the pull request merged. Its guide says resolution rate beats comment volume, and "if your resolution falls while comment volume rises, the bot is generating noise". Cursor reports that by May 2026 default-effort resolution had reached about 80% of bugs resolved by merge time. That is Cursor's self-reported figure, judged by a language model on public repositories. It is not a false-positive rate, and your own number is what matters.

Cursor's dashboard and analytics API report pull requests reviewed, issues by severity and issues resolved. They do not report how long pull requests wait for review or how often they pass first time. DORA's guidance on streamlining change approval recommends measuring time spent waiting for approval from reviewers. The first two measures below are our suggested definitions, taken from your own source control data, and are not Cursor or DORA metrics.

Take a baseline before you switch Bugbot on and compare after a month. If it is working, we would expect first-pass rate to rise. Our posts on measuring whether AI is working and measuring AI coding tools beyond seat count cover the wider framework.

Why calibration comes before more automation

Cursor offers several ways to act on review findings automatically, and each one multiplies whatever the review says.

• Bugbot Autofix starts a Cursor cloud agent to fix reported bugs and pushes to a new branch (Cursor's recommended mode) or the existing one. It is billed as cloud agent usage and is not available on Azure DevOps or Bitbucket Data Center.
• PR Routing and Approval routes pull requests to reviewers and can approve low-risk changes, using Bugbot's findings as approval signals. It will not approve where Bugbot reports findings that need human review, and Cursor says it "does not replace a full code review" (approval agents docs). It supports GitHub and Origin only.
• Automations can comment, act on reviewers' comments or open pull requests, depending on how they are written. Cursor's template for review comments attempts a minimal fix when a reviewer leaves an inline comment and is told not to approve the pull request. See our post on Cursor cloud agents and automations.

Because approval takes Bugbot's findings as an input, an uncalibrated Bugbot feeds weak signals into that decision (our post on approval design for AI workflows covers who should sign off what). Our view, drawn from that documented dependency, is that a team should show a stable resolution rate and healthy rule acceptance before anything approves or fixes on Bugbot's say-so. Cursor's separate Security Review (Teams and Enterprise, launched 23 Sep 2026) reports exploitable bugs with a proposed fix, and Cursor says "Style and quality stay with Bugbot" (Cursor changelog), so calibration still applies.

Common questions

Does Cursor Bugbot replace human code review?

No. Cursor's own code review guide says AI review changes what humans spend time on, and that it overlaps CI without replacing it. Bugbot is best used to clear logic errors and similar bugs so senior reviewers can concentrate on design, product risk and knowledge of the system.

How do you stop Bugbot adding noise to pull requests?

Write one or two rules from comments your senior reviewers make repeatedly, put them in .cursor/BUGBOT.md and confirm they loaded with a verbose run. Watch resolution rate for a week before widening, and remove rules with poor acceptance. Cursor's ordinary editor rules do not apply to Bugbot.

Can Bugbot block a merge?

Not on its default settings. Requiring the Bugbot check in branch protection makes sure Bugbot ran, but findings default to a neutral result, which a required check accepts. Cursor's docs describe a fail-on-unresolved-issues option that makes unresolved findings fail the check where it is available for your organisation, without saying which plans have it, so confirm with Cursor.

Which source control platforms does Bugbot work with?

As at 21 Oct 2026, Cursor's docs list GitHub including Enterprise Server, GitLab including self-hosted, Bitbucket, Azure DevOps Services and Cursor's own Origin. Bitbucket Cloud and Azure DevOps are labelled public beta. Bitbucket Data Center needs a Teams or Enterprise plan and supports automatic reviews only.

How do you tell whether AI code review is working?

Use Cursor's resolution rate and per-rule acceptance rate to judge the findings. For delivery, we suggest two measures from your own source control data: review turnaround (time to first substantive human review) and first-pass PR rate (share of pull requests approved without another round of changes).

If you want help setting Bugbot up against your own review history, start with a diagnostic, or visit our SpaceXSI implementation page to Request a Quote. We use Cursor in our own engineering, and we calibrate review before we automate around it.

John Kelleher holds the SpaceX Super Intelligence Partner Network Accreditation: Forward Deployed Engineer.