How to Review Code When AI Writes Most of It

You cannot read every line anymore. You also cannot ship code nobody has checked. The answer is to decide how much to review, and to agree on that as a team. This post gives a simple way to do that.

1. The Big Idea

Code review is not "read everything" or "read nothing". It is a dial. How far you turn it depends on how much damage a change can do.

2. Start with the Spec, Not the Code

The best moment for a human review is before any code exists.

• Write down what we want to build, why, and how we will know it works.
• Review the spec and the plan together. A wrong plan gives wrong code, and that code can still pass its own tests.
• Once the team agrees on the spec, the code review becomes a simple question: does the code do what the spec says?

This is the core of Spec Driven Development. If you want the full picture, read Part 1: The Three Problems and Part 2: The Framework.

3. Match Review Depth to Risk

Think of your codebase as a tree.

• Trunk code is shared by everything: auth, payments, core data, shared libraries. A bug here hurts the whole app. Read it closely.
• Leaf code stands alone: one screen, one endpoint, one small feature. A bug here stays small. A lighter review is fine.

To decide, ask three questions:

1. What must not change for the user?
2. How bad is it if this goes wrong?
3. Can we undo it quickly?

Changes you can undo easily need less review. Changes you cannot undo, like data migrations, emails, and payments, always need a careful one.

4. Ask for Proof, Not Just Code

A pull request should show that the change works. Ask for:

• Tests that would really fail if the feature broke
• Logs from a real run
• Screenshots or a short video for UI changes
• A short note on how confident the author is, and what is still unsure

When the proof is good, you can read less code and still trust the result. Watch out for tests that only repeat the implementation. They always pass and tell you nothing.

Proof is also part of the bigger system around the model. See Harness Engineering for how constraints and feedback loops make AI output reliable.

5. Keep Changes Small

Small pull requests are easier to judge, faster to review, and simpler to roll back. A huge diff makes every review shallow. If a change is big, split it.

6. Let Tools Handle the Small Stuff

Style, formatting, types, and common bugs should be caught by linters, type checkers, and CI. People should spend their time on design, logic, and risk. Do not argue about nits that a tool can fix.

7. Use AI as a Second Reviewer

• Use a fresh reviewer with no knowledge of how the code was written. An author remembers its own reasoning and tends to defend it. This is the same idea as subagent isolation in Claude Code Best Practices.
• Ask the reviewer to be critical, not polite. Opus 5.5: Why Your Old Prompts Need an Upgrade shows a real challenge-me review workflow.
• Treat it as an extra pair of eyes. It does not replace the human owner.
• Keep the PR description short. A summary longer than the change is a warning sign.

8. Ship Behind a Gate

Put new features behind a flag, even a simple on/off switch.

• You can release to a few users first.
• You can turn it off without a new deploy.
• Remember to remove the flag when the feature is stable. Old flags become hidden debt.

Before the rollout, decide what you will watch (errors, speed, key metrics) and what result means "roll back".

9. Merge-Ready Is Not Launch-Ready

Getting code to work is about 80% of the job. The last 20% takes just as long:

• Check against the spec
• Review security, dependencies, and data safety. For agent skills and tools, SkillSpector can help find risky behavior.
• Check performance and cost
• Clean up and polish the details

This part needs human care and taste.

10. Make It a Team Agreement

None of this works if it lives in one person's head. Write it down:

• Which parts of the codebase are trunk, and who must approve changes there (for example, with CODEOWNERS)
• What every PR must include: spec link, tests, proof, rollback plan
• When a feature flag is required
• Who owns each change after it ships

Whoever opens the PR must be able to explain the change in their own words. If they cannot, it is not ready, no matter who or what wrote it. Keeping these rules in the repo is what Building an Engineering Memory is about.

11. Learn from What Happens

Track bugs and rollbacks, and note where they came from. If AI-written changes in some area stay safe, you can review them more lightly. If they do not, review them more closely. Let evidence set the dial, not gut feeling.

12. Quick Checklist

• Spec reviewed and agreed before coding
• Risk level of the change is clear (trunk or leaf)
• Change is small and focused
• Proof included: tests, logs, screenshots
• Linters and CI pass
• Independent review done (human, AI, or both)
• Behind a flag, with a rollback plan
• Security and data changes checked
• An owner can explain the change

The goal has not changed: ship good software safely. AI makes writing code fast, so the work moves to the human side. Agree on what to build, check the risk, ask for proof, and take ownership of what goes out.

13. Read More

• Why Spec Driven Development, Part 1: The Three Problems
• Why Spec Driven Development, Part 2: Code and PR Review of AI Outputs
• Harness Engineering
• Claude Code Best Practices
• Securing Your AI Agent Workflows with SkillSpector
• Opus 5.5: Why Your Old Prompts Need an Upgrade