AI code review habits

Good code review for AI-generated code starts with one checklist, one owner, and one rule every agent-authored change must pass before a human reads it. A code review habit is a fixed routine the whole team runs on every change, instead of a judgment call that depends on who is looking. Get that routine in place and the rest of your guardrails have something to hang on.

The thing that breaks first is not speed. It is that review stays vague while the agent gets faster. AI-written code looks finished, so reviewers skim it, and brittle logic, missing tests, and connector sprawl slip through because nobody agreed on a gate. The fix is to make review repeatable.

Read the change, not the confidence of the author

AI-written code reads clean even when it is wrong. That polish is the trap, so review behavior instead of style.

A simple way to hold yourself to that is two passes on every diff. The first pass checks behavior, tests, and rollback: does it do the right thing, and can you undo it. The second pass checks scope, permissions, and any tool use you cannot see in the code: what could this change reach. The second question is the one polished code makes you forget.

That shift moves you from "does it look right?" to "what can it touch?" Same diff, very different review.

Check the boundary files before you read the diff

Most teams trust the agent more than the files that are supposed to constrain it. Those files drift, and nobody notices until something escapes.

Each tool keeps its rules in a known place. In Cursor, Anysphere's AI code editor, that is .cursor/rules/*.mdc. In Claude Code, Anthropic's coding agent, it is CLAUDE.md. In Codex, OpenAI's coding agent, it is AGENTS.md. The failure is the same everywhere: the file exists, but nobody confirms it still matches the repo.

So confirm it first. Before you read the diff, open the rules file for whichever tool wrote the change and check that the contract is current. A diff means more once you know the lane it was written in.

Treat every new connector as a boundary, not a detail

A connector can look harmless in a diff while reaching GitHub, Slack, your docs, or a database. The Model Context Protocol specification is explicit that tools are arbitrary code execution paths and need user consent, control, and safety review. So MCP is a boundary problem, not a size problem: a tiny tool can still reach a sensitive system.

Make every new connector announce itself. When a change adds or alters one, attach a one-line note naming the server, the data it can read, and the action it can take. The reviewer then reads that note instead of reverse-engineering the integration from the diff, which makes review faster, not slower.

The same note tells you when to pull in a second person. If a change touches auth, data movement, permissions, or generated tests, it gets a second human reviewer. That turns a vague worry into a rule anyone can apply.

Paste this checklist into your review template

This is the routine itself. It is boring on purpose, because boring is what makes a habit stick.

# AI-generated code review checklist

- [ ] The author marked the change as AI-assisted or agent-authored.
- [ ] The diff has one clear purpose and no unrelated refactors.
- [ ] Tests were added or updated for the changed behavior.
- [ ] Boundary files were checked: .cursor/rules, CLAUDE.md, AGENTS.md, or overrides.
- [ ] Any MCP server or external connector is named and reviewed.
- [ ] Permissions, secrets, and data access were not widened without approval.
- [ ] A human reviewer checked behavior, rollback, and failure mode.
- [ ] The change is safe to revert.

One good test of whether it is working: can a reviewer tell, in under two minutes, what the agent could touch and what a human already verified. If yes, the gate is doing its job.

Common questions

• What is the best way to start a code review habit for AI-generated code?

  Start with one checklist, one boundary-file check, and one escalation rule. Run all three on every agent-authored change so review becomes a routine instead of a case-by-case debate. When a change touches permissions, data movement, or MCP connectors, require a second human reviewer before merge.

• How do we keep Cursor, Claude Code, and Codex aligned on review?

  Write one review policy, then map it onto each tool's native files. That means .cursor/rules/*.mdc for Cursor, CLAUDE.md for Claude Code, and AGENTS.md for Codex. The shared policy matters more than the surface, so any engineer reviewing in any tool runs the same gate.

• Do we need MCP review even for small changes?

  Yes, whenever the change adds or alters a connector. A small tool can still reach sensitive systems, so review the server, the permissions, and the data path before you review the prompt. Size tells you nothing about blast radius, and a one-line diff can open a wide door.

• What should reviewers look for first?

  Start with behavior, scope, and blast radius. Then check tests, rollback, and whether the agent used any connector or override file that changes the repo contract. That order keeps a reviewer from being charmed by clean code that still does the wrong thing, and it surfaces hidden reach early.

• Does this slow the team down?

  A little, at first, and that is the trade you want. The gate adds friction to merges but cuts the cost of hidden scope and unreviewed connector access. It does not replace senior judgment, it makes that judgment easier to apply the same way on a Monday and a Friday.

Put the gate in your next pull request

Pick the checklist above and one repo boundary file, and make both visible in your next review. For the wider policy your team can grow into, send people to agentic coding governance.