What Vercel's 57 React Rules Show About Enforcing Quality

The core of the 57 React performance rules that Vercel published is that they're organized not as abstract principles like "write efficiently," but as rules concrete enough for a machine to verify. For example: avoid barrel imports from lucide-react, parallelize independent awaits with Promise.all, and use dynamic import for components over 50KB — all written so that violations can be judged from the code alone.

Most teams write standards like this into a wiki or put them into a coding agent's system prompt. But both depend on human memory, so the wiki goes unread and the prompt only applies to whoever is using the tool. As a result, things look fine in the review screen while the same mistakes keep repeating, and the standard ends up being nothing more than documentation advice.

The solution is to turn standards into standards-as-code. If checks are kept as markdown files inside the repository and run automatically on every PR, the same criteria apply regardless of who opened it. At Continue, these checks run as full AI agents that read files and execute commands, then get reflected in the GitHub status check along with suggested fixes.

For rollout, rather than turning on all 57 at once, it's better to start with CRITICAL rules. Run the rules that lead to real user harm for a few sprints first, and once false positives are low and usefulness is confirmed, expand to HIGH, then MEDIUM.

The core change is simple.

• Standards shift from something written in docs to checks that run on every PR.
• You no longer have to rely on a reviewer's memory and attention.
• Newly joined developers are held to the same bar as senior engineers.

Ultimately, what's worth learning from Vercel's rules isn't the accumulation of knowledge but the method of enforcement. Writing it down isn't enough — a standard only becomes how the team actually operates once it runs automatically on every PR.