How I review AI-generated systems without slowing delivery

AI can produce a large amount of plausible code very quickly. That makes review discipline more important, but it does not make one undifferentiated line-by-line pass the right control for every change.

I review in proportion to consequence. A copy change, an isolated UI component, an authentication boundary, and a payment workflow should not receive the same verification plan.

Start with the system boundary

Before implementation, I want the architecture, data ownership, trust boundaries, failure modes, and acceptance criteria to be explicit. Most expensive defects begin with a wrong assumption at that level, not with unusual syntax inside one helper.

• High-risk code gets direct scrutiny. Money, identity, permissions, personal data, destructive operations, migrations, and external side effects receive the closest review.
• Tests prove only what they cover. I use unit, integration, contract, and end-to-end checks where they reduce meaningful uncertainty, and I inspect whether the test actually exercises the risk.
• The deployed path matters. Build success is not production evidence. I verify the real environment, observe logs and health signals, and keep a recovery path available.

Review is a system, not a gesture

My review loop combines scoped implementation, targeted code inspection, automated checks, diff review, staging, runtime verification, observability, and rollback readiness. The mix changes with the risk; the ownership does not.

What to ask an AI-assisted team

Ask how they decide what is high risk, which behaviours are proven, what remains uncertain, how staging differs from production, what they monitor after release, and how they recover. Those answers tell you much more than a blanket claim about reading every generated line.