How to Review AI Generated Code

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Re-read what you asked for, then read the diff, then the files it touched, and look at the checks last. Start with intent, because it is the one part of the review that only you can check. A machine reviewer will flag the likely bugs, which covers most of the mechanical work. It cannot tell you whether the diff is the change you wanted or only a change that passes. Spend thirty seconds on your original request before you open the code, so you read the diff against what you meant.

Check scope second. Compare the files the agent touched with the files you named, and treat every extra file as a question.

Running the test suite first is tempting, but a green result makes a reviewer generous. If the agent wrote a test in the same run as the code, green may only mean that the test agrees with what shipped. The old rule applies: never trust a test you have not watched fail. Treat the output as evidence to weigh, not as a verdict.

Mostly in where the machine pass runs. On a small team, run it before the code leaves your machine. /review picks the right review agent, such as BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition., and runs it over your changes. /review-security runs the Security Agent directly.

Both commands run from the agent input in Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..7+, at cursor.com/agents and in the Cursor CLICursor's command line: the full agent, all modes and models, in the terminal and pipeable into scripts and CI. Press Enter for the full definition., before anything reaches a pull request. Check your plan first: Free and Plus don't include BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition., and Security Agents need a Teams or Enterprise plan.

/review-security reviews your branch changes by default, meaning every change relative to the base branch, committed or not. On a long-lived branch, that pulls in code you changed days ago. Ask it to review only your uncommitted changes when you want a narrower read.

On a bigger team, the decision moves from reviewing to routing. PR Routing & Approval, which you configure in Automations, can rate a pull request's risk and assign reviewers based on code ownership and commit history. That puts each change in front of the people who wrote the code it touches, which no single reviewer can do. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition.'s analytics in Automations then show review activity and outcomes, so you can see whether the setup works.

Stacked diffs help in a different way: they cut the cost of each review, but not the number of reviews. Five small pull requests each read faster, and they still land as five reviews on somebody's afternoon.

Agents made writing code fast, and that moves the constraint to review, quality and security. Cursor's write-up of a University of Chicago study reports that organizations merged 39% more pull requests after Cursor's agent became the default, measured against a baseline group that wasn't using Cursor. Each of those pull requests needs a reviewer, and the extra load lands on the people who were already reviewing.

The failure that follows is quiet. A queue of green-checked diffs invites approval without a close read, and the problem stays invisible until something merges that nobody understood.

More reviewers add capacity, but each one still has the same limit: how many diffs one person can hold in mind in an afternoon. So cut what reaches a human at all. Let the machine pass clear the mechanical findings, and spend human review on the changes where intent is in doubt.

Two things make that human review sharper. On Enterprise, once a team admin turns it on, Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. adds line-level human and agent co-authorship to git blame, so which lines an agent wrote becomes a query instead of an argument. Accountability also stays where it was: when agent-written code breaks production, the person who approved and merged it owns the result, whatever a first-pass reviewer said.