80/20 Review Pattern

“80% of my code is written by AI, 20% is spent reviewing and correcting it.” — Andrej Karpathy

​

The Problem with Constant Review

Edit file 1 → Review → Edit file 2 → Review → Edit file 3 → Review
  ↑           ↑         ↑           ↑         ↑           ↑
  2 min       3 min     2 min       3 min     2 min       3 min

Total: 15 minutes (only 6 minutes of actual progress)

• Context switching overhead
• Interrupts AI’s flow
• Reviews often find nothing wrong
• Slows down iteration speed

​

The 80/20 Solution

Edit 5 files → Checkpoint Review → Edit 5 more → Checkpoint Review
  ↑              ↑                   ↑              ↑
  10 min         5 min               10 min         5 min

Total: 30 minutes for 10 files (vs 45 minutes with constant review)

• 33% faster overall
• Better context (see changes together)
• AI maintains flow between reviews
• Reviews are more thorough (not rushed)

​

Review Checkpoints

​

Checkpoint 1: After Plan Approval

• Does the plan make sense?
• Are all affected files identified?
• Are risks and mitigations reasonable?
• Is the approach aligned with project patterns?

PLAN: Add Webhook Support

Files to modify: 4 files
New files: 2 files
Approach: Event-driven with retry logic
Risks: High volume, circular webhooks

✓ Review: Plan approved, proceed

​

Checkpoint 2: Every 5 File Edits

• Are changes following the plan?
• Any obvious bugs or logic errors?
• Tests passing?
• Ready to continue or need course correction?

CHECKPOINT: 5 files edited

Completed:
✓ src/models/webhook.ts - Model validation
✓ src/api/events.ts - Event hooks
✓ src/services/delivery.ts - HTTP delivery
✓ src/queue/webhook-queue.ts - Retry logic
✓ migrations/001-webhooks.sql - Schema

Tests: 18/18 passing
Typecheck: Clean

→ Continue to next 5 files

​

Checkpoint 3: Before Destructive Operations

• git commit (review before committing)
• git push (double-check before pushing)
• File deletion (verify files should really be deleted)
• Schema changes (migrations are hard to reverse)
• npm publish (can’t unpublish)

About to commit:
  M src/models/webhook.ts
  M src/api/events.ts
  A migrations/001-webhooks.sql
  D old-webhook-implementation.ts  ← Verify deletion

Pause for review before commit.

​

Checkpoint 4: At Wrap-Up

• All changes across the session
• Uncommitted work
• TODOs or console.log statements
• What was learned?
• Any corrections to capture?

/wrap-up

​

Between Checkpoints: Trust Mode

​

Quality Gates

# Automatically run relevant tests
npm test -- path/to/changed-file.test.ts

# Run full quality check
npm run lint
npm run typecheck  
npm test

# Final validation
npm run lint
npm run typecheck
npm test -- --coverage

​

Hook Integration

{
  "hooks": {
    "PreToolUse": "Track edit count. Remind at 5, 10, 15 edits."
  }
}

{
  "hooks": {
    "PreToolUse": "Before git commit/push, remind about quality gates."
  }
}

{
  "hooks": {
    "Stop": "If >5 edits since last checkpoint, suggest review."
  }
}

​

Review Checklist

​

When to Pause Mid-Flow

• Tests suddenly break
• Error messages you don’t understand
• AI asks a clarifying question
• Approach seems wrong
• About to make a destructive change

• Stylistic preferences (add to LEARNED instead)
• Minor improvements (note for later)
• Curiosity about implementation (trust the process)

​

Correction Workflow

[LEARN] Error Handling: Webhooks should not retry on 404 (permanent failure)

​

Metrics and Analytics

/insights

• Corrections per checkpoint: Should decrease over time
• Issues found: More at early checkpoints vs late (front-load validation)
• Time between checkpoints: Should be consistent (5 files or ~20 min)
• Tests catching issues: High number means good test coverage

​

Comparison: Constant vs Checkpoint Review

​

Best Practices

​

Do

​

Don’t

​

Integration with Other Patterns

• Each phase has its own review checkpoint
• Research phase: review confidence score
• Plan phase: review plan before implementation
• Implement phase: review every 5 edits
• Final phase: wrap-up review

• Corrections found at checkpoints → [LEARN] rules
• Rules prevent same issues at future checkpoints
• Checkpoints become faster over time

• Each teammate reports at checkpoints
• Lead reviews all teammate outputs together
• Synchronization points prevent conflicts

​

Real-World Example

9:00 AM - Planning Phase
  → Review: Plan approved (Checkpoint 1)

9:15 AM - Implementation starts
  → Edit: 5 files (models, services, routes)
  → Tests: All passing
  → Checkpoint 2: Review, all good

9:35 AM - Continue implementation  
  → Edit: 5 more files (tests, migrations, docs)
  → Tests: All passing
  → Checkpoint 3: Found issue with migration
  → Fix: Update migration script
  → Verify: Tests still passing

9:55 AM - Quality gates
  → Lint: Clean
  → Typecheck: Clean  
  → Tests: 45/45 passing
  → Checkpoint 4: Ready to commit

10:00 AM - Commit
  → Review git diff (Checkpoint 5)
  → Commit with conventional message
  → /wrap-up (Checkpoint 6)

Total: 1 hour, 10 files edited, 1 issue found and fixed

Without checkpoints: Would have taken 1.5 hours with constant review

​

Adjusting Checkpoint Frequency

​

Next Steps