AI-Enhanced Code Reviews in Cursor
Cursor reviews code in three places: Agent Review analyzes a local diff before a commit is pushed, BugBot reviews every pull request against rules tuned to a team’s standards, and the Cursor CLI runs custom review workflows inside GitHub Actions. The AI pass handles mechanical defects so human reviewers spend their attention on architecture and business logic.
It is Friday afternoon and six pull requests are waiting. Two are from a junior developer who tends to miss error handling. One is a 47-file refactor that will take an hour just to understand. Another touches the payment flow. The senior engineer who reviews most PRs has been in meetings until three, so everything has been sitting for hours — and when the backlog finally gets cleared, it gets cleared fast enough to miss the null check that is in the wrong order.
The bottleneck is not the review rule, it is the workflow. AI-assisted review does not replace human reviewers; it amplifies them. The AI catches the mechanical issues — missing error handling, inconsistent patterns, potential null references — so the human reviewer can judge the things AI cannot: whether the architecture makes sense, whether the business logic is right, and whether this was the right approach at all.
What AI-enhanced review gives you
Section titled “What AI-enhanced review gives you”- A self-review workflow that catches most review comments before you submit the PR
- BugBot configuration that catches real issues without generating noise
- A CLI-based custom review workflow for team-specific standards
- Copy-paste prompts for complex PRs, security-sensitive code, large refactors, and AI-generated code
- Project rules that encode your team’s review checklist so every surface enforces the same one
- A pipeline that keeps humans reviewing judgment calls instead of checklists
The three places Cursor reviews code
Section titled “The three places Cursor reviews code”Each mechanism covers a different stage of the pipeline, and combining them gives coverage no single approach matches.
Agent Review: pre-flight on your own diff
Section titled “Agent Review: pre-flight on your own diff”Before you push a commit, Agent Review runs Cursor’s analysis against your local diff. After Agent generates changes — or any time you have uncommitted changes — click Review in the diff view, then Find Issues. The agent analyzes your changes line by line and flags potential bugs, logic errors, and missing edge cases.
You can also review all changes against your main branch from the Source Control tab, which is the version worth running right before opening a PR. In the chat input, /review and /review-bugbot do the same from the keyboard.
In Cursor settings you can enable:
- Auto-run on commit: automatically scans for bugs after each commit
- Include submodules: reviews changes in Git submodules
- Include untracked files: catches issues in files not yet staged
Turn on auto-run if you want continuous feedback; leave it off and trigger reviews manually if you would rather control usage.
BugBot: every pull request, automatically
Section titled “BugBot: every pull request, automatically”BugBot is Cursor’s managed service for automated pull request reviews. Enable it in your Cursor dashboard (Settings > BugBot) or through the GitHub App, connect your repository, and it reviews every PR, posting findings categorized by severity (Bugs, Security, Compliance). A manual run is a bugbot run or cursor review comment on the pull request.
BugBot works differently from a manual review prompt. It uses specialized analysis tuned for catching bugs in diffs — not just style issues, but actual logic errors, missing edge cases, and potential regressions. When it flags something on a PR, Autofix with Cloud Agent spawns an isolated VM that applies the fix, verifies the test suite, and pushes a follow-up commit to the branch.
Cursor CLI: review logic you write yourself
Section titled “Cursor CLI: review logic you write yourself”For review logic beyond what BugBot provides — compliance checks, architectural pattern enforcement, integration with external tools — the Cursor CLI runs fully custom review workflows in GitHub Actions.
The permissions configuration is what keeps the review agent able to read code and post comments but unable to modify the repository:
{ "permissions": { "deny": [ "Shell(git push)", "Shell(gh pr create)", "Shell(gh pr merge)", "Write(**)" ] }}Self-review before you open the PR
Section titled “Self-review before you open the PR”The highest-leverage review workflow is reviewing your own code before anyone else sees it. It catches most of the comments you would otherwise receive, which means your reviewers spend their time on architecture instead of pointing out the empty-array case.
Run that in Ask mode, fix what it finds, then submit. When the change touches something security-sensitive, run a second, narrower pass instead of widening the first one — the prompt below goes deeper on one axis and deliberately ignores code you did not touch:
Encoding your team’s standards as a rule
Section titled “Encoding your team’s standards as a rule”Cursor’s project rules are the one place to write your review checklist down, and every surface reads them: Agent Review, /review, and BugBot. Rules scoped to “Always Apply” are included in every BugBot review; glob patterns scope the stricter ones to where they belong, such as src/api/**/*.ts.
---description: Standards for AI-assisted code reviewalwaysApply: false---
## Always check- Every new API endpoint must have input validation using Zod- Database queries must use parameterized inputs, never string concatenation- Error handling must not swallow errors silently (no empty catch blocks)- New React components must have TypeScript prop interfaces, not inline types- Async functions must have try/catch or .catch() error handling- Error responses must follow the format in @src/lib/errors.ts
## Performance- No N+1 queries: if a loop contains a database call, flag it- No synchronous file system operations in request handlers- Images must use lazy loading in frontend code
## Testing- New utility functions must have corresponding test files- Test files must include at least one edge case test- Mock external services, never hit real APIs in tests
## Do not flag- Style preferences (formatting is handled by Prettier)- Import ordering (handled by ESLint)- Variable naming unless it is genuinely confusingStore it as .cursor/rules/review-standards.mdc. The “Do not flag” section is the half most teams leave out, and it is the half that fixes the false-positive problem: without it, every review argues with Prettier.
Saving a review you run every time as a command
Section titled “Saving a review you run every time as a command”For reviews you repeat, a saved command beats re-pasting a prompt:
---description: Run a security-focused review on the current changes---
Review all changes on the current branch compared to main for security issues.
Check for:- User input that reaches database queries without parameterization- Missing authentication or authorization checks- Secrets or credentials in code or configuration- User input rendered in HTML without sanitization- File paths constructed from user input- Deserialization of untrusted data
For each finding, rate it as Critical, High, Medium, or Low severity.Provide the file, line, the vulnerability, and a specific fix.Save as .cursor/commands/security-review.md and invoke with /security-review before opening a pull request.
Reviewing someone else’s pull request
Section titled “Reviewing someone else’s pull request”Building a mental model first
Section titled “Building a mental model first”Fifteen changed files and 400 lines of diff is not a review problem yet, it is a comprehension problem:
That saves ten minutes of scrolling through a diff trying to work out what the PR is actually for.
One focused pass per concern
Section titled “One focused pass per concern”Three focused passes catch more than one unfocused “review this code”:
Large refactors, three passes
Section titled “Large refactors, three passes”Large PRs are where AI review delivers the most value. A human reviewer’s attention degrades after the first 200 lines of diff; the AI holds the same level of scrutiny across 2,000. Structure the passes explicitly so it does not mix concerns:
@src/services
This PR refactors the service layer from class-based services to functional modules.Review the changes in three passes:
Pass 1 - Correctness: Do the new functional implementations preserve the samebehavior as the class-based versions? Check return types, error handling, andedge cases.
Pass 2 - API Surface: Are the exported function signatures backward-compatible?Will consumers of these services need to update their imports or call patterns?
Pass 3 - Testing: Do the existing tests still make sense with the newimplementation? Are there new code paths that lack test coverage?
Summarize findings for each pass separately.Architecture rules rather than best practices
Section titled “Architecture rules rather than best practices”Sometimes the review needs to enforce your specific architecture, not generic quality:
Writing a PR description reviewers can act on
Section titled “Writing a PR description reviewers can act on”A good description answers the reviewer’s first three questions before they open the diff: what changed, why, and where to look.
Reviewing AI-generated code with extra scrutiny
Section titled “Reviewing AI-generated code with extra scrutiny”AI-generated code has a specific failure pattern: it looks more correct than it is. A function may have a try/catch that catches errors and does nothing with them. A validation function may check three of four required fields. The structure looks right even though the behavior is wrong, which is exactly what makes it easy to wave through.
Responding to review comments
Section titled “Responding to review comments”Feedback you do not understand is the slowest kind. Cursor can explain the reviewer’s reasoning before you decide whether to accept it:
The pipeline that turns this into a culture
Section titled “The pipeline that turns this into a culture”The most effective teams use AI review as a first pass, never as a replacement:
- The author runs Agent Review locally before pushing, and fixes the obvious issues before the PR exists.
- BugBot reviews the PR automatically when it opens, catching bugs, missing tests, and security issues against the project rules.
- The human reviewer focuses on architecture, design decisions, and business logic — the judgment the AI is least equipped to supply.
- The author addresses feedback from both, asking Agent mode to implement the mechanical fixes directly.
The AI handles the checklist. You handle the judgment.
Where AI code review goes wrong
Section titled “Where AI code review goes wrong”BugBot generates too many false positives. Usually the project rules are too broad or contradictory. Narrow them: instead of “all functions must have error handling,” say “async functions in src/api/ must wrap their body in try/catch.” And write the “Do not flag” list — the AI cannot guess that Prettier already owns formatting.
Agent Review misses obvious bugs. The review is only as good as the model and the context it has. For complex logic, ask directly: “Is there a case where this function returns undefined instead of throwing?” Targeted questions beat open-ended “review this code.”
AI review misses business logic errors. Structural issues are what it catches. A function that calculates tax incorrectly will pass every AI review if the code is clean. Business logic correctness stays a human responsibility, permanently.
Reviews become a rubber stamp. If you accept AI output without reading it, you lose the context-specific issues that were the point. Treat the findings as the starting point of your review, not the end of it.
The CLI review workflow posts duplicate comments. A workflow that triggers on synchronize re-reviews the whole diff on every push. Tell the agent to check first: “Before posting a comment, check if similar feedback already exists on nearby lines using gh pr view —json comments.”
The review takes too long and blocks the PR. Set a job timeout in GitHub Actions — ten minutes is usually enough. If it still times out, reduce scope to changed files rather than the whole codebase.
PR descriptions come out generic. “Updated the service” means the AI had no access to why. Fill in the business context in the prompt; it is the one section that cannot be inferred from a diff.