doubt-driven-development

Doubt-Driven Development

Overview

For most code, optimism is fine: try it, run the test, fix what breaks. For changes you cannot cheaply undo, optimism is a liability. Doubt-driven development inverts the default — you actively try to refute your chosen approach before you build it, and you require concrete evidence to clear each doubt.

Core principle: default to refuted when uncertain. A doubt you cannot disprove with evidence is a reason to choose a safer path, not a reason to proceed and hope.

This is review applied during the build, by you, before a single line is committed. It is distinct from [[validate]], the post-hoc multi-agent loop that runs after implementation — that catches what got built wrong; this catches what should never have been built that way.

When to Use

Apply when the change is high-stakes or hard to reverse:

• Schema / data migrations — backfills, column drops, type changes, anything that mutates existing rows
• Authentication / authorization — session handling, token validation, permission checks
• Payments / billing — charges, refunds, idempotency, money math
• Public API surface — endpoints or contracts other teams or users depend on
• Destructive / irreversible operations — deletes, overwrites, bulk updates, cache purges
• Concurrency — locking, ordering, race-prone shared state

Routine, easily-reverted CRUD does not need this. Reserve the ceremony for blast radius.

Process

1. Name the decision

State the high-stakes decision in one sentence, explicitly. "I will run the backfill in a single transaction over the whole table." Vague intent cannot be refuted. If you cannot name it crisply, you do not understand it well enough to commit to it.

2. Adopt the skeptic stance — refute, don't defend

Before implementing, switch jobs. Your job is now to break the chosen approach, not to justify it. Produce, in writing:

• How it fails — concrete failure modes, not "it should be fine"
• What it breaks — existing callers, data, invariants, in-flight requests
• What would disprove it — the specific observation that would prove the approach wrong (the row count mismatches; the lock is held > N seconds; the old client gets a 500)