Four PR rules I set for my team last month are now in place:
Whoever opens the PR owns it. “AI wrote it, so I didn’t look closely” is not an acceptable excuse.
The PR template gets a “How was this verified?” field. Writing only “self-tested” doesn’t count. The most important thing is to state what was not tested.
Reviewing AI-written code uses a different set of questions: Does this logic already exist in the repo? Is the error handling real, or invented? Have the preconditions it relies on been validated? Do the tests check behavior, or implementation details?
AI has no approval channel. It can change code and open PRs, but only the code owner can click merge. Automated review will only comment, not block, at first; once it has proven reliable for a while, I’ll give it more authority.
On October 15, the Claude Code team published a long post on their official blog, “How the Claude Code team does code review,” describing how they review code today. The background: roughly 90% of Claude Code’s code is written by Claude. From June to September, merged PRs more than doubled, while the share needing rollback actually fell by more than 40%.
They did not abolish review. What changed is the question being asked. It used to be “has anyone read this code?” Now it is “what could go wrong with this change, and which check is best placed to catch it?” The goal is to spend less human time without increasing rollbacks or incidents.
I compared my own rules against theirs. The conclusion first:
Verification up front and machine review first: both sides point the same way.
Who approves the merge: the biggest disagreement.
On keeping review rounds under control, they have gone a few steps further than I have, and I plan to copy three of their practices.
