There's a reason the people who build AI stopped prompting it one request at a time. This page explains the habit they switched to — loop engineering — with the receipts, the failure data, a worked example you can watch run, and the exact text file. Nothing else.
"I do not prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops."
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
✗ "write me a marketing plan" # zero decisions → the model returns the average of # every plan it has ever seen ✓ ROLE who the AI should be ✓ DELIVERABLE exactly what to produce ✓ CONSTRAINTS audience · tone · limits ✓ FORMAT the shape of the output
Start with the part you may already know. A language model is a prediction machine: given your words, it produces the most statistically likely continuation. Hand it a request that decides nothing and it has no choice but to return the average of everything it has seen — grammatical, plausible, and written for nobody. The generic answer isn't the model being lazy. It's the model faithfully mirroring a generic request.
The fix is to make the decisions yourself before the model can guess them: who the AI should be, what exactly it must produce, under which constraints, and in what shape. Each decision collapses thousands of possible "marketing plans" down toward the one you actually need. That's the entire skill people call prompt engineering — four decisions, not forty tricks. (It gets its own chapter: Chapter 01 — from wishing to guaranteed results.)
And it has a hard ceiling that almost nobody says out loud: a specification, however good, buys exactly one attempt. Real work — a plan you'd present, an email you'd send, code you'd ship — is never attempt one.
Here's what actually happens after attempt one. You read the draft. You notice the tone is off and the third section missed the point. You explain the fixes. You wait, read again, catch a new problem, re-ask. By round five you've done the judging, the quality control, and the project management — the AI just did the typing.
Look at the diagram: four of the five jobs in the cycle are yours. When you prompt one task at a time, the human is still the loop. That sentence is the entire insight behind everything the builders changed. The cycle itself — draft, review, fix, repeat — is not the problem. It's the correct way to produce good work. The problem is who's running it: a cycle is exactly the kind of thing machines exist to run, and this one is running on you.
The reason it keeps running on you is simple: nobody wrote the rules down. You know what "good" looks like for your task — the checks live in your head, applied one round at a time. Write them down, and the cycle becomes transferable.
A loop is a prompt that makes the AI run that cycle itself, in passes. Each pass, it does the work, then grades its own output against criteria you wrote — not a vague sense of "better," but hard checks it must answer yes or no, quoting the evidence. Anything that fails gets repaired on the next pass; anything that passes gets left alone. And it stops honestly, through one of exactly two exits: every check passes, or a pass limit is reached and it reports truthfully what's done and what isn't.
Notice what you're actually delegating. Not the steps — you're not scripting "first write the intro, then…". You delegate the outcome: here is the mission, here is how you'll know it's met, here is when to stop. The AI figures out the rest. That's the difference between a to-do list and a finish line.
One property carries all the weight: verification. A loop that can check its own work self-corrects — that's what frees you to walk away. A loop that can't check its own work still produces drafts that look finished, but you have to read every one to know. Which quietly puts you right back in the diagram from section 02.
Abstractions hide the magic, so here's a small loop actually running. The mission: a product description for a lavender candle — under 120 words, mentions the 45-hour burn time and the $24 price, ends with exactly one call to action. Four checks, all countable.
── PASS 1 · draft, then self-grade ────────────── ✓ mentions $24 "…for $24, it earns its shelf…" ✓ one call to action "Order yours before…" (only 1 found) ✗ under 120 words word count: 164 ✗ mentions burn time no match for "45" or "burn"
── PASS 2 · fix ONLY the two failures ─────────── ✓ under 120 words word count: 112 ✓ mentions burn time "…45 hours of slow burn…" ✓ mentions $24 unchanged — not touched ✓ one call to action unchanged — not touched ALL CHECKS PASS → STOP LOOP LOG: 2 passes · trimmed 52 words · lesson — draft long, then cut; burn time belongs in sentence 2
Three things to notice. The checks did the judging — not a human, and not a vibe. The second pass touched only the two failures, so the parts that already worked couldn't get worse. And the log recorded what the loop learned, so your next candle description starts smarter. That's the whole mechanism, at every scale from a product blurb to a codebase: the tasks change, the shape doesn't.
| Result | What was measured |
|---|---|
| 75.8 → 38.1% | Accuracy after naive self-review. Models asked to "reflect and improve" second-guessed correct answers into wrong ones — reflection without criteria made the work dramatically worse.HUANG ET AL. · ICLR 2024 |
| 96% | How often an unguided checker rejected work that was already correct. A verifier with no rubric doesn't verify — it invents objections.STECHLY ET AL. |
| 83% | Share of total measured gains that landed in the first structured pass. Improvement front-loads; pass ten is polishing noise.MADAAN ET AL. · SELF-REFINE |
If loops are so effective, why doesn't everyone just tell the AI "review your answer and make it better"? Because researchers tried exactly that, and measured what happens. Without falsifiable criteria, self-review turns into self-doubt: the Huang study watched accuracy fall from 75.8% to 38.1% as models talked themselves out of correct answers. Stechly's unguided checkers rejected work that was already right 96% of the time. And Madaan's Self-Refine results showed that when improvement does happen, 83% of it arrives in the first structured pass — iteration has sharply diminishing returns even when it works.
Read those three numbers together and the lesson is precise: iteration without rules destroys work; iteration with rules front-loads value. The four rules in the next section aren't style preferences. Each one exists to neutralize a specific failure documented above.
| yes/no checks | "Under 150 words" is countable; "make it better" is not falsifiable. Binary checks are what keep the loop from becoming the 38.1% story — there's nothing to second-guess when the criterion either holds or doesn't. |
| quote the proof | Every ✓ must cite its evidence — the sentence, the count, the match. This is what separates a verifier from an objection generator: a checker that must show its work can't reject correct output on a hunch. |
| fix only failures | Passing parts are load-bearing. A full rewrite on every pass risks breaking what worked; targeted repair means quality can only move one direction. |
| cap the passes | Four passes, then an honest report. The cap converts "polish forever" into "finish or say exactly what's still failing" — and since 83% of gains land early, you lose almost nothing by stopping. |
Strictness feels like bureaucracy until you've watched an unruled loop run. These four constraints are the entire difference between the failure data and the success data — discipline, not decoration.
YOUR MISSION the deliverable + a measurable "done" (include a number) EACH PASS draft — or fix only what failed — then re-grade CHECK YOURSELF 3–5 yes/no checks · quote the proof for each ✓ LOOP LOG passes · failures · lessons STOP WHEN all checks pass OR 4 passes → honest report RULES guardrails · stuck twice → ask me
Everything above compresses into six labeled lines that any chat AI can follow — ChatGPT, Claude, Gemini, a coding agent. There's no software to install and no code to write. Here's how to fill each label well:
| YOUR MISSION | Name the deliverable and a measurable finish line. Weak: "a good product description." Strong: "a product description under 120 words that names the price and burn time." The number is what makes "done" checkable. |
| EACH PASS | Two modes only: draft (first pass) or repair-what-failed (every later pass). Then re-grade everything. Naming both modes is what stops full rewrites. |
| CHECK YOURSELF | Three to five binary checks, each with quoted proof. Fewer than three and the loop can't see; more than five and it drowns. If a check can't be answered yes/no, rewrite it until it can. |
| LOOP LOG | One line per pass: what failed, what was fixed, what was learned. The log is what makes run five smarter than run one — it's also how you audit the loop later. |
| STOP WHEN | Exactly two exits: all checks pass, or the cap is hit and it reports honestly. Never let "keep going until it's great" be an exit — that's the unruled loop again. |
| RULES | Your guardrails: sources it may use, things it must never change, and the escape hatch — stuck on the same failure twice, stop and ask you. |
Write it once and it becomes a reusable asset: the same six labels, re-filled for the next task in minutes.
Write one loop by hand first. A single honest LOOP LOG will teach you more than any explainer. When you'd rather have the spec and the checks written for you, that's the tool we build.
Try Prompt Optimizer