doubt-driven-development

Adversarial code review introduces a fresh-context reviewer biased toward disproof rather than approval. It challenges accumulated assumptions during high-stakes architectural decisions by materializing a reviewer focused on disproving outputs before they proceed to production.

Provide an artifact and a contract, then execute the structured doubt cycle: CLAIM, EXTRACT, DOUBT, RECONCILE, STOP. This formal process audits security-sensitive production changes by forcing disproof of assumptions before allowing the output to stand.

Doubt-driven development applies across both software and data workflows. It is designed for any non-trivial, high-stakes output where context is partial, enabling rigorous adversarial examination of decisions regardless of the specific engineering domain.

Standard code review typically seeks approval, while adversarial review uses a fresh-context reviewer explicitly biased to disprove. The structured doubt cycle maintains auditable decisions by testing robustness through adversarial prompts rather than validating existing assumptions.

Adversarial review targets non-trivial, high-stakes outputs like architectural decisions and security-sensitive logic. For routine or low-stakes changes where context is complete and consequences are minimal, the rigorous doubt cycle may introduce unnecessary overhead.

Yes, doubt-driven development supports optional cross-model opinions to broaden review coverage. This expands the adversarial examination by introducing diverse fresh-context perspectives to disprove assumptions in architectural and security-sensitive decisions.