Loop engineering: build loops, not prompts

Peter Steinberger puts it roughly like this: stop prompting coding agents, design loops that prompt them. Boris Cherny, Head of Claude Code at Anthropic, goes further:

I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

This is loop engineering, and it describes a shift I take seriously while staying skeptical. A loop is, at its core, a recursive goal: you define the purpose, the AI iterates until it is met. One thing up front, token costs can swing wildly. You have to watch them.

What changes

For two years it went like this: you write a good prompt, give enough context, read the answer, write the next prompt. You hold the tool the whole time, turn after turn. Loop engineering flips that. You build a small system that finds the work, hands it out, checks the result, records what is done, and decides the next thing. Then that system pokes the agents, not you.

The surprising part: it is barely a tool question anymore. A year ago a loop was a pile of bash scripts only you maintained. Today the pieces ship inside the products, almost identically in the Codex app and in Claude Code. Once you see the shape is the same, you stop arguing about the tool and design the loop so it works in either.

The pieces

A loop needs roughly six things:

• Automations that run on a schedule and find and triage work on their own. That is the heartbeat. Without them it is a single run, not a loop.
• Worktrees, so two agents can work in parallel without writing into the same files.
• Skills that hold the project knowledge the agent would otherwise guess every time.
• Connectors over MCP, so the loop reaches your real tools: issue tracker, database, Slack.
• Sub-agents, split into one that builds and one that checks. The model that wrote the code grades its own work far too kindly.
• A memory outside the conversation: a markdown file, a Linear board. It sounds too simple, but it is the core. The model forgets everything between runs, so the state has to live on disk, not in the context. The agent forgets, the repo does not.

Plus two commands that hit the point: /loop re-runs on a cadence, /goal keeps going until a verifiable condition actually holds, and after each turn a separate model checks whether done is really done. The one who writes is not the one who grades.

What the loop does not do for you

This is where it gets interesting, because three problems get sharper, not easier, the better the loop runs.

Verification stays with you. A loop running unattended is also a loop making mistakes unattended. That is exactly why you split the checker from the maker. And even then, done is a claim, not a proof.

Your understanding erodes if you let it. The faster the loop ships code you did not write, the wider the gap between what exists and what you actually grasp. A smooth loop widens it faster, unless you read what it built.

And the comfortable posture is the dangerous one. When the loop turns itself, it is tempting to stop having an opinion and just take what comes back. Designing the loop is the cure when you do it with judgment, and the accelerant when you do it to avoid thinking. Same action, opposite result.

Build the loop, stay the engineer

I think this is a preview of how our work shifts. But: if I did not review the code myself and leaned entirely on automated loops, my products would get worse, and I would dig myself in deeper, step by step.

So go ahead and build your loops, but do not forget that prompting directly still works. It is about balance.

Two people build the same loop and get opposite results. One gets faster at work they understand deeply. The other avoids understanding the work at all. The loop does not know the difference. You do.

That is what makes loop design harder than prompt engineering, not easier. Cherny’s point is not that the work got easier. The leverage point moved. Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.