Loop Engineering

把「产出—审判—修订」的循环显式写进提示词，并给出让循环不至于失效的四个部件：生产者、评审者、判定规则、终止条件。

单次生成只会给出中位水平的答案，循环才能给出好答案。本文列出每个有效循环必备的四个部件，以及缺失任一部件会导致的可预期失败，随后给出可直接套用的循环模板（批判、验证、发散、多视角），并针对「只夸不批」「停不下来」「越改越差」给出修复方法。文中还说明如何把评审者放到独立 subagent 或全新上下文中运行，使其不带感情地审阅。

# Loop Engineering

**Use when:** the output has to be excellent, not just finished.
**Works with:** any agent. Best with agents that can run commands and read files.
**Pairs with:** [quality_bar.md](quality_bar.md), [self_critique.md](self_critique.md), [rubric_scoring.md](rubric_scoring.md)

A single pass produces a median answer. A loop produces a good one. Loop engineering is the practice of writing the loop into the prompt so the model runs it without being asked again.

Every useful loop has four parts. Miss one and the loop fails in a predictable way.

| Part | What it does | If missing |
| --- | --- | --- |
| Producer | Makes the artefact | Nothing to improve |
| Judge | Finds real faults with evidence | Loop turns into praise |
| Decision rule | Says what counts as an improvement | Loop drifts and rewrites good work |
| Stop condition | Ends the loop | Loop stops after one round, or never |

---

## The master loop prompt

```text
LOOP PROTOCOL

Run every stage. Do not skip. Do not merge stages.

STAGE 0: CONTRACT
Write, in under 150 words total:
- Goal in one sentence.
- Definition of done as a checklist of statements that can each be
  checked true or false.
- Rubric: 5 to 7 scoring dimensions, each with one line describing a 10.
- Reference bar: 2 or 3 real world artefacts that represent a 10 here.

STAGE 1: DIVERGE
Produce 3 materially different approaches. Materially different means
different structure, strategy, or trade off, not different names for the
same idea. For each: one paragraph, plus its main risk.
Score all 3 against the rubric. Pick a winner. Say in one line what you
are taking from each loser.
Skip this stage only when the task has one obvious correct shape.

STAGE 2: BUILD
Build the winner completely. No placeholders, no stubs, no "left as an
exercise". If something is genuinely blocked, build everything else and
name the block explicitly.

STAGE 3: VERIFY
Check the work against reality, not against your memory.
- Code: run it, run the tests, read the actual output.
- Claims about a codebase: open the file, quote the line.
- Numbers: compute them.
Any claim you cannot back with evidence gets deleted or marked uncertain.

STAGE 4: JUDGE
Switch roles. You are now a hostile reviewer who did not write this and
wants to reject it. Your reputation depends on finding what is wrong.
List every real fault. For each:
  Severity: Blocker | Major | Minor | Polish
  Location: exact file, line, section, or element
  Why it is wrong: the concrete failure it causes
  Fix: what specifically to do
Do not invent faults to fill a quota. If you find nothing at a severity,
walk the rubric out loud and state why each dimension passes.

STAGE 5: DECIDE
For each finding, decide: fix now, fix later, or reject with a reason.
You may only change something that a finding names. If you want to
change something with no finding attached, write the finding first.
Keep the best version so far. A revision is accepted only if it closes a
named finding and lowers no other rubric dimension.

STAGE 6: REVISE
Apply the accepted fixes. Rescore the rubric.

STOP CONDITION
Return to STAGE 4 unless one of these is true:
  a) Two rounds in a row produced no finding of Major or above, and every
     rubric dimension is 9 or higher.
  b) The last round produced changes that raised no dimension score.
  c) You have run 4 rounds. Then stop and report exactly what still fails
     and why. Do not pretend it passed.

OUTPUT
Give me the final artefact first. Then a short block: what changed across
rounds, final rubric scores, and anything still open. Keep it tight.
```

---

## The cheap loop

For small tasks where the full protocol is too heavy. Costs about one extra minute.

```text
Do the task. Then reread your answer as a hostile expert reviewer and
list every real flaw with severity and a specific fix. Apply the fixes.
Show me only the fixed version plus a two line note on what you caught.
```

---

## Loop types

Different jobs need different loops. Pick one, or chain them.

### 1. Critique loop
Produce, attack, revise. The default. Stop after two dry rounds.
Best for: writing, design, API design, anything with taste involved.

### 2. Verification loop
Every claim must be backed by something you actually ran or read. Walk the claims one at a time; delete or fix any that fail.
Stop when: every claim has evidence attached.
Best for: code review, codebase questions, research, anything where being confidently wrong is the main risk.

```text
List every factual claim you just made as a numbered list. For each, name
the evidence: the command you ran and its output, or the file and line you
read. Any claim without evidence gets removed or marked "unverified guess".
Then rewrite the answer using only what survived.
```

### 3. Divergence loop
Generate N candidates, judge them against a rubric, then build a winner that steals the best parts of the losers.
Stop when: the winner beats the runners up on every dimension, or you can name the trade off you accepted.
Best for: architecture, visual design, naming, product decisions.

### 4. Perspective loop
Same artefact, one fresh lens per round. Correctness, then edge cases, then security, then performance, then accessibility, then maintainability, then a first time user.
Stop when: every lens has run once and its findings are resolved.
Best for: review of anything that ships.

```text
Review this once per lens, in this order: correctness, edge cases and
failure modes, security, performance, accessibility, maintainability,
first time user experience. One lens at a time. Do not carry the previous
lens into the next. Findings only, with severity and a specific fix.
```

### 5. Escalation loop
Cheap check first. Only go deeper when the cheap check fails.
Stop when: a check passes, or you reach the deepest level.
Best for: debugging, triage, cost control.

### 6. Ratchet loop
Keep a best so far snapshot. Each round may only accept changes that raise a score. Never accept a change that lowers one.
Stop when: no change raises a score.
Best for: long sessions where quality tends to drift down over time.

---

## Stop conditions, ranked

Use the strongest one your task allows.

1. **Objective gate.** Tests pass, the build is green, the number hits the budget. Best when it exists.
2. **Dry rounds.** Two rounds in a row with no finding above Minor.
3. **Score gate.** Every rubric dimension at 9 or above, with evidence per score.
4. **Diminishing returns.** The last round raised no score.
5. **Round budget.** Hard cap of N rounds, then an honest report of what still fails.

Always include a round budget as a backstop, even when you have a better condition. It prevents a loop that never converges.

---

## The four ways loops fail

**The critic is polite.** The model reviews its own work and finds it good. Fix: make the critic a separate role with an opposing goal, put it in a fresh message or a subagent so it does not see itself as the author, and require severity plus location on every finding.

**The critic invents problems.** A quota like "find 5 issues" causes fabrication. Fix: ask for every real fault, and when there are none, require the model to walk the rubric and justify each pass. Absence of findings must be earned, not assumed.

**The work drifts.** Each round rewrites things that were already fine, and quality wanders sideways. Fix: the decision rule. Only change what a finding names. Write the finding before making the change.

**Quality goes down.** Round 3 is worse than round 2. Fix: the ratchet. Keep the best version, accept a change only if it closes a finding and lowers nothing else.

---

## Running the judge as a separate agent

The strongest version of the critique loop puts the judge outside the producer's context.

In Claude Code:

```text
Implement X. When done, spawn a subagent whose only job is to review the
diff as a hostile principal engineer with no attachment to the code. Give
it the rubric and nothing else about your reasoning. Apply its Blocker and
Major findings, then loop until it returns two clean rounds.
```

In a plain chat tool: paste the artefact into a new conversation with only the review prompt. The model has no memory of writing it and reviews far harder.

---

## Composing loops

A strong default chain for shipping code:

```
Divergence loop (pick the design)
  -> Build
  -> Verification loop (prove the claims)
  -> Perspective loop (7 lenses)
  -> Critique loop until 2 dry rounds
```

Do not run all five on a one line change. Match the loop depth to the cost of being wrong.