Iteration Loops: Critique-and-Refine Patterns
Prompt Engineering Mastery gave you the Critic and Refine patterns. This lesson makes them operational — five ways to run a critique-and-refine loop on today's actual work without it running forever.
Prompt Engineering Mastery already gave you the Critic pattern (ask AI to evaluate its own output against explicit criteria) and the Refine pattern (feed the critique back in for a revision). If you've been through that track, you know the theory. This lesson is about running that loop for real, on today's actual work, without it either stopping too early or never stopping at all.
That second failure mode is the one that costs people the most time. A refine loop with no stop condition doesn't fail loudly — it fails by quietly eating an afternoon on the eleventh "just one more pass" revision of something that was good enough on pass four.
Pattern 1: Rubric-Gated Revision
Write the rubric before the first draft exists. Revise only against the rubric — never against a vague sense that something feels off.
Before you draft [TASK], first write a rubric: 4-6 specific, checkable
criteria this output must meet. Number them.
Then draft [TASK].
Then evaluate your own draft against EACH numbered rubric item — pass
or fail, with a one-line reason for any fail.
Revise only the items that failed.
When it works: Any recurring output type — proposals, PR descriptions, status updates — where "good" has a definable shape even if it varies task to task. Writing the rubric first also forces you to know what you actually want before you see something that might talk you out of it.
When it fails: If you write the rubric AFTER seeing a draft, it silently reshapes itself around whatever the draft already does — you're no longer measuring quality, you're rationalizing the output you happened to get. This names the same trap Critic-pattern users hit in the craft track when they let the critique run on vibes instead of predefined criteria.
Pattern 2: Diff-Only Iteration
Ask for a changelist against the previous version, not a full regeneration — so you can review exactly what moved without re-reading the whole thing.
Here is the current draft: [DRAFT]
Revise it to [SPECIFIC CHANGE]. Do NOT regenerate the whole thing.
Return only:
1. A list of what changed, one line per change
2. The full revised draft
I need to verify the changelist matches the actual diff before I accept it.
When it works: Long documents, code, or anything where a full regeneration makes it expensive to spot what actually moved — and where an unreviewed regeneration risks silently changing something you didn't ask to change.
When it fails: If you don't cross-check the stated changelist against the actual returned text, you're trusting a summary that can drift from what was really changed. Diff-Only Iteration reduces review effort; it doesn't eliminate the need to verify.
Pattern 3: A/B Prompt Duel
Run two variant prompts against the same input, then compare outputs side by side before picking one — instead of iterating serially on a single thread and anchoring on whatever you saw first.
Generate TWO variants of [TASK] using different approaches:
VARIANT A: [APPROACH A, e.g. "lead with the data"]
VARIANT B: [APPROACH B, e.g. "lead with the recommendation"]
Present them side by side. Then list 2-3 specific tradeoffs between them
— don't just declare a winner.
When it works: Decisions where the approach is genuinely uncertain, not just the wording — should this email lead with the ask or the context, should this doc open with a summary or a walkthrough. Seeing two real options side by side beats imagining the option you didn't take.
When it fails: Running more than two variants at once turns comparison into cognitive overload — you stop evaluating and start pattern-matching for whichever one "feels" longest or most confident. Two variants, real tradeoffs, then decide.
Pattern 4: Regression Watch
When refining, explicitly check that the revision didn't break something that was already working — the classic trap where fixing item 4 quietly reintroduces the bug you fixed in item 2.
Here is the previous draft: [PREVIOUS]
Here is the revised draft: [REVISED]
Before confirming this revision, check: does the revised draft still
satisfy everything the previous draft got right? List anything that
regressed, even if it wasn't part of this revision's target.
When it works: Multi-pass revisions on anything with several independent correctness criteria — code with multiple test cases, a document with multiple stakeholder requirements. The more passes you run, the more this matters, because each pass is a new chance to step on an earlier fix.
When it fails: If you only check the specific thing you asked to change and skip the regression check entirely, you'll ship a draft that's better on the dimension you targeted and quietly worse on one you weren't looking at.
Pattern 5: Bounded Refine Loop
Set an explicit stop condition before you start — a rubric-met state OR a maximum iteration count — so the loop has a defined exit instead of running until you get tired of it.
Run a refine loop on [TASK] against this rubric: [RUBRIC ITEMS].
Rules:
- After each revision, re-check against every rubric item
- STOP when all items pass, OR after [N] iterations, whichever comes first
- If you stop at [N] iterations without passing, say so explicitly and
list which items still fail — don't present it as finished
When it works: Anything where "keep iterating" is tempting to do indefinitely — you need a forcing function that ends the loop on a real condition, not on exhaustion.
When it fails: If the stop condition is just a raw iteration count with no quality bar attached, you'll accept a mediocre draft on iteration N purely because the loop said "done" — the cap alone isn't a quality signal, only a time limit. Pair it with a rubric (Pattern 1) so the loop can also exit early and honestly, on merit.
Where the Craft Track Comes In
Critic and Refine are the named patterns in Prompt Engineering Mastery — this lesson assumes you either know them or are willing to look them up, and focuses entirely on making them operational: what rubric, what stop condition, what gets diffed, what gets compared. If you want the theory behind why self-critique improves output quality, that's where it lives.
Build It
The BuildChallenge below has you build runRefineLoop — a bounded-loop function (same shape as the agent loop you may have built in Codex Basics Lesson 527) that iterates a mock critique/revise cycle against a rubric and stops on either all-checks-pass or max-iterations, reporting which case actually triggered the stop.
Bottom Line
Five patterns that turn "keep revising until it feels right" into something you can actually run under a deadline: Rubric-Gated Revision defines quality before you see a draft. Diff-Only Iteration keeps review effort flat as documents grow. A/B Prompt Duel surfaces real tradeoffs instead of anchoring on the first attempt. Regression Watch stops fixes from creating new breaks. Bounded Refine Loop gives the whole cycle an honest exit. That's all eight job-function lessons. Next: the capstone — assembling the patterns you'll actually keep into one personal library.