Dual-Thread Development

The Pattern

Run two parallel AI sessions on the same codebase:

Thread 1 — Builder Implements features, writes code, fixes bugs. Works fast, takes creative leaps, makes pragmatic trade-offs. Commits frequently.

Thread 2 — Auditor Reviews every change the builder makes. Catches security issues, performance problems, edge cases, and architectural drift. Has zero context contamination — it doesn't know why the builder made a choice, only what the code does.

Why This Works

The builder's biggest weakness is context bias — after writing code for 2 hours, you stop seeing your own mistakes. The auditor has fresh eyes on every diff.

Traditional code review happens after the PR is done. Dual-thread catches problems during implementation, when they're cheapest to fix.

Setup

Thread 1 (Builder)

You are the implementation thread. Your job:
1. Implement the feature/fix described below
2. Write clean, tested code
3. Commit after each meaningful change
4. Don't second-guess yourself — move fast, the auditor will catch issues

Feature: [describe what to build]
Codebase context: [key files, patterns, constraints]

Thread 2 (Auditor)

You are the audit thread. Your job:
1. Watch for new commits on this branch
2. Review each change for:
   - Security vulnerabilities (injection, auth, data exposure)
   - Performance problems (N+1, memory leaks, missing pagination)
   - Logic errors and edge cases (null, empty, boundary, concurrent)
   - Architectural drift (patterns inconsistent with codebase)
   - Error handling gaps
3. Report findings with severity: CRITICAL / HIGH / MEDIUM / LOW
4. For each finding, suggest a concrete fix
5. You have NO CONTEXT about why changes were made — judge the code on its own merits

Branch to watch: [branch name]
Codebase conventions: [key patterns to enforce]

Operating Rules

1. Builder commits frequently — small commits give the auditor granular review surface
2. Auditor doesn't block — files findings asynchronously, builder decides when to address
3. CRITICAL findings pause the builder — security or data-loss risks stop forward progress
4. Auditor doesn't rewrite — suggests fixes, doesn't implement (prevents role bleed)
5. Builder addresses findings in batches — every 3-4 commits, sweep through audit findings

When to Use

• Implementing security-sensitive features (auth, payments, data handling)
• Large refactoring where it's easy to break things
• Working with unfamiliar codebase or framework
• When the cost of a bug reaching production is high
• Any change touching more than 5 files

When NOT to Use

• Trivial changes (rename variable, fix typo)
• Exploratory prototyping where quality doesn't matter yet
• When you'll do a proper PR review anyway and time is tight

Output

Builder produces: working code, commits, PR
Auditor produces: severity-ranked findings list, suggested fixes, final sign-off or block