How to Review AI Generated Code

The working pattern for AI generated code review is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running AI generated code review as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

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.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains 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.

Re-read what you asked for, then read the diff, then the files it touched, and take the checks last. Intent before mechanics, because intent is the only part of this pass nothing else can do for you.

A machine reviewer will flag the likely bugs, and that is most of the mechanical work. What it cannot tell you is that the diff is the change you wanted rather than a change that passes, and that gap does not close further down the pipeline. Thirty seconds spent on the request before you open the code is what makes the rest of the pass mean anything.

Scope is the second read. Compare the files it touched against the files you named, and treat every extra one as a question rather than a bonus.

Then the checks, and here I would push back on the common habit of running the suite first. Green makes you generous. Worse, if the agent wrote the test in the same run as the code, green may only mean the test agrees with what shipped, which is why the rule is never to trust a test you have not watched fail. Read the output as evidence you are weighing, not as a verdict already in.

Mostly in where the machine pass runs. On a small team you can do it before the code leaves your machine: /review runs BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. over your changes and /review-security runs the Security Agent, both available in Cursor 3Cursor's agent-forward interface (also called the agent window or Glass), built to run and supervise many agents at once rather than edit one file. Press Enter for the full definition..7+ and in the signed-in web app at cursor.com/agents. No dashboard, no configuration, nobody's PR queue involved.

/review-security defaults to your branch changes, meaning everything relative to the base branch including uncommitted work, so on a long-lived branch you will get findings for things you fixed on Tuesday. Ask it for just the uncommitted changes when you want the narrow read.

The bigger the team, the more the interesting decision moves from reviewing to routing. A PR-opened automation that rates risk and assigns reviewers from git blame does something no individual reviewer can, which is putting the change in front of the people who wrote the code being changed. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition.'s 30-day dashboard then tells you whether any of it is working, drillable by repo and split by severity.

Stacked diffs are the other half of the answer. They cut the cost of each review rather than the number of reviews, a distinction teams collapse constantly. Five small PRs read faster one at a time and still land as five reviews on somebody's afternoon.

Because the queue grows and the reviewing capacity does not. A University of Chicago study of 1,000 organisations adopting Cursor found a 39% increase in org-level output, with teams merging 39% more pull requests after Agent became the default mode. Which is also a 39% bigger review load, landing on whoever was already doing the reviewing.

What follows is quiet. A queue of green-checked diffs invites approving on vibes, and that failure stays invisible until something merges that nobody understood.

The instinct is to add reviewers. My read is that this buys less than it looks like, because the constraint was never how many people can read a diff, it is how many diffs any one of them can hold in their head in an afternoon. So the move is to cut what reaches a human at all. Let the machine pass clear the mechanical findings and spend the human budget on the changes where intent is genuinely in doubt.

And two things make that spending sharper. 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 on top of git blame, so which lines an agent wrote becomes a query rather than an argument. The accountability also stays exactly where it was. When agent-written code breaks production, the person who approved and merged it owns that, and no first-pass reviewer moves it.

Generation stopped being the constraint. Review, quality and security are the constraints now, and most review budgets have not caught up with that.