DEV Community: Harel Coman

The Red Queen Code Review Pattern — Perpetual Evolution in AI-Powered Development

Harel Coman — Wed, 05 Nov 2025 08:07:16 +0000

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.

Stop “Vibe Coding”: What Worked for Me as a Front-End Tech Lead

Harel Coman — Sun, 12 Oct 2025 06:13:34 +0000

TL;DR: I built a 7-step workflow to pair with AI effectively: align on context, plan, track progress, implement in small steps, reflect, test, and run deterministic quality checks before every commit.

After more than ten years of coding, I hit a weird spot.
The tools kept getting smarter — React was rock solid, TypeScript was everywhere, and AI assistants started feeling like magic.
But my workflow? Total chaos.

Some days, I’d treat the AI like a teammate and actually collaborate. Other days, I’d just “vibe code,” throw random prompts at it, and hope for the best.
Sometimes it worked. Most of the time, it didn’t.

That’s when I realized I needed to figure out a better way to actually work with AI — not just use it.

The Problem with “Vibe Coding”

Let’s be real — AI coding assistants are amazing.

They can spin up components from a single prompt, explain code better than Stack Overflow ever did, and sometimes even save you from your own bugs.

But when I first started using them, I completely messed up my approach.

I’d let the AI take the wheel.

One day I’d say, “Build me a user dashboard,” and it would spit out 200 lines of working code.

The next day I’d ask for “a better version,” and suddenly everything looked different — styles, logic, even naming.

It was fast, sure. But it was chaos.

No consistency.

No real sense of progress.

And no way to actually learn from what worked.

Building a Systematic Approach

After months of experimentation, I developed a workflow that treats AI as a skilled collaborator rather than a code generator. It's structured, repeatable, and gives me complete control while leveraging AI's strengths. Every commit follows the same 7-step process, and every decision is intentional.

Here's exactly how I work now:

Step 1: Context & Planning 🎯

I start every feature by giving my AI assistant complete context. This isn't just about what I want to build - it's about ensuring the AI understands my codebase, patterns, and standards.

In this phase, I deliberately elaborate as much technical knowledge as possible - architecture constraints, data models, invariants, performance budgets, failure modes, and edge cases - so the plan encodes my expertise and trade-offs.

My typical prompt to Cursor:

"I need to add a table view and switcher to my card list component.

Please read the context:
- @src/components/ui/Table/Table.tsx
- @src/components/ui/ViewSwitcher/ViewSwitcher.tsx
- @src/components/Cases/Cases.tsx
- @.cursor/rules/react-development.mdc (React/TS patterns & standards)
- @.cursor/rules/quality-check.mdc (quality requirements)
- @.cursor/rules/api-development.mdc (API interaction patterns)

Now create a detailed implementation plan with:
1. Small, deliverable steps...
2. Testing strategy...
3. Component architecture...
4. Best practices to follow...

The key here is my Cursor rules - custom guidelines I maintain that ensure consistent React patterns, accessibility standards, and quality requirements. Without these, I'd be starting from scratch every time.

Note: these @...md Commands are my custom Cursor actions that encapsulate prompts and validations.

Step 2: Generate Progress Document 📋

Once I have the plan, I run my custom command: @progress-md.md. This generates a structured progress tracker that breaks the feature into small, testable steps.

The output looks like this:

# Table View Feature - Progress Tracker

## Project Overview

**Objective**: Add table view and switcher to card list
**Status**: In Progress | **Phase**: 1 of 5 | **Progress**: 0%

## Pending Steps

- [ ] **STEP-001**: Create ViewSwitcher component
- [ ] **STEP-002**: Integrate Table component with data
- [ ] **STEP-003**: Add view switching logic
- [ ] **STEP-004**: Add comprehensive tests
- [ ] **STEP-005**: Update documentation

Each step is designed to be committed independently.

This document becomes my roadmap. No more vague "implement the feature" - I know exactly what's next.

Step 3: Implement Features ⚡

Here's where the actual coding happens. I work through each step systematically, implementing small chunks that can be committed independently.

For UI components, I use another custom command: @start-playwright.md to launch Playwright. This gives the AI browser context, allowing it to see rendered components and validate interactions in real-time.

I tell Cursor: "Based on our plan, implement STEP-001. Follow the patterns in @src/components/ui/ and ensure accessibility compliance."

The result? A focused, testable component that fits perfectly into my architecture.

Step 4: Reflect on Changes 🔍

After implementation, I ran @reflect-changes.md to analyze what was built. This command validates compliance with my development patterns and identifies improvement opportunities.

Summary of Changes:
- Added ViewSwitcher component with proper state management
- Integrated Table component with existing data structure
- Used consistent styling patterns across components

React Development Pattern Compliance:
- Component Structure: PascalCase naming, proper organization
- TypeScript Usage: Proper interfaces and type safety
- Accessibility: WCAG 2.1 AA compliance, proper ARIA attributes
- State Management: Correct hooks usage and data flow

Extraction Opportunities:
- Switcher logic could be moved to a custom hook for reuse

This reflection step catches inconsistencies before they become problems.

Step 5: Add Tests 🧪

Testing is non-negotiable. I run @add-tests.md to generate user-centric tests that focus on real interactions, not implementation details.

The generated tests look like this:

describe('View switching', () => {
  it('switches between card and table views', async () => {
    render(<Cases />)
    await user.click(screen.getByRole('button', { name: /table view/i }))
    expect(screen.getByRole('table')).toBeInTheDocument()
    await user.click(screen.getByRole('button', { name: /card view/i }))
    expect(screen.getAllByTestId('case-card').length).toBeGreaterThan(0)
  })
})

These tests validate user workflows while ensuring accessibility compliance.

Step 6: Quality Assurance ✅

Before any commit, I run @precommit.md for deterministic validation. No opinions here - just tools checking my work.

Quality Checks:
✅ TypeScript compilation - No type errors
✅ ESLint - Code quality standards met
✅ Prettier - Consistent formatting
✅ Vitest - All 127 tests passing
✅ React patterns - Development standards compliance

📊 Quality metrics:
- 0 linting errors
- 0 type errors
- 98% test coverage
- All accessibility checks passed

🎯 SUGGESTED COMMIT MESSAGE:
feat: add table view and switcher to card list

✨ Key improvements:
- ViewSwitcher component for toggling between views
- Table component integration with existing data
- Accessible view switching with keyboard navigation
- Comprehensive test coverage for user workflows

If the tools pass, the code is ready. No human judgment needed.

Step 7: Commit & Continue 🚀

With validation complete, I commit using the generated message and update my progress document:

## ✅ Completed Steps

- [x] **STEP-001**: Create ViewSwitcher component ✅
  - Commit: feat: add table view and switcher
  - Validated: All quality checks passed

## 🔄 In Progress

- [ ] **STEP-002**: Integrate Table component with data 🔄
  - Status: Ready to implement
  - ETA: Next work session

Each step gets its own commit with clear value and context.

Why This Works

After 10 years of coding, I've learned that consistency compounds. Every feature I build now follows this exact process, which means:

Predictable Quality: Every commit meets the same high standards
Faster Iteration: Clear progress tracking means I can resume work instantly
AI Accountability: The structured approach prevents "vibe coding" while maximizing AI benefits
Measurable Improvement: I can optimize each step because the process is consistent

AI Should Amplify - Not Obscure - Your Expertise

There's a gut-check I run every day: do I feel my existing knowledge is being fully used? If the answer is ever "no," that's a signal I'm slipping into autopilot. The goal of this workflow is not to outsource judgment - it's to amplify it, so my advantages (taste, domain context, architectural instincts) compound through the AI, not get washed out by it.

Practically, I design each step so my expertise has to show up: I reference my own rules and patterns in prompts, I constrain options (trade-offs I care about), and I reflect on diffs with questions only I can answer ("Does this match our failure modes?" "Will this scale with our data shape?"). When that loop is present, I feel my experience steering the outcome.

If I ever feel my expertise isn't factoring into day-to-day work, I treat it as a process bug - not a personal one - and adjust the guardrails until my judgment is front and center again.

The Tools That Make It Possible

My workflow relies on several key components:

Cursor AI: The intelligent assistant that understands my codebase and patterns
Custom Cursor Rules: @.cursor/rules/react-development.mdc, @.cursor/rules/quality-check.mdc, etc.
Custom Commands: @progress-md.md, @reflect-changes.md, @add-tests.md, @precommit.md
Playwright MCP: For real browser context during UI development
Structured Progress Tracking: Living documents that guide each feature

Looking Forward

This workflow has transformed how I approach development. What used to take days of scattered effort now happens in focused, high-quality sessions. The AI isn't replacing my judgment - it's amplifying my systematic approach.

If you're considering AI-assisted development, don't just "try it out." Build the guardrails, establish the patterns, and create the consistency that lets you optimize every iteration.

The shift from traditional coding to this AI-augmented approach wasn't about the tools - it was about finding a systematic way to collaborate with them effectively.

You can see my complete workflow presentation and methodology at: github.com/haco29/ai-workflow

Who Am I

Hey, I’m Harel — a Front-End Tech Lead at Verbit.

Over the past few years, I’ve built and led React projects that grew from small ideas into large-scale ecosystems used daily by hundreds of people.

Somewhere along the way, I realized that writing great code isn’t just about knowing React or TypeScript — it’s about building systems that make other developers faster, calmer, and more confident. That’s the craft I’m obsessed with.

I love exploring tools, patterns, and workflows that bring more intention to coding — from shared UI libraries and micro frontends to AI-assisted development.

The goal is always the same: make the front end less chaotic, and coding more deliberate.

Outside of work, I’m usually chasing my two little kids around the house or over-engineering some side project for fun.

Connect with me on LinkedIn →

Note: This article was collaboratively written with AI assistance following the same structured workflow described above.