Reviewing Code with Cursor

Codebase search lets Cursor see how changed code connects to the rest of your project. It can check whether a change duplicates existing logic, violates patterns your team uses elsewhere, or misses edge cases that similar code handles.

Self-review before submitting PRs

The most effective reviews happen before you push. When you review your own changes with Cursor, you catch issues while the context is fresh and before you've context-switched to something else.

Cursor can compare your changes against patterns elsewhere in the codebase. If you're adding error handling to one endpoint, it can check whether similar endpoints handle errors the same way. This consistency check is tedious to do manually but natural for Cursor.

If you develop prompts that work well for your codebase, turn them into custom commands. A /review command that runs your standard checks before every PR saves time and ensures consistency.

Automated review with Bugbot

Bugbot reviews PRs automatically when you push. It reads the full context of your change, including how the changed code interacts with the rest of your codebase, and looks for bugs that would reach production.

This is different from linters. Linters catch formatting issues and simple patterns. Bugbot looks for logic errors: null pointer exceptions waiting to happen, race conditions, missing error handling, security issues. It understands code semantically, not just syntactically.

What Bugbot catches

The specific issues Bugbot surfaces depend on your codebase. It tends to find null reference errors, missing error handling, race conditions, and security issues. Teams with strong typing see fewer null errors flagged; teams with async code see more race condition warnings.

See the Bugbot documentation for setup and configuration.

Reviewing others' PRs

When you're the reviewer, Cursor helps you understand unfamiliar code quickly and check things you might miss.

Understanding what changed

Start by getting oriented. Use Ask mode (Shift+Tab, then select Ask) to explore without making changes:

Cursor traces through callers and callees to show you the impact of changes. A two-line change might have implications across multiple files, and Cursor can surface those connections.

Checking edge cases

Domain-specific edge cases are easy to miss in review. If you know the area is tricky, ask Cursor to enumerate what could go wrong:

This works because Cursor can see similar code elsewhere in your codebase. If other endpoints handle certain errors, it notices when this one doesn't.

Checking against team standards

If your team has documented standards in rules files, Cursor can check compliance:

The more specific your rules files, the more useful this check becomes. "Follow best practices" produces vague feedback. "Use the Result pattern for operations that can fail" produces specific feedback.

Encoding review standards

The knowledge that makes senior engineers good reviewers can be captured in rules files. When you encode this knowledge, Cursor (and Bugbot) apply it consistently across every review.

Bugbot rules (BUGBOT.md)

Create a BUGBOT.md file in your repository root:

# Review Standards## Test coverageIf the PR modifies files in {server/**, api/**} and there are no changesin {**/*.test.*, tests/**}, flag as needing tests.## Security-sensitive areasIf the PR modifies files in {auth/**, payments/**, security/**},add a comment requesting security review.## Common patterns to enforce- Flag .Result or .Wait() in async code (use await instead)- Flag TODO comments without linked issues- Flag new dependencies without justification in PR description

Cursor rules (.cursor/rules/)

Create a .cursor/rules/review.mdc file for Cursor-assisted review:

# Review Context## Patterns to check- Error handling: All async operations should use try/catch or the Result pattern- Validation: Public API endpoints must validate input before processing- Logging: Operations that can fail should log before and after with correlation IDs## Files to reference- src/utils/errors.ts shows our error handling pattern- src/middleware/validation.ts shows our validation approach## Known areas of risk- The legacy UserService has implicit null returns; always check for null- Payment operations must be idempotent; check for duplicate handling

Start with the issues that come up repeatedly in your reviews. Each rule you add is a review that future PRs get automatically.

Connecting external context

MCP integrations can pull context from GitHub, GitLab, Linear, and other tools directly into your review workflow. If you need to understand why a change was made, you can reference the linked issue. If you need to check related PRs, you can query your repository.

Browse the Marketplace for available integrations with your tools.

Getting started

1. Try self-review first. Before your next PR, ask Cursor to review your changes. Notice what it catches that you missed, and what feedback is useful versus noise.

2. Enable Bugbot on a repository. After a week of running, you'll have a sense of which comments are valuable and which to dismiss, and you can tune the rules accordingly.

3. Start a rules file. Pick one or two issues that come up repeatedly in your reviews and encode them. Add more as patterns emerge.

4. Use Ask mode for understanding. When reviewing unfamiliar code, explore with Ask mode before forming opinions.

For related workflows, see Understanding Unfamiliar Code for exploring codebases and Debugging for investigating issues discovered in review.