doubt-driven-development

Adversarial code review subjects non-trivial outputs to fresh-context scrutiny, surfacing unstated assumptions, edge cases, and risk in-flight before deployment. It uses doubt-driven development to enforce a five-step cycle, ensuring correctness when verifying decisions upfront is cheaper than debugging later.

To perform a fresh-context review for architectural decisions, present the artifact and contract, execute an adversarial review on the artifact, and reconcile the findings with the contract. This in-flight decision review process enforces a five-step doubt cycle to surface flaws.

Use doubt-driven development instead of standard code review when correctness matters more than speed, such as for architectural changes, unfamiliar codebases, or high-stakes production risks. It is best suited for non-trivial decisions where verification is cheaper upfront than debugging later.

Yes, this development process handles edge cases in unfamiliar codebases by applying adversarial prompts to surface unstated assumptions and risk in-flight. It guides decision-making by subjecting non-trivial outputs to fresh-context adversarial scrutiny to surface flaws.

A key limitation of this adversarial review process is that it prioritizes correctness over speed, making it less suitable for rapid, low-stakes iterations. It enforces a rigorous five-step doubt cycle for non-trivial decisions, which may introduce unacceptable latency for trivial code changes.

The five-step doubt cycle for in-flight decision review is CLAIM, EXTRACT, DOUBT, RECONCILE, and STOP. It facilitates rigorous output scrutiny by subjecting non-trivial decisions to fresh-context adversarial review to surface unstated assumptions and reconcile findings with the contract.