Your Code Review Happens After Generation. Your Standard Needs to Happen Before It.
There is an assumption buried in how most teams think about AI generated code. The assumption is that the review process will catch what needs catching. The AI generates, a human reviews, problems get flagged, corrections happen. The system works the way code review has always worked, just with an AI in the author role instead of a person. This assumption misses something fundamental about how the AI actually operates. It does not review its own output. It does not second guess its architectural
There is an assumption buried in how most teams think about AI generated code. The assumption is that the review process will catch what needs catching. The AI generates, a human reviews, problems get flagged, corrections happen. The system works the way code review has always worked, just with an AI in the author role instead of a person.
This assumption misses something fundamental about how the AI actually operates. It does not review its own output. It does not second guess its architectural decisions. It does not pause halfway through generating a component and ask whether this is the right approach for this specific project. It generates, based on whatever it can infer from context and whatever instructions it received, and then it stops.
There is no internal reviewer inside the generation process. The only reviewer is the human who looks at the output afterward. And by the time that review happens, every decision has already been made.
What generation actually looks like from the inside
When the AI generates a component, it makes a sequence of decisions very quickly. Where should this state live. What should this be called. How should this be structured. What pattern applies here. Each decision happens based on the immediate context and whatever general knowledge the model has, and then the next decision happens on top of it.
There is no step in this process where the AI stops and evaluates whether the decision it just made matches your project's standard. It does not have access to your standard unless you gave it explicit rules to follow. It has its training, the immediate context, and the prompt. That is what informs every decision it makes during generation.
This is different from how a human developer works, even one who is moving quickly. A human developer carries an internalized standard that operates continuously during the work. They do not consciously think about it most of the time, but it is there, shaping decisions as they are made. A senior developer writing a component is applying years of accumulated judgment about what this specific codebase should look like, even without articulating any of it.
The AI has no equivalent internal process. It has no accumulated judgment about your specific project. It has patterns from its training and whatever is visible in the current context. Without explicit rules, every decision during generation is made in the absence of the standard that a human would have been applying automatically.
Why review after generation is the wrong place to catch this
Code review exists to catch what generation itself does not catch. This has always been true, going back before AI was part of the workflow. A human developer writes code, another human reviews it, and the review catches logic errors, missed edge cases, security issues, things the original developer did not think of or got wrong.
This works because human authorship already has a standard embedded in the generation process. The review is catching mistakes on top of a foundation that mostly reflects the project's conventions. The reviewer is looking for what went wrong, not establishing what the baseline should have been.
With AI generated code the review is doing something different, whether anyone intends it to or not. Because there is no standard embedded in the generation process unless rules were provided beforehand, the review becomes the place where the standard gets established after the fact. The reviewer is not just catching mistakes. They are retroactively defining what should have happened, one comment at a time, on code that has already been written based on the AI's best guess without that definition.
This is expensive in a way that traditional code review is not. The code already exists. The developer already spent time on it. Correcting it after the fact costs more than it would have cost to define the standard before generation began. And because the standard was never written down, the same retroactive correction happens again in the next pull request, and the one after that.
The reviewer that does not exist
If you think about what would actually solve this problem, the answer is obvious once you say it out loud. You need something reviewing the decisions as they get made, before the output reaches a human reviewer. You need a standard that operates during generation, the way a senior developer's internalized judgment operates during their own writing process.
The AI cannot provide this on its own. It does not have accumulated judgment about your project. It has no internal reviewer checking its work against your conventions because it has no access to your conventions unless you give them to it explicitly.
This is what rules actually do. They are not documentation for humans to reference later. They are the internal reviewer the AI does not otherwise have. When a rule says state belongs in a dedicated hook, that rule is operating during generation, before the component exists, shaping the decision the same way a human developer's internalized standard would shape their own writing.
The difference between a rule and a code review comment is the difference between prevention and correction. A code review comment happens after the mistake is already in the codebase, in a pull request, taking up review time. A rule happens before the mistake has a chance to exist. The generation itself follows the standard because the standard was present during generation, not absent from it and discovered afterward.
What it looks like when the standard operates during generation
Consider a specific decision that happens constantly during React development. Should this piece of logic live in the component or in a hook.
Without a rule, the AI decides this based on whatever it infers from context. Sometimes it puts logic in the component because that is simpler for the specific case. Sometimes it extracts a hook because the context suggests that pattern. The decision is made fresh every time, based on immediate signals rather than a consistent standard.
With a rule specifying exactly when logic must be extracted into a hook, the decision is no longer being made fresh. It is being checked against a standard that exists before the component is written. The AI does not have to infer what your project prefers because your project's preference has been stated explicitly and it is present during the generation process itself.
Here is what a set of rules that operate during generation actually looks like, as opposed to comments that would otherwise appear during review:
Rules that replace after-the-fact review comments:
1. Any state that affects more than one render decision moves into a dedicated hook, not inline useState calls scattered through the component. This is checked during generation, not flagged during review.
2. Components receiving more than four props get evaluated for whether they are doing too much before the component is written, not after a reviewer counts the props and asks why.
3. Any function passed as a prop follows the handleX naming convention consistently, checked as the function is named, not corrected in a review comment asking for a rename.
4. Data fetching never happens directly inside a component body. This is enforced as the component is structured, not caught when a reviewer notices a useEffect doing something it should not be doing.
Enter fullscreen mode Exit fullscreen mode
Each of these represents a decision point during generation where a rule can operate instead of a human catching the absence of that rule after the fact. The review still happens. It just has less retroactive standard-setting to do because the standard was already present when the code was written.
What changes for the humans doing review
This does not eliminate code review. It changes what code review is for.
When rules operate during generation, the review process gets to focus on what it was originally designed for. Logic correctness. Edge cases. Whether the feature actually does what the product requires. The kinds of judgment calls that genuinely benefit from a second set of eyes, as opposed to structural and conventional decisions that should have been consistent from the start.
Reviewers stop writing the same comments about component structure and state placement and naming conventions, not because they got more lenient, but because those categories of feedback are no longer necessary. The AI was not left to guess at those decisions during generation. The rules already determined them.
The time this saves compounds. Every pull request that does not need retroactive standard correction is a pull request where the reviewer's attention goes to something that actually requires their judgment. Over enough pull requests this is a substantial shift in how review time gets spent.
The prompt does not matter. The rules do.
Your AI does not review its own output. It generates and stops. There is no internal process checking whether the decisions it just made match your project's standard, unless that standard was given to it explicitly before generation started.
Your human reviewers are catching this after the fact, one comment at a time, on code that has already been written without the standard that should have shaped it. This is not a failure of your review process. It is a mismatch between where the standard needs to operate and where it is currently being applied.
Write the rules. Give them to the AI before generation happens. And let your review process finally focus on what it was built for instead of retroactively establishing a standard that should have been there from the start.
Want to find where your React project needs rules operating during generation instead of corrections during review?
I built a free 24 point checklist that helps you identify exactly that. The structural gaps where your standard is currently being discovered after the fact instead of applied before generation.
