AI-assisted review, testing & anti-patterns

Everything an AI writes is a draft until it lands as a pull request.

The PR is where intent, change, evidence and human accountability fuse into one reviewable, revertable, auditable artifact. Internalize one idea from this module and make it the unit of trust is the PR. Not the diff. Not the chat transcript. Not the agent run.

Why the PR and not the commit or the agent output? A PR is the smallest object that carries all four things an enterprise needs at once:

• A bounded scope (blast radiusHow much breaks if a change goes wrong; the scope of potential damage. you can reason about).
• A description (the intent and the why).
• A set of checks (the evidence).
• An approval (the human who is now accountable).

A raw agent transcript has none of these as durable, queryable records. Picture your ITGCIT General Controls. The baseline IT controls auditors check: who can change what, how changes get approved and how systems are run. auditor six months from now, pulling that PR and asking three things:

• Who approved this?
• What did the checks say?
• Does the description match the diff?

Every author, human or agent-driven, inherits one mandate: the PR must be well-scoped, well-tested and well-described so that nothing downstream changes. Downstream means your reviewers, your CI, your CODEOWNERS routing, your release process, your auditors. Force any of those to behave differently with bigger diffs, weaker checks or skipped approvals and you've leaked the cost of AI velocity onto the parts of the system that exist to contain risk.

Review is defense in depth, not a single gate. Each layer catches a different class of failure and each one stays independent of the others. The moment two layers share a blind spot, you've spent process without buying safety.

The architecture exists so the cheap, fast, deterministic layers catch the boring stuff. That frees scarce human attention for where it's irreplaceable: design fit, intent, risk and the things only a domain expert sees.

1. 1Author self-review. Before requesting review, the author reads their own diff line by line. With AI-authored code this is non-negotiable: you are claiming authorship of what the agent produced. Can't explain a line? It doesn't ship.
2. 2Deterministic checks. Lint, type-check, build, tests, SASTStatic Application Security Testing. Scanning source code for vulnerabilities without running it., secret scanning, license checks. Reproducible and non-negotiable: same input, same verdict. They are the floor, not the ceiling.
3. 3AI review (independent signal). BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. reads the PR fresh and comments inline. It is a second pair of eyes that did not write the code and that independence is the entire point.
4. 4Specialist review. Security, SRESite Reliability Engineering. The team and practice that keeps production reliable: monitoring, on-call and incident response., data or domain experts for changes that touch their risk surface. Routed by CODEOWNERS and risk tier, not by vibes.
5. 5Required human code-owner approval. The accountable signature. This is the separation-of-duties control: the person who merges is not the person or agent who authored. It never collapses into any earlier layer.

Why independence is load-bearingthe core interview point

If the same model that wrote the code also reviews it, the review inherits the author's blind spots and rationalizes the same flawed assumption it baked in. Independence is what makes a second signal worth anything. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. reviewing an agent's PR is valuable because it brings different context and a fresh read of the final diff. A human code-owner reviewing both is still required, because the human carries accountability and judgment no model layer provides.

BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. is Cursor's AI code reviewer. Mechanically it auto-runs when a PR is opened or updated, reads the diff in the context of the repo and leaves inline comments on the specific lines it's worried about. This is not a linter with a fixed ruleset. It reasons about logic, edge cases, error handling and whether the change matches its apparent intent.

As of June 2026, Cursor says BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs.'s average review time is about 90 seconds, down from about five minutes; it costs about 22% less per run and finds about 10% more bugs. That's fast enough to sit in the PR loop without becoming the bottleneck. (Treat the specific percentages as perishable. Verify before quoting in a customer setting.)

The number Cursor's own team quotes most is the issue-resolution rate: across their fleet BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. consistently resolves north of 70-80% of the issues it raises. That's a signal-to-noise statement, not a vanity one. It's the proportion of flagged problems that turned out to be real and got fixed, which is exactly the health metric you want from a reviewer. (Perishable. Verify before you quote it in front of a customer.)

Trust progression: approve-each-fix, then graduate to auto-fixearn autonomy a rung at a time

BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs.'s config lives in an admin dashboard with four knobs worth knowing cold: which repos it operates on, the scrutiny level, whether it runs per-PR automatically or on a manual trigger, and whether it is surface-only or allowed to auto-fix. The recommended rollout is a trust progression: start with auto-fix off so a human approves every proposed fix, watch the resolution rate and false-positive rate, and only graduate a repo to auto-fix once the team trusts the signal. It's the same propose-then-earn-autonomy pattern as the bright line in the next section, applied to a single tool.

The leadership dashboard

BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. also exposes an engineering-leadership view: last-30-days PRs reviewed, issues resolved and automatic fixes merged, drillable down to a specific repo and broken out by severity (high / medium / low). This is the surface that turns AI review from a feature into an ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. story. When a director asks 'is this worth it?', you don't hand-wave. You point at 30 days of resolved high-severity issues per repo. It's also the honest counter to volume metrics: it counts issues resolved, not lines touched.

Custom rules: .cursor/BUGBOT.mdper-area, checked into the repo

Generic review advice is noise. the impact is .cursor/BUGBOT.md, a checked-in file where a team encodes its hard-won rules:

• "Never call the billing API without an idempotency key."
• "All DB migrations must be backward-compatible for one release."
• "PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive. fields must go through the redaction helper."

Because it lives in the repo and can be scoped per area, the same BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. enforces different standards in the payments directory than in the marketing-site directory. That's how an AI reviewer stops being a generic nag and becomes a guardian of your specific risk tiers.

Autofix and isolated VMspropose, don't presume

When BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. can propose a fix, Autofix spins up an isolated cloud-VM agent to generate the change. It's sandboxed, so fix-generation has no ambient access to your laptop or secrets. Read Autofix correctly in an interview: the win is not automatic merge. The win is AI proposes, human disposes, with a review gate that accepts useful fixes and rejects weak ones.

AI is fantastic at generating tests and terrible at knowing what's worth testing. The discipline is the whole game. A generated test that mirrors the implementation is no safety net. It's a tripwire that fires only when you change the code, never when the code is wrong.

Assert intent, not the implementationthe cardinal rule

Here's the classic AI test anti-pattern. The agent writes the function, then writes a test that re-states what the function does line for line. If calculateTax has an off-by-one, the test generated from that buggy function asserts the buggy output and passes forever. A real test encodes the intent: the spec, the business rule, the expected behavior at the boundaries, derived independently of how the code happens to work. A good prompt is "write tests that assert the documented behavior and edge cases of this function." Then you read them and confirm they'd fail against a wrong implementation.

Characterization tests before a refactorpin behavior first

Before you let an agent refactor a gnarly legacy module, write characterization tests first: tests that capture the current observable behavior, warts and all, even behavior you suspect is wrong. This is the one place 'mirror the existing behavior' is correct, because the goal is to pin behavior so the refactor can't silently change it. AI is excellent at this. Point it at the module, have it generate characterization tests across the input space, confirm they pass against the current code, then refactor. A characterization testA test written to pin down current behavior before a refactor, so you notice if the behavior changes. that breaks during the refactor just caught a behavior change you didn't intend, which is the whole point.

Coverage is a gate input, never the goalGoodhart's Law

Coverage is useful as a floor. A PR that drops coverage on a critical module is worth a second look. The moment coverage becomes a target, Goodhart's Law kicks in: "when a measure becomes a target, it ceases to be a good measure." Teams and agents chasing a 90% number generate tests that execute lines without asserting anything meaningful, so coverage climbs while real safety goes flat or down. AI makes this worse: it manufactures coverage-padding tests by the dozen in seconds.

BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. isn't the only reviewer you get. You can codify your review step as a reusable skill and you can strip the most common AI failure patterns out of generated code before it ever reaches a PR. The discipline is to move quality controls earlier, not to lean harder on the last gate.

Why this matters now: agent-driven coding generates code at 10x-100x prior rates, so the bottleneck has shifted from writing code to reviewing it. There are far more PRs than humans can read line by line. The answer isn't to read faster. It's to layer cheap, repeatable quality controls in front of human review so the human reads a tight summary of what actually needs a decision, not three million unfiltered lines.

A mini Bugbot you build yourselfa review step as a skill

.cursor/BUGBOT.md tunes the hosted reviewer. A skill lets you build a reviewer of your own that runs locally, in your editor, on your terms. The pattern is simple: write a skill whose instruction is something like "You are an expert code reviewer. Audit this change for X, Y and Z", where X/Y/Z are your team's real risk areas, then set it to run whenever you commit new feature work.

name: feature-review
description: Expert code review run after feature work. Audit the diff for missing
  error handling, untested edge cases, and any call to the billing API without an
  idempotency key. Report only reproducible findings against the actual diff.
auto-run: after feature work that touches src/ or components/

When you create a skill, Cursor asks the three questions that make it governable: where to store it (project, so it's shared and committed, vs user, so it's personal), how to handle conflicts with other skills, and when it should auto-run (after any feature work touching components, only when you explicitly ask, or whenever tests or adjacent source files change). The auto-run trigger is what turns a one-off prompt into a standing review step.

De-slop at generation timethe layered pre-PR pipeline

Cursor's own engineers run a de-slop skill consistently at generation time, before code reaches a PR. It evaluates model-written code and removes the typical AI slop: generic variable and function names, verbose throwaway comments, overengineering and unnecessary abstraction, bad boilerplate, then standardizes style. It's published on Cursor's public marketplace as a reusable skill, so it's a real, dogfooded example, not a hypothetical.

Stack it and you get a layered pre-PR quality pipeline: de-slop at generation → your review skill / BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. before the PR → human review of a clean diff. Each layer is cheaper than the one after it and each one means the human reviewer spends scarce attention on intent and risk instead of renaming data2 and deleting comments a model left behind.

Cursor's agent surface now reaches into the CI loop. Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. (shipped in 3.5, May 2026) run in isolated cloud VMs with terminal and browser access, work across multiple repos in parallel and report back asynchronously. An agent can be triggered by a failing pipeline, investigate and propose a fix without a human babysitting the terminal. The CLI gained /debug in 3.1.

That's powerful and it's exactly where the governance question gets sharp.

The bright linepropose vs commit

One distinction decides everything about how you deploy agents in CI.

The governance guarantee: automations never mergethe merger is accountable, full stop

Here is how Cursor's own engineering team states the rule, and it's the cleanest version of the bright line you can hand a customer: no automation agent ever merges directly to the repo. It always produces a PR a human reviews and the person who clicks merge is accountable for what lands. You can layer BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. and as many validation automations as you like in front of that PR. The accountability never moves off the human who merges.

Staying on the propose side doesn't mean dumb dispatch. A mature pattern is the risk-rated PR automation: an agent triggers on PR-opened, classifies the change as low / medium / high risk, and routes accordingly. A genuinely low-risk change (say a title or copy tweak) gets auto-approved and merges easily; a high-risk change is held for human review and the automation assigns the right reviewers by running Git blame to find the people who actually own those lines. That's the deterministic dispatch behind the bright line: the agent does the routing, the human still owns the merge on anything that carries risk.

Never fix a pipeline by disabling a checkthe cardinal sin

CI goes red, the pressure is on and the seductive 'fix' presents itself:

• Disable the failing check.
• Mark the test as skipped.
• Merge with admin override.

This is the one move that is always wrong. The check is the evidence. Disabling it doesn't fix the problem. It deletes the proof a problem exists and silently lowers the bar for everyone after you.

An agent told to 'make CI green' will absolutely do this if you let it. That's why agents that touch CI need rules forbidding it and why a human reviews any change to the pipeline config itself.

1. 1Read the failure. Get the actual error and the failing check's logs. Don't guess. (The CLI /debug and Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. are good at exactly this.)
2. 2Reproduce locally or in an isolated agent VM. A failure you can't reproduce is a fix you can't trust.
3. 3Find the root cause. Is the code wrong or the test or check wrong? Both are legitimate, but you must know which. Changing a test to match buggy code is itself the bug.
4. 4Fix the cause, not the symptom. Repair the code or correct the test if it was genuinely wrong, with justification in the PR. Never disable, skip or override to go green.
5. 5Re-run the full suite and confirm green for the right reason. Land it as a normal PR through the normal gates.

Every AI-in-the-SDLC failure mode rhymes. Learn the taxonomy and you can name what's going wrong in a customer's org in one sentence, then point at the guardrail. For each one: the failure, who loses trust and the control that contains it.

How they clusterthree root causes

Notice the through-line. Nearly every guardrail in the right column is something we already covered: the well-formed PR, the layered review with a non-collapsible human gate, intent-asserting tests, least privilege, outcome metrics over volume. The anti-patterns aren't exotic. They're what you get when you skip the disciplines. Your job in the field is to spot which discipline a team dropped, then restore it.

The canonical prompt anti-patternwhere prompt-and-pray actually starts

Most prompt-and-pray messes begin with the same move: a vague prompt on the most expensive model. "Make the app better" on a frontier model, expecting horsepower to substitute for direction. With no concrete target the agent makes blind, scattershot edits, which burns tokens, then burns more tokens reading and fixing the bad code it just wrote: a compounding blind edits → read/fix → more tokens loop that drives cost up and quality down at the same time. Power on a fuzzy task is the worst of both worlds.