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 is the discipline of materializing a fresh-context reviewer — biased to disprove, not approve — before any non-trivial output stands.

This is not code-review or review. Those are verdicts on finished artifacts. Doubt-driven is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.

When a decision is "non-trivial"

At least one of these holds:

• Introduces or modifies branching logic
• Crosses a module or service boundary
• Asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)
• Correctness depends on context the future reader cannot see
• Blast radius is irreversible (production deploy, data migration, public API change)

Apply when: