Turning Code Reviews into a System That Learns

Almost nobody does strict Test-Driven Development for an early-stage MVP.

Requirements change daily, product assumptions are fluid, and writing exhaustive test suites before touching code feels like too much overhead. Lots of early teams rely on manual testing and PR review to catch mistakes.

That trade-off worked when it was just humans writing code at human speed.

Once you introduce coding agents, that completely falls apart. An agent can generate several hundred lines of code in minutes. Reviewing all that code by hand doesn’t just slow you down. It quickly becomes an endless loop of leaving the exact same comments across different PRs.

The problem here is treating agent’s mistakes as one time bugs instead of systematic ones.

---

1. Eliminate the Entire Class at the Root, Never Just Patch the Instance

When review or QA catches an error, the natural instinct is just to patch that file:

• A component uses #f7f7f7 directly? Swap it for var(--surface-secondary).
• An endpoint misses an authorization check? Add an if (!user.isAdmin) guard.
• A concurrent invite acceptance creates a duplicate membership? Patch the route handler with an extra lookup.

Patching the file fixes the immediate bug. But it does nothing to stop the agent from doing the exact same thing in the very next PR.

flowchart TD
    subgraph Reactive ["The Reactive Review Wheel (Symptom Patching)"]
        R1[PR Opened] --> R2[Reviewer Finds Flaw]
        R2 --> R3[Human Comments on PR]
        R3 --> R4[Agent Patches Single File]
        R4 --> R5[Next PR Repeats Same Mistake]
    end

    subgraph Ratchet ["The Learning Ratchet (Root Elimination)"]
        L1[PR Opened] --> L2[Linter / Constraint Fails]
        L2 --> L3[Agent Self-Corrects in Loop]
        L3 --> L4[Rule Permanently Enforced in Repo]
    end

A systematic fix tackles the whole category at the root:

Core Principle: If you have to leave the same review comment twice, you don’t have a code problem; you have a tooling or context problem.

If a problem can be caught by a machine, leaving a review comment is a waste of time. You eliminate the whole category at the root so nobody has to review it again.

---

2. Lock Upfront Invariants, Not Exhaustive Unit Test Suites

Skipping strict TDD doesn’t mean building with zero guardrails.

You don’t need 100% test coverage for an MVP, and you definitely don’t need to mock every API or test every little helper function.

You just need two or three core invariants: the non-negotiable rules that have to hold no matter how the feature gets built.

Say you need an organization invitation flow. Before prompting the agent to write the feature, write executable checks for the boundary conditions:

1. Expired tokens cannot be redeemed.
2. The same invitation token cannot be redeemed twice.
3. Acceptance must yield exactly one membership with the assigned role.

Write boundary tests → Agent generates implementation → Run checks → Agent self-corrects until green

These checks define what cannot break without micromanaging how the agent writes the code. The agent can rearrange UI, tweak DB queries, or refactor routes, as long as those core checks stay green.

---

3. When Qualitative Review Findings Repeat, Promote Them into Agent Instructions

Not every issue can be caught by a linter or a database rule.

Lots of patterns are contextual:

• Choosing between server components and client components.
• State management and query cache invalidation patterns.
• Error response shapes and user-facing copy conventions.
• Architectural boundaries between modules.

In traditional teams, these live as unwritten conventions or scattered PR comments. With coding agents, that means things slowly drift off track.

The rule of thumb: once a qualitative review comment repeats a second time, take it out of review and write it straight into AGENTS.md (or your repository instructions).

## Data Fetching Invariant
- DO NOT fetch raw queries inside leaf UI components.
- ALWAYS route queries through the repository layer (`src/lib/db/*`).
- Invalidate queries via cache manager upon mutation, not by reloading.

Agents are much better at following explicit rules than guessing what you want. Giving them clear anti-patterns (“Don’t do X; do Y instead”) turns yesterday’s PR comments into today’s guardrails.

---

4. The Three-Tier Enforcement Model: Manufacturing Gravity in a Greenfield Repo

Mature codebases naturally keep coding agents in line. Years of type definitions, battle-tested utilities, strict CI pipelines, and established patterns force the agent into acceptable shapes.

A brand-new codebase doesn’t have that gravity. You have to build it intentionally, without killing your momentum:

By using code review to feed these three layers, you stop paying for the same mistake twice. The repository builds up memory over time, human review gets lighter, and you keep moving fast without letting the codebase turn into a mess.