doubt-driven-development

Doubt-Driven Development

A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development materializes a fresh-context reviewer — biased to disprove, not approve — before a non-trivial output stands. This is not a final code review: a final review judges a finished artifact, while this is an in-flight posture applied while course-correction is still cheap.

When to use

A decision is non-trivial when at least one is true: it introduces or modifies branching logic; it crosses a module or service boundary; it asserts a property the compiler/type system can't verify (thread safety, idempotence, ordering, invariants); its correctness depends on context a future reader can't see; its blast radius is irreversible (production deploy, data migration, public API change).

Don't use it for: mechanical operations (renaming, formatting, moving files), a clear unambiguous instruction, reading or summarizing existing code, a one-line change with obvious correctness, or when the user has explicitly asked for speed over verification. Doubting every keystroke means shipping nothing.

The process

CLAIM ──→ EXTRACT ──→ DOUBT ──→ RECONCILE ──→ STOP

1. CLAIM — name what stands

State the decision in two or three lines:

CLAIM: "The new caching layer is thread-safe under the read-heavy
        workload described in the spec."
WHY IT MATTERS: a race here corrupts user data and is hard to
                detect in QA.

If you can't write the claim that compactly, it's a vibe, not a decision — surface it before scrutinizing it.

2. EXTRACT — the smallest reviewable unit

A fresh-context reviewer needs the artifact and the contract, not the journey that produced them: the diff or function (not the whole file), the proposal in 3-5 sentences plus the constraints it must satisfy. Strip your own reasoning — handing over conclusions gets back validation of those conclusions, not independent scrutiny. If the unit is too large to hold in mind in one read (a 500-line PR), decompose first.