Cursor updated BugBot this week with two additions worth flagging: severity scoring on each comment and the ability for teams to configure their own review rules. Both target the noise problem that has been BugBot’s biggest weakness since launch.

What’s new

Severity scoring. Each BugBot comment now ships with a severity label: Critical, Major, Minor, or Style. The labels appear inline with the comment, letting reviewers triage quickly.

Team review rules. Cursor admins can configure which categories of issues BugBot focuses on. Teams that want strict security review can crank that up; teams that want lighter review can dial back the scope.

Comment threading. When BugBot’s comment is responded to (resolved, dismissed, etc.), the next BugBot run remembers. No more “BugBot keeps flagging the same thing we decided was fine.”

Why severity matters

The biggest BugBot complaint has been noise. About 40% of comments were “technically correct but not worth fixing” — minor issues, style preferences, low-impact suggestions. Reviewers had to triage every comment.

Severity scoring lets teams skip the triage. “Show me only Critical and Major BugBot comments” is a real workflow now. The Minor and Style comments are filtered out.

For teams that previously turned BugBot off because of noise, this is the change that lets them turn it back on with a manageable signal.

How severity works

The categorization:

Critical: likely to cause production issues. Memory leaks, race conditions, security holes, data loss bugs.

Major: correctness issues. Missing null checks, off-by-one errors, wrong type assumptions, missed edge cases.

Minor: style and consistency issues. Variable naming, unused imports, inconsistent patterns.

Style: preference. Formatting, comment placement, code organization.

The categorization is approximate. BugBot estimates severity based on the issue’s pattern; misclassifications happen. But it’s accurate enough to be useful as a triage tool.

The team rules

Team admins can configure BugBot’s behavior:

{
  "scope": ["critical", "major"],
  "categories": {
    "security": "always",
    "race_conditions": "always",
    "null_safety": "warn",
    "performance": "off",
    "style": "off"
  },
  "ignored_files": ["**/migrations/**", "**/legacy/**"]
}

Granularity is reasonable. Teams that don’t want style review can disable it. Teams that don’t want BugBot in legacy code can ignore those files.

This is the kind of customization that converts BugBot from “annoying default” to “useful tool.” Configuration takes 30 minutes; the result is a tool aligned with the team’s actual review priorities.

A specific use case

For a team I work with, the previous BugBot configuration produced ~12 comments per PR, of which ~3 were useful. Reviewer fatigue led to BugBot being mostly ignored.

After configuring with the new options:

- Scope: Critical and Major only
- Security: always
- Performance: warn (we care, but lower priority)
- Style: off (we have linters)
- Ignored: migrations, generated files

Comment volume dropped to ~3 per PR, of which ~2.5 are useful. The signal-to-noise improved dramatically. Reviewers now read every BugBot comment because they’re worth reading.

What’s still imperfect

A few rough edges:

Severity classification accuracy. Some “Critical” comments are actually Minor. Some “Minor” comments are actually Critical. The classifier is probabilistic; expect some misclassification.

Team rules don’t sync across organizations. If you have multiple GitHub orgs on Cursor Business, the rules are per-org. No way to share a config.

Threading on long PRs. PRs that have been through many revisions sometimes have stale BugBot comment threads. The dismissal state isn’t always preserved cleanly.

These are reasonable next-cycle items.

Comparison to alternatives

GitHub Copilot’s PR review feature has fewer configuration knobs. It’s broadly functional but produces more noise.

Specialized tools (CodeRabbit, Greptile, etc.) have more sophisticated review logic but cost more and require separate integration.

BugBot’s positioning: integrated into Cursor (free if you’re already on Business+), reasonable quality, manageable noise (after configuration). For teams already on Cursor, the marginal cost is low.

Worth using?

For Cursor Business+ teams already paying for BugBot: definitely use the new configuration. The noise reduction is meaningful.

For teams that turned BugBot off because of noise: try again with the new severity filtering. The experience is meaningfully better.

For teams not on Cursor: this isn’t a reason to switch. BugBot is good but not category-defining. Choose Cursor (or not) based on the broader experience.

The category trajectory

AI-powered PR review is emerging as a real category. The 2024 attempts (Copilot, Cursor BugBot v1) were proof of concept with too much noise. The 2026 versions (BugBot with severity, evolved Copilot review, specialized tools) are reaching the threshold of “useful default for most teams.”

The next year should see further refinement. The features I’d watch for:

• Customization based on per-repo conventions (auto-learning team patterns)
• Integration with existing review tools (don’t re-flag what humans already addressed)
• Severity classification that gets better with feedback

The fundamentals are now in place. The future improvements are about polish.

A meta observation

Tools that ship with too much noise usually get turned off, then get refined, then come back as more focused versions. BugBot followed this trajectory: launched with broad coverage, generated noise complaints, refined to severity-based filtering.

The pattern repeats across software categories. The right initial version of an AI-driven review tool is “useful for catching everything, configurable for what teams care about.” Cursor’s been navigating this iteration well.

For users: keep an eye on tools you’ve turned off. They sometimes come back better. The 6-month-ago version of BugBot might be turn-off-worthy; the current version is worth re-evaluating.