Every team has that one pull request.
The one that sits in review for three days. The one with twelve comments that all circle around the same underlying issue. The one where the conversation keeps going because nobody can agree on what the standard actually is.
And then next week there is another one just like it.
The review is not slow because the reviewer is slow. It is not slow because the developer did something wrong. It is slow because the AI built the feature without a standard to follow and now the review is the place where the missing standard gets negotiated in real time.
What actually happens in a slow review
Most of the time spent in a long React pull request review is not about logic.
It is about structure. Naming. Where state lives. Whether the component is doing too much. Whether the pattern matches what the rest of the codebase does.
These are not hard questions. They are standard questions. Questions that should have been answered before the first line was generated, not after the last line was reviewed.
When the AI builds a feature without rules, it makes those decisions itself. Sometimes it guesses right. Sometimes it does not. And when it does not, the review becomes the place where the correct decision gets established, one comment at a time.
That is an expensive place to establish a standard. The feature is already built. The developer already spent time on it. Now both the developer and the reviewer spend more time discussing decisions that rules would have prevented.
Why the same comments keep appearing
If you look at your last ten pull request reviews and the comments repeat, that is not a coincidence.
Repeated comments are patterns. And patterns are rules that have not been written down yet.
Every time a reviewer writes "this should be in a hook" they are communicating a rule. Every time they write "this component is doing too much" they are communicating a rule. Every time they write "this naming does not match our convention" they are communicating a rule.
The rule exists. It just lives in the reviewer's head instead of in the system the AI follows.
So the AI keeps not following it. And the reviewer keeps writing the same comment. And the pull request keeps taking longer than it should.
What changes when the rules exist before the review
When the AI has rules that define what the output must look like, the review changes completely.
The structure is already correct. The naming already follows the convention. The state is already in the right place. The component is already the right size.
The reviewer opens the pull request and reads code that matches the standard without negotiation. The comments are about logic, edge cases, product decisions. The things that actually require human judgment.
The review gets shorter. Not because standards are lower. Because the standard was already applied before the code was written.
Here is what that looks like in practice:
Rules that eliminate the most common review comments:
1. Components are presentational or container. Never both. Extract before the PR is opened.
2. State lives in a dedicated hook. No inline state management in UI components.
3. Naming follows domain language. No generic names that require a comment to understand.
Three rules. Applied before every session. The comments those rules would have generated never appear in the review.
The review is the wrong place to enforce a standard
Code review exists to catch logic errors, discuss product decisions, and share knowledge.
It was never designed to be the place where the AI standard gets established. But without rules, that is exactly what it becomes.
Every comment about consistency is a rule the AI did not have. Every repeated comment is a rule the AI still does not have. And every slow pull request is the cost of enforcing a standard at the end of the process instead of the beginning.
The prompt does not matter. The rules do.
The review that never ends is not a review problem. It is a missing rules problem.
Define the standard before the first session. Give it to the AI before it generates anything. And let the review be about the work that actually matters.
Want to find which review comments should already be rules in your React project?
I built a free 24 point checklist that helps you find exactly that. The structural gaps that keep showing up in your reviews because the AI never had rules to prevent them.
Top comments (0)