Skip to content

Iterative Refinement

Ratified

First draft, then polish. Repeat until done.

Generate initial output, then run additional passes that:

  • Identify specific weaknesses
  • Make targeted improvements
  • Know when to stop (diminishing returns)
  • Creative or complex output that benefits from revision
  • Tasks where “good enough” isn’t good enough
  • When feedback loops are cheap relative to the value of improvement
  • Output that will be seen by humans and quality matters
  • A runnable check exists; use Verification Loops instead
  • The first draft already meets the bar
  • No stopping criterion can be stated
  • Each pass should have a specific focus (clarity, accuracy, brevity)
  • Define stopping criteria: score threshold, max iterations, or a change threshold (stop when a pass changes less than it)
  • Later passes should see the evolution, not just the current state
  • Track what changed to detect loops or regressions
  • Clarity: Is this understandable to the audience?
  • Accuracy: Are all claims correct and supported?
  • Brevity: Can this be shorter without losing meaning?
  • Completeness: Is anything missing?
  • Tone: Does this match the intended voice?
  • Illustrative case (hypothetical)
  • Output: a migration guide for an API version change
  • Pass 1, accuracy: check every endpoint named against the changelog; two renamed fields fixed
  • Pass 2, completeness: compare against the list of breaking changes; one missing section added
  • Pass 3, brevity: cut 30% with no loss of steps
  • Stop: the fourth pass changed only wording, below the change threshold, so stop
  • Infinite loops (no stopping criteria)
  • Passes that undo each other’s work
  • Refining when the first draft was already good enough
  • Over-polishing low-stakes output