惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
Microsoft Security Blog
Microsoft Security Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 叶小钗
博客园 - 三生石上(FineUI控件)
爱范儿
爱范儿
T
Tailwind CSS Blog
F
Fortinet All Blogs
Blog — PlanetScale
Blog — PlanetScale
WordPress大学
WordPress大学
H
Help Net Security
Apple Machine Learning Research
Apple Machine Learning Research
Y
Y Combinator Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
GbyAI
GbyAI
Martin Fowler
Martin Fowler
有赞技术团队
有赞技术团队
腾讯CDC
V
V2EX
Jina AI
Jina AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
B
Blog
M
MIT News - Artificial intelligence
宝玉的分享
宝玉的分享

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Your React Pull Requests Take Too Long to Review. The AI ...
Avery · 2026-06-02 · via DEV Community

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.

Repeated review comments are not a sign that developers are not learning. They are a sign that the standard has not been given to the AI that is generating the code.

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.

Enter fullscreen mode Exit fullscreen mode

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.

Get the React AI Clean Code Checklist — free

Avery Code React AI Engineering System