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. If you only internalize one idea from this module: 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? Because 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), and an approval (the human who is now accountable). A raw agent transcript has none of these as durable, queryable records. The PR is what your ITGCIT General Controls. The baseline IT controls auditors check: who can change what, how changes get approved, and how systems are run. auditor will pull six months from now and ask: who approved this, what did the checks say, and does the description match the diff?

The practical mandate this puts on every author — human or agent-driven — is that the PR must be well-scoped, well-tested, and well-described so that nothing downstream changes. Downstream here means your reviewers, your CI, your CODEOWNERS routing, your release process, your auditors. If an AI-authored PR forces any of those to behave differently — bigger diffs, weaker checks, skipped approvals — you've leaked the cost of AI velocity onto the parts of the system that exist to contain risk.

Review is not a single gate; it's a defense in depth. Each layer catches a different class of failure, and — critically — each layer is independent of the others. The moment two layers share the same blind spot, you've spent process without buying safety. The whole architecture is built so that the cheap, fast, deterministic layers catch the boring stuff, and scarce human attention is reserved for judgment: design, 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. If you 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. These are 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 — 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 — it will rationalize the same flawed assumption it baked in. Independence is what makes a second signal worth anything. That's why BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. reviewing an agent's PR is valuable (different context, fresh read of the final diff) and why a human code-owner reviewing both is still required: the human carries accountability and judgment that 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. It 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 it's roughly 3x faster and 22% cheaper than the prior generation, finds about 10% more bugs, and 90% of runs finish in under 3 minutes — 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.)

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

Generic review advice is noise. The leverage 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 you turn an AI reviewer from a generic nag into 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 — sandboxed, so the fix-generation has no ambient access to your laptop or secrets. Roughly 35% of autofix-proposed changes end up merged. Read that number correctly in an interview: it is not a failure rate. It means a third of proposals were good enough to accept and the rest were correctly rejected by a human — which is exactly the AI-proposes / human-disposes model working as designed. A 100% merge rate would actually be alarming; it would mean nobody was reviewing.

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 not a 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

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 that was generated from that buggy function will assert the buggy output and pass forever. The test must instead encode 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" — and 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 where '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. If a characterization testA test written to pin down current behavior before a refactor, so you notice if the behavior changes. breaks during the refactor, you've caught a behavior change you didn't intend — exactly what you wanted.

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. But 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 — coverage goes up, real safety goes flat or down. AI makes this worse because it can manufacture coverage-padding tests by the dozen in seconds.

Cursor's agent surface now reaches into the CI loop. Cloud Agents (shipped in 3.5, May 2026) run in isolated cloud VMs with terminal and browser access, can work across multiple repos in parallel, and report back asynchronously — which means 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. This is powerful, and it's exactly where the governance question gets sharp.

The bright linepropose vs commit

There is one distinction that decides everything about how you deploy agents in CI:

Never fix a pipeline by disabling a checkthe cardinal sin

When CI goes red and the pressure is on, the seductive 'fix' is to disable the failing check, mark the test as skipped, or 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 that a problem exists and silently lowers the bar for everyone after you. An agent under instruction to 'make CI green' will absolutely do this if you let it — which is why agents that touch CI need rules that forbid 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 Agents are good at exactly this.)
2. 2Reproduce locally (or in an isolated agent VM). A failure you can't reproduce, you can't trust you've fixed.
3. 3Find the root cause. Is the code wrong, or is the test/check wrong? Both are legitimate, but you must know which — and 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 the test 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: 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, and 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 and restore it.