doubt-driven-development

Use the doubt cycle: write a compact CLAIM, extract the artifact and its contract, then spawn a fresh-context reviewer with an adversarial find-issues prompt. Classify each finding against the artifact text and stop after trivial findings, 3 cycles, or user override.

Code review is a post-hoc verdict on a finished artifact like a pull request. Doubt-driven development is an in-flight posture that cross-examines individual non-trivial decisions while course-correction is still cheap, and the two are complementary.

Skip it for mechanical operations like renaming or formatting, one-line changes with obvious correctness, reading or summarizing code, pure tooling operations, and when the user explicitly prioritizes speed over verification.

Yes, after verifying the binary works, write the adversarial prompt plus artifact and contract to a file and pipe it via stdin with a read-only sandbox, such as codex exec --sandbox read-only or gemini --approval-mode plan. Never interpolate artifacts into shell-quoted arguments.

Passing your conclusion biases the reviewer toward agreement, defeating the purpose of fresh-context review. The reviewer must independently determine whether the artifact satisfies the contract, so only ARTIFACT and CONTRACT are passed.

It cannot run nested inside a subagent context, where only a degraded self-questioning fallback is possible. It also adds latency and cost per decision, so it is scoped strictly to non-trivial decisions rather than every keystroke.