Generate → Review → Fix Loop

Overview

For non-trivial implementation work, use three distinct stages: a coding model drafts, an independent audit model compares the draft with the contract, and the coding model revises from that review. This reduces the chance that a single model overlooks its own edge cases; it does not replace a real test.

Procedure

1. Give the generator the full task contract, relevant code, constraints, and expected verification.
2. Give a different reviewer the task contract and generated diff. Ask for concrete defects, missing cases, and unsupported assumptions. For each finding, state what must be true on that path after the repair, not only the symptom. Mark each finding CONFIRMED only if the reviewer executed the case and recorded observed values, otherwise SUSPECTED (reasoned only, including could-not-execute). Keep suspected findings in the review; do not apply them as repairs until confirmed or shown red by a test. See specs/the-silent-clear-problem.md.
3. Give the generator the review and require a revised final result. Preserve the review and final output. Repair only concrete defects, missing cases, and unsupported assumptions. Record and leave unapplied findings that are only style or idiom. A same-file fact the change alters remains in scope.
4. Functionally test the final result in the repository before reporting it as verified.

Role selection

• Use a coding-oriented local model for draft and repair.
• Use a distinct audit-oriented model for review; do not have the generator self-review as the only gate.
• Prefer a more thorough reviewer for high-risk or edge-case-dense changes.

Pitfalls

• Shipping the draft rather than the repaired output.
• Treating review as proof of runtime behavior.
• Spending the multi-stage process on a trivial one-line edit when direct verification is cheaper.
• Reviewing only the diff when the change alters a fact the same file asserts elsewhere. The reviewer's unit is then the file, and the search covers the old value and the subject's constraint language, not the old value alone. See specs/rigor-spectrum.md lesson F.

Verification checklist

• Generator and reviewer were separate roles.
• The repair addressed the review rather than merely restating it.
• The final revision, not an earlier draft, was tested.
• Every finding carried its CONFIRMED/SUSPECTED label, and each unapplied finding was recorded as either style or idiom only, or SUSPECTED and not yet confirmed or shown red by a test.