The review process did everything right.
Someone opened the pull request. Someone else read through it carefully. The logic was sound. The tests passed. The naming was reasonable. Nothing obviously wrong. Approved.
Three months later that feature is the one nobody wants to touch. The patterns it introduced do not match anything around it. The state management approach it used became a local convention that contradicts the one two features over. The component boundaries made sense in isolation and make no sense in context.
The review did not fail. It caught what it was designed to catch. The problem is that what it was designed to catch does not include missing AI standards.
What code review is actually for
Code review is a human process designed to catch human mistakes.
Logic errors. Security vulnerabilities. Missing edge cases. Unclear naming that a second pair of eyes catches. Architecture decisions that need discussion. These are the things code review is built to find.
What it is not built to find is the absence of a standard that should have existed before the AI generated anything. A reviewer can see that a component is structured a certain way. They cannot see that the AI made that structural decision because no rule existed to make it differently.
The missing standard is invisible in the code. It only becomes visible over time, when enough sessions have made enough slightly different decisions that the inconsistency becomes impossible to ignore.
By then the review that approved all of it is long forgotten.
The confidence that code review creates
This is the part that makes missing AI standards expensive in a specific way.
When a pull request gets approved, it signals that the code meets the standard. The team has looked at it. The team is satisfied. Everyone moves on with confidence that what was built is correct.
That confidence is not wrong about what was reviewed. It is wrong about what was not reviewed. The review confirmed the logic. It did not confirm that the AI had rules to follow. It did not confirm that the structural decisions the AI made match the ones three features over. It could not confirm those things because they were never defined.
The approval creates confidence in code that has a silent gap underneath it. And silent gaps do not stay silent forever.
A code review tells you the code is correct. It cannot tell you that the standard behind the code exists. Those are two different questions and only one of them gets asked in most review processes.
What happens when the gap surfaces
It usually surfaces during a refactor or a handover.
Someone opens the codebase to extend a feature and realizes the pattern used in that approved pull request from three months ago does not match anything else. They have to decide whether to follow the local pattern or the global one. Either way something is now inconsistent.
Or a new developer joins and tries to understand the codebase by reading through it. They find three different ways of doing the same thing and no indication of which one is correct. All three were approved. None of them was wrong. None of them was the result of a defined standard.
The review worked. The standard was missing before the review ever happened.
Where the gap actually gets closed
Not in the review. Before the session.
The review cannot close a gap that existed before the AI generated anything. It can only catch the symptoms of that gap, and only if the reviewer knows to look for them, which they usually do not because the symptoms look like reasonable code.
The gap closes when the AI has rules that define what the output must look like before any generation happens. When those rules exist the review confirms something different. Not just that the code is correct but that the code follows a standard that was defined before the first line was written.
Here is what that looks like in practice:
Rules that exist before the review:
- Component structure follows the presentational or container pattern. Reviewers can verify this against a defined standard.
- State placement follows a defined rule. The review confirms compliance, not just correctness.
- Naming follows documented conventions. The review catches deviations from something explicit.
The review becomes a compliance check against a known standard instead of a judgment call about whether something reasonable was done.
The prompt does not matter. The rules do.
Your code review process is not the problem. It is doing exactly what it was designed to do.
The problem is that what it was designed to do does not include catching the absence of AI standards. That is not the review's job. That is the rules' job.
Define the standard before the AI generates anything. Let the review confirm what was already defined. And stop expecting the review to catch something that was never defined to begin with.
Want to find where your React project is missing the standards your reviews cannot catch?
I built a free 24 point checklist that helps you find exactly that. The structural gaps that pass every review because they were never defined in the first place.