TL;DR: I built a feedback loop where every AI code review either fixes the code or evolves the rule — creating a self-improving system that keeps our team’s standards alive as both humans and AI adapt.
Like the Red Queen Hypothesis in evolution, the goal isn’t to win — it’s to keep evolving just to stay aligned.
In other words, it's a system that evolves with you, not just for you.
This article introduces a framework I call The Red Queen Code Review Pattern — a way to make code reviews self-evolving through human-AI collaboration.
The Red Queen Effect 🧬
In evolutionary biology, the Red Queen Hypothesis describes a race with no finish line.
It comes from Lewis Carroll’s Through the Looking-Glass, where the Red Queen tells Alice:
“It takes all the running you can do, to stay in the same place.”
— Lewis Carroll, Through the Looking-Glass (1871)
Biologists use this idea to explain how species must constantly evolve just to survive, because their environment — and everything competing within it — is also evolving.
Gazelles run faster, lions hunt faster — neither “wins,” but both must keep adapting or fall behind.
In AI-powered development, we face the same dynamic.
Our tools learn, our frameworks shift, our patterns change — and our code reviews can’t stay static.
Every time the AI flags an outdated rule, we evolve it — and the race continues.
Every time it enforces a pattern, our team runs a little faster to stay consistent.
That’s the Red Queen Code Review Pattern:
a system where humans and AI co-evolve through feedback.
Each cycle keeps our rules relevant, our code consistent, and our development process alive.
Fix the code → follow the rule.
Update the rule → evolve the system.
Either way, the race never stops — and that’s exactly the point.
After years of doing code reviews, I hit a frustrating pattern.
Same type of issue. Different reviewers. Completely different feedback.
Developer A would flag a magic number. Developer B would approve the exact same pattern.
Six months later, our codebase looked like it was written by five different teams.
Then I started using AI to write code, and it got worse.
Cursor would generate perfectly valid React code that violated our unwritten patterns. I'd ask for revisions, but there was no source of truth to reference. Just vibes and inconsistent PR comments.
That's when I realized: if my rules aren't written down, my AI assistant can't follow them. And neither can my team.
The Moment It Clicked
Last week, I finished a feature and ran my usual code review command. Cursor analyzed my branch against main and came back with this:
### src/components/UserProfile.tsx
**Issue:** Using axios directly instead of HttpClient
**Rule Violated:** api-development.mdc - "Always use HttpClient for API requests"
**Suggestion:** Replace axios with HttpClient static methods
Normally, I'd just fix it and move on.
But this time I stopped.
The rule was outdated. We'd decided weeks ago that direct axios was fine for one-off requests. But I never updated the documentation.
So I had two options:
Option A: Fix the code (and get the same comment next time)
Option B: Update the rule (and never see this comment again)
I updated the rule.
And that's when it hit me: every code review comment is either validating a rule or exposing an outdated one.
The system I built — what I now call the Red Queen Code Review Pattern — runs as a simple Cursor command called @code-review.md.
You can see the implementation and rule examples on GitHub → haco29/ai-workflow
It’s not fancy. Just a markdown-driven feedback loop that keeps evolving with every review.
Here's the workflow I've been using:
1. Document Standards as Cursor Rules
I keep all our patterns in .cursor/rules/*.mdc files:
.cursor/rules/
├── react-patterns.mdc # Component architecture
├── api-development.mdc # API patterns
├── code-quality.mdc # Constants, errors
├── testing-accessibility.mdc # Testing & WCAG
└── python-core-architecture.mdc # Backend patterns
These aren't vague guidelines. They're concrete examples:
## HTTP Status Codes
❌ Never use magic numbers:
if (error.response?.status === 401) { redirect('/login') }
✅ Always use constants:
import { AUTHENTICATION_ERROR_STATUS_CODE } from '@/constants'
if (error.response?.status === AUTHENTICATION_ERROR_STATUS_CODE) {
redirect('/login')
}
When I write new features, Cursor reads these rules and generates code that follows our patterns automatically.
2. Run Automated Code Review
I created a Cursor command called @code-review.md that:
- Diffs my branch against main
- Reads all rules from
.cursor/rules/ - Reviews every change against those rules
- Provides structured feedback with explicit rule references
The output looks like this:
## 🔴 Critical Issues (Must Fix)
### app/services/user_service.py
**Issue:** Missing error handling decorator
**Rule Violated:** python-core-architecture.mdc -
"All service methods must use @handle_service_errors"
**Suggestion:** Add the decorator
# Current
async def get_user(user_id: str) -> User:
return await db.users.get(user_id)
# Suggested
@handle_service_errors
async def get_user(user_id: str) -> User:
return await db.users.get(user_id)
Every issue points to a specific rule. Every suggestion includes code.
3. The Feedback Loop
This is the key part.
When I get a review comment, I ask myself: Is the rule right?
If yes → Fix the code.
If no → Update the rule.
This creates a self-improving system:
Code Review → Rule Violation Found →
Fix Code OR Update Rule →
Next Review Uses Updated Standards →
Codebase Stays Consistent
Over time, the rules get better. The AI learns our actual patterns. And new team members can run the same review on their PRs to learn our standards instantly.
What This Actually Looks Like
Before: Random Feedback
PR #1:
Reviewer: "Can you add error handling here?"
Developer: "Sure... what kind?"
Reviewer: "Just try-catch I guess?"
PR #2 (Same Pattern):
Reviewer: "Looks good ✅"
After: Consistent Standards
PR #1:
**Rule Violated:** python-core-architecture.mdc
**Suggestion:** Use @handle_service_errors decorator
PR #2 (Same Pattern):
**Rule Violated:** python-core-architecture.mdc
**Suggestion:** Use @handle_service_errors decorator
Same issue. Same comment. Every time.
Reviewing Other People's Code
This system shines when I review someone else's work.
I checkout their branch and run @code-review.md. The AI generates structured feedback I can copy directly into GitHub:
**Rule Violated:** Security Guidelines - "Never store secrets in code"
**Suggestion:** Replace with environment variable or AWS Secrets Manager
Instead of my usual:
"um... maybe don't hardcode that?"
The author immediately knows:
- What rule was violated
- Where it's documented
- How to fix it
- Whether the rule needs updating
No more vague feedback. No more "I think we should..." discussions.
Why This Actually Works
1. AI Generates Consistent Code
Cursor reads my rules before generating code. Instead of random patterns:
// Random patterns from AI
const data = await axios.get('/api/users')
const users = await fetch('/api/users')
const result = await httpClient.get('/api/users')
I get consistent code that matches our standards:
// Follows documented pattern
const users = await HttpClient.getUsers()
2. New Developers Learn Faster
New team members run @code-review.md on their first PR. They instantly see what patterns we follow and why.
No more "how do we handle errors here?" questions. The rules show concrete examples.
3. Less Bikeshedding in PRs
Debates end faster:
Dev: "Should we use axios here?"
Reviewer: "Check api-development.mdc - we use HttpClient"
Dev: "Got it, fixing"
Or:
Dev: "The rule says HttpClient, but this is a one-off call"
Reviewer: "Good point. Update the rule to include the exception"
The conversation shifts from opinions to whether the rule is right.
4. Code Reviews Focus on What Matters
Instead of catching style issues, reviewers focus on:
- Business logic correctness
- Edge cases
- Architecture decisions
- Security implications
The boring stuff gets caught automatically.
The Gut Check
There's something I think about every time I review code now: Is my expertise actually being used here?
If I'm just checking for formatting or patterns we've agreed on, that's a waste of my time. The AI should catch that.
If I'm evaluating trade-offs, thinking about failure modes, or spotting subtle bugs, that's where I add value.
This system automates the first part so I can focus on the second.
When I feel like I'm just rubber-stamping PRs, that's a signal. Either the rules need updating, or I need to look deeper at the actual logic.
Common Questions
"Isn't this just a linter?"
No. Linters catch syntax. This catches:
- Architecture violations (logic in wrong layer)
- Missing patterns (forgot to use our HttpClient)
- Security issues (hardcoded secrets)
- Accessibility problems (missing ARIA labels)
"Won't this slow down development?"
It speeds it up. Less back-and-forth in PRs. Fewer surprises. AI generates correct code the first time.
"What if we disagree on a rule?"
Perfect. Discuss it once. Document the decision. Never discuss it again.
The rule can include the why so future developers understand the reasoning.
Start Small
You don't need 50 rules to see benefits.
Start with:
- One rule file for your biggest pain point
- The code review command
- The feedback loop (fix code OR update rule)
Run it on your next PR. See what happens.
You can see my complete code review command and rule examples at my GitHub: github.com/haco29
In a world where tools evolve faster than teams, the only sustainable strategy is to evolve with them.
That’s the Red Queen race — and it’s how we keep our standards alive.
Note: This article was collaboratively written with AI assistance following a structured workflow.
Top comments (0)