I SPENT 700+ HOURS BUILDING AI LOOPS. HERE ARE THE 7 PRINCIPLES I WISH SOMEONE HANDED ME ON DAY ONE.

Peter Steinberger says it monthly: you should not be prompting coding agents anymore, you should be designing loops that prompt your agents. Boris Cherny, who runs Claude Code at Anthropic, says it plainer: "I do not prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops."

Most people read those lines, nod, and have no idea what they mean in practice. What goes in the files? What breaks on the second iteration? Why does one person's loop ship three pull requests overnight while another person's burns $40 producing nothing?

These are the 7 principles behind the loops that actually survive in production. Principle 7 is the one that decides whether a loop makes you money or quietly drains you, and it only lands after the first six. Read in order.

1. A prompt makes you the engine

Look at how most people use AI: type a request, wait, read the answer, spot the mistake, type again. It feels like the AI is working. It is not. You decide every next step, you check every result, you carry every failure from one message to the next. You are the engine. The AI is the tool in your hand, and a tool does nothing on its own.

A loop flips the roles. You define the goal once, and the system runs the cycle itself: figure out what needs doing, plan the step, do the work, check the result, feed failures back in, repeat. You step away and the work keeps going.

A prompt gives the model an instruction. A loop gives it a job: a goal, a way to know the job is done, and a rule for when to give up. Everything below is about building those three things correctly.

2. No gate, no loop

Verification is the heart of a loop, and it is the part everyone skips. Without a real check that can reject bad work, you do not have a loop. You have an agent agreeing with itself on repeat, and a model grading its own homework is a very generous grader.

A gate is anything that can fail the work without you in the room: a test suite, a type checker, a build, a linter, a strict rubric, a measurable condition. The rule that separates working loops from expensive theater:

DONE WHEN: tests return 0 AND lint returns 0.
Not "when it looks fine". Not "when most of them pass".
Done is an exit code, not a feeling.

If nothing in your setup can automatically say "no, this failed", stop building the loop and go write a better prompt instead.

3. Most tasks do not deserve a loop

Loops sound powerful, so people try to loop everything. That is how you build machines that run all night for nothing. A loop earns its setup cost only when the task passes all four of these:

Does it repeat at least weekly? A one-off is faster with one good prompt.

Can bad output be rejected automatically? See principle 2. If a human still has to inspect every result from scratch, the loop saves nothing.

Can the agent act end to end? If it needs your permission or missing context every two minutes, it is manual work with extra steps.

Is "done" objective? "Tests pass" is objective. "The article feels good" is not. No agent will ever hand you exit code 0 on beauty.

"Triage failing CI runs" passes all four. "Update dependencies and verify nothing broke" passes. "Make the design feel more premium" fails the last one and always will. Tasks like that stay manual, and that is fine. Miss one box, write a prompt. Pass all four, build the loop.

4. The maker never checks its own work

The single highest-value structural trick in loop design: the agent that creates the work must not be the agent that verifies it.

Not because models are useless. Because self-review is weak, in machines and in humans. The model that just wrote a fix has already spent its reasoning defending it. Ask it to review itself and it finds a way to pass. This is why newsrooms have editors who did not write the piece and banks split payment creation from payment approval.

The working pattern: a maker produces, a checker verifies, and the checker sees only the requirements and the result, never the implementation and never the maker's reasoning. Bonus economics: the maker can be a cheap fast model, the checker a strong strict one. You pay premium rates for judgment, not for typing.

VERIFIER RULES:
you receive the spec and the test output. nothing else.
you do not read the implementation.
tests green and spec met -> approve.
anything less -> reject with the list of failures.
you have no other opinion.

5. Memory lives in a file, not in the model

Every agent run starts as a blank slate. It does not remember that it tried this exact fix yesterday and the fix did not work. Leave that unhandled and your loop repeats the same mistake every single night, on your budget.

The cure costs nothing: a plain text file the loop reads at the start of every run and rewrites at the end. What was tried. What passed. What failed. What still needs a human. And the most underrated section, lessons learned: the local landmines that exist in neither the code nor the docs.

# STATE.md
## last run
- 3 fixes shipped, 2 escalated

## do not retry
- restarting the worker blind: failed twice, root cause elsewhere

## lessons
- e2e checkout test needs the webhook secret in env. skip if absent.
- the windows runner chokes on powershell. use bash.

The model forgets. The file does not. A loop without external state is not a loop, it is a series of first days at work.

6. Every loop needs a fuse

Bad loops do not crash. That is what makes them dangerous. A normal script fails loudly; a bad loop keeps running confidently, declaring half-finished work done, retrying the same dead end, billing you in silence.

So every serious loop carries two stop conditions. A success stop: the gate passed, ship and exit. And a failure stop, the fuse: maximum 8 iterations, maximum dollar budget per run, stop if the same error repeats twice, stop and escalate if the checker rejects the same fix two rounds in a row. Tools already support this: Claude Code has a literal budget flag. Set it on day one, not after the first surprise bill.

Same logic says: start with closed loops, not open ones. "Every Monday, check for safe dependency updates, apply one at a time, run tests, open a PR if green, log and stop if red" is closed: bounded path, defined checks, explicit exit. "Find ways to improve the product and implement the best ideas" is open: exciting, exploratory, and a token furnace. Closed loops are boring, and boring is what you can trust overnight. Earn autonomy gradually: reliability first, freedom later.

7. The only metric is cost per accepted result

Not tokens spent. Not loops run. Not "look, it did something while I slept". The number that decides everything: how much did each result you actually kept cost you?

Loop costs compound in a way single prompts never do. Every iteration re-reads the goal, the state, the previous failures, the tool output. The pile grows each pass. A loop that runs ten times is not ten prompts, it is ten prompts that each got bigger. Add a checker agent and you have doubled the readers.

That spend is fine when the loop ships. It is poison when it does not. If the loop produces ten outputs and you reject seven, it did not save you work, it manufactured review debt. If it opens five PRs and you merge one, manual was cheaper. And there is a quieter cost: when a loop ships faster than you read, your understanding of your own system falls behind. The code works and nobody knows why. That bill arrives later, with interest.

Which is why the build order is fixed, and skipping steps is how loops blow up at 3am:

1. run the task manually until one run is reliable
2. save the instructions as a reusable skill
3. add the gate (principle 2) and the checker (principle 4)
4. add state (principle 5) and the fuse (principle 6)
5. only THEN put it on a schedule

Try the shape tonight, without any tools

You can feel the whole pattern inside any chat model with one paste. No scheduler, no agents, no bill:

You will work in a loop until the task meets the bar.

TASK: [exactly what you want]

SUCCESS CRITERIA:
- [criterion 1]
- [criterion 2]
- [criterion 3]

EVERY TURN:
1. PLAN   - name the single next step
2. DO     - produce or improve the work
3. VERIFY - score 1-10 on each criterion, brutally
4. DECIDE - all 8+? print FINAL and stop.
   otherwise print ITERATING and fix the weakest score first.

RULES: never call it done early. max 3 iterations.
assume instead of asking. begin.

Watch it draft, grade itself, find the weak spot, rewrite, and only then stop. That is the entire idea in miniature. What is missing is exactly what the 7 principles add: a trigger that is not you, a gate that is not the model's opinion, memory that survives the session, and a fuse.

The point

Prompt engineering improves one answer. Loop engineering improves the process that produces answers, and the process is where the compounding lives. The people winning with agents right now are not writing more clever prompts into chat boxes. They are deciding what starts the work, what verifies it, what it must never touch, and when it must stop and call a human.

The loop is the product. The prompt is one part of it.

Bookmark this before you build anything. Then reply with the one task you repeat every week and quietly resent, and I will sketch its loop for you in one message.