Stop Prompting. Start Looping.

On June 7, Peter Steinberger posted six words: you should not be prompting coding agents anymore, you should be designing loops that prompt them for you. Three million people read it inside a week. Two days earlier, Boris Cherny, the person who runs Claude Code at Anthropic, said the same thing on stage in front of Addy Osmani. I do not prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops.

I have spent the week building one, breaking one, and watching the second draft chew through a triple-digit token bill on a problem that I could have solved by hand in twenty minutes. The argument is correct. The execution is harder than the people repeating the quote on LinkedIn want you to know.

Here is what I have learned.

What a loop actually is

For most of the last two years, working with a coding agent has felt like high-effort ping pong. You write a prompt. You wait. You skim what came back. You adjust. You send the next one. In that mode, your attention is the engine. The model is the muscle. You are the loop.

Loop engineering inverts that. You write a small program that does the prompting. The program picks the next task, dispatches it to the model, grades the result, logs the outcome, decides whether to fire again, and stops when a condition you defined ahead of time is met. The model becomes a function the program calls inside a while. The chat box is gone.

flowchart LR
    A[Trigger] --> B[Gather context]
    B --> C[Take action<br/>Model call]
    C --> D[Verify output]
    D -->|Pass| E[Log + stop]
    D -->|Fail and budget left| B
    D -->|Budget hit| F[Halt + alert]

    classDef step fill:#FFFFFF,stroke:#001D22,color:#001D22
    classDef verify fill:#DDE6E7,stroke:#001D22,color:#001D22
    classDef halt fill:#001D22,stroke:#001D22,color:#F5F7F7
    class A,B,C,E step
    class D verify
    class F halt

That is the whole shape. Everything else is scaffolding around those five boxes.

The stack: prompt, harness, loop

A clean way to think about where you are in your own AI journey:

flowchart TB
    P[Prompt Engineering<br/>One turn] --> H[Harness Engineering<br/>One agent, structured environment]
    H --> L[Loop Engineering<br/>Many runs on a schedule, verified, halted]
    style P fill:#F5F7F7,stroke:#2A4144,color:#001D22
    style H fill:#DDE6E7,stroke:#001D22,color:#001D22
    style L fill:#001D22,stroke:#001D22,color:#F5F7F7

Most teams I talk to are still on floor one and pretending they are on floor three because their CEO read a tweet. You cannot loop on top of a harness you do not have. If your agent does not yet have a working system prompt, project skills, and a clean tool surface, build that first. Skip the floors and you will spend the next six months debugging a loop that is amplifying problems instead of solving them.

When a task is actually loop-shaped

Before I build a loop for anything, I run it through three questions. If the answer to any of them is no, I do not build the loop. I write a prompt or a regular script.

1. Is it repetitive enough that the design cost pays back? If you are going to run this twice a year, write the script.
2. Can a passing result be expressed as a check a second agent or a script could actually run? If you cannot define passing, the loop will not know when to stop, which means it will not stop.
3. Is the output worth the tokens? Loops have a floor cost in time and money. If the task is a one-off worth twenty dollars of your time, do not spend forty dollars of model time on it.

The Reddit user whose post got most quoted in this debate had it right. He loops the parts that are mechanical. He does not loop the parts where his taste is the product. Candidate gathering, dedupe, link verification, fact checking, image validation: loop. Topic selection, narrative shape, what to actually say: human.

The anatomy of a loop that does not embarrass you

Cherny's framing is the cleanest one out there. Five components. I add a sixth, because every production loop I have built has needed it. Seven if you include the trigger.

flowchart LR
    T[1. Trigger<br/>Schedule, webhook, file change] --> A[2. Automations<br/>Hands-free dispatch]
    A --> W[3. Worktrees<br/>Isolated branches per agent]
    W --> S[4. Skills<br/>SKILL.md + scripts]
    S --> C[5. Connectors<br/>MCP to issue tracker, web, data]
    C --> SA[6. Sub-agents<br/>Writer + reviewer split]
    SA --> M[7. Memory<br/>State file that survives crashes]
    M --> T

    classDef step fill:#FFFFFF,stroke:#001D22,color:#001D22
    class T,A,W,S,C,SA,M step

Walking each one in plain English:

The trigger. Something has to start a run that is not you typing. In Codex that is the Automations tab. In Claude Code that is the /loop command, a hook, or a GitHub Action. Whatever you pick, it ships with a stop condition or it is not a trigger, it is an open door.

Automations. The piece of plumbing that dispatches the work without a human pressing go. Both Codex and Claude Code have this. If you are still hitting return in a terminal, you do not have a loop, you have a faster prompt.

Worktrees. If two agents touch the same checkout at the same time, you get silent overwrites or a thrashing merge that costs you a day. Git worktrees give each agent its own branch and its own working copy backed by the same repo. Both major harnesses now spin worktrees up for you. Running parallel agents without them is building a race condition on purpose.

Skills. A folder containing a SKILL.md plus the scripts and fixtures the agent needs to do a specific job. The agent loads the skill when the description in the frontmatter matches the task. The mistake almost everyone makes here is writing the description like a tag line. The description is a manifesto. It is the thing that decides whether the loop ever calls the skill at all. We have spent more time tuning skill descriptions at Magnet than we have spent writing the skills themselves.

Connectors. The loop has to reach out to the rest of your stack: the issue tracker, the staging API, the data warehouse, Slack, the live web. Connectors run on MCP. Both Codex and Claude Code speak it. A loop without connectors is a glorified script. A loop with the right four or five connectors is what separates an agent that hands you a patch to apply from a loop that opens the PR, links the Linear ticket, posts in your engineering channel, and waits for CI on its own.

Sub-agents. The single pattern that pays for itself fastest is splitting the writer from the reviewer. One agent makes the change. A second agent, often on a cheaper model, grades it against the rubric and the tests. The grader does not need to be smarter than the writer. It needs to be different, with its own instructions and its own scoring rules. Asking the same agent to both write and review is how loops convince themselves they are succeeding while shipping garbage.

Memory. The loop has to remember what it did yesterday. Markdown checklist in the repo, JSON file beside it, Linear board, SQLite database. Pick one. Every run reads it at the start and appends to it at the end. This is how a loop survives a crash, a context-window reset, or a 3 a.m. process kill without restarting from zero.

Open loops, closed loops

There are two shapes. Pick the right one for the problem.

flowchart LR
    subgraph Open
        OG[Goal + guardrails] --> OA[Agent picks its own path]
        OA --> OO[Surprising output<br/>Sometimes great, sometimes noise]
    end
    subgraph Closed
        CG[Mapped steps + rubric] --> CA[Agent iterates inside scaffolding]
        CA --> CO[Predictable output<br/>Compounds over runs]
    end

    classDef step fill:#FFFFFF,stroke:#001D22,color:#001D22
    classDef outcome fill:#DDE6E7,stroke:#001D22,color:#001D22
    class OG,OA,CG,CA step
    class OO,CO outcome

Open loops trade structure for surface area. You hand the agent a target and some guardrails and it picks its own route. Useful for prototyping and unknown terrain. Dangerous in production. If your project standards are vague, the output is mostly noise wearing a confident hat.

Closed loops are the opposite. You map the route first: what each step does, how it is checked, when the loop is allowed to stop. The agent iterates inside that scaffolding. Runtime cost is predictable. Quality improves over time because every run is graded against the same rubric.

In production, closed wins by default. Use open loops for research. Use closed loops for anything that ships.

The three guards every loop needs before it touches your card

This is the part that nobody on LinkedIn is saying loud enough.

Uber, the company, capped its engineers at fifteen hundred dollars per person per tool per month on Claude Code and Cursor after burning its annual AI budget in four months. Fifteen hundred dollars. Per engineer. Per tool. Per month. That is what an unmetered loop costs when smart people build them without the right guards.

Three non-negotiable rules:

1. A hard ceiling on iterations. The loop is allowed N passes and then it stops, regardless of whether it is done. N is a number you write down before you press go, not a number you discover when the bill arrives.
2. A diff check. If the last three passes have not changed anything meaningful, kill the run. The loop has either succeeded or gotten stuck. Either way, it is finished.
3. A spend cap. In tokens, in dollars, or both. The loop checks itself against the cap on every iteration and ends the run before billing does.

Without all three, you do not have a loop. You have an open invoice.

flowchart TB
    R[Run starts<br/>Budget = $20, Max iters = 25] --> I{Iteration}
    I --> CK1{Iter count<br/>>= max?}
    CK1 -->|Yes| K[Halt: max iterations]
    CK1 -->|No| CK2{Spend<br/>>= cap?}
    CK2 -->|Yes| K2[Halt: budget cap]
    CK2 -->|No| CK3{Last 3 diffs<br/>== 0?}
    CK3 -->|Yes| K3[Halt: converged]
    CK3 -->|No| I

    classDef start fill:#001D22,stroke:#001D22,color:#F5F7F7
    classDef check fill:#FFFFFF,stroke:#001D22,color:#001D22
    classDef halt fill:#F9432B,stroke:#F9432B,color:#FFFFFF
    classDef done fill:#DDE6E7,stroke:#001D22,color:#001D22
    class R start
    class I,CK1,CK2,CK3 check
    class K,K2 halt
    class K3 done

I run this exact pattern on every loop we build at Magnet now. The first version we shipped did not have it. The first version cost me sixty-three dollars in tokens before I noticed. The second version cost me four.

The two risks the guards do not solve

Even with the guards, two things will hurt you.

Comprehension debt. Addy Osmani coined the phrase. The faster a loop ships code you did not write, the wider the gap between what exists in your repo and what you actually understand. The better the loop runs, the faster the debt accrues. Done is a claim, not a proof. Read the diffs. Read them on the phone in line at the coffee shop if you have to.

Taste. Greg Brockman put it cleanly. As models get more capable, the bottleneck stops being the model and starts being the taste of the person directing it. Loops amplify whatever you put into the rubric, the skills, and the verification step. If those three things reflect real judgment about what good means in your codebase and which edge cases actually matter, the loop compounds in the right direction. If they do not, you have built a faster way to ship work that was not worth doing. More PRs nobody asked for. More tickets autoclosed against the wrong root cause. The loop lets you be wrong at machine speed.

This is why the harness layer is the easy part to copy and the rubric inside it is the part that is actually yours.

Where to start tomorrow morning

If you have read this far and you want to actually do this, here is the smallest first move that will teach you almost everything you need to know.

1. Pick one repetitive task you run at least weekly. Pull request triage. Docs sync after API changes. Lead enrichment. Pick the boring one.
2. Write the rubric before you write any code. What does a passing run look like? Be specific enough that a second agent could grade it.
3. Build the closed loop. Trigger, gather context, take action, verify, log, stop.
4. Add the three guards before you give it credentials. Max iterations, diff convergence, spend cap.
5. Run it ten times by hand. Watch every iteration. Tune the rubric. Do not automate the schedule until you trust the output.
6. Then automate the schedule. And read the diffs every morning for two weeks.

That is it. That is the playbook. Anyone telling you it is faster than that is selling you something.

The frontier here is not built by waiting for Anthropic or OpenAI to wrap a nicer UI around it. It is built one boring workflow at a time by operators who decided that their corrections and their rubrics were the part of their business worth keeping.

Get a Loop Audit

If you are reading this and you can already feel which workflow in your business is loop-shaped, that is the workflow that is leaking the most money right now. We help marketing and operations teams pick the right one, build the loop, and put the three guards on it before it touches your card.

We are offering a free 45-minute Loop Audit through the end of July. We will look at your existing AI workflows, identify the one that is most worth turning into a loop first, sketch the trigger, the verification step, and the stop condition, and tell you honestly whether you should build it, hire it out, or wait six months.

Book a Loop Audit at https://magnet.co/contact. No pitch. No deck. Just one call, your real workflows, and a written plan you can hand to your engineer the next morning.