Loop Engineering: Stop Prompting, Start Designing the Loop

In June 2026, three people independently reached for the same idea in the same week. Peter Steinberger put it bluntly: you should not be prompting coding agents anymore, you should be designing the loops that prompt them. Boris Cherny, who leads Claude Code at Anthropic, said much the same — that he no longer prompts Claude, he writes loops that prompt Claude. And Addy Osmani named it in writing: loop engineering is replacing yourself as the person who prompts the agent, and designing the system that does it instead.

The shift is one of position. For two years the way you got work out of a coding agent was to sit at the keyboard and prompt it line by line — you were the clock inside the loop, and every tick came from you. Loop engineering deletes that assumption. You step outside the loop and build the thing that ticks on its own: it runs on a timer, spawns helpers to do the work, checks whether the result is right, and feeds its own output back as tomorrow's input.

A loop is not idle spinning. Each turn does five concrete things: it discovers work worth doing, hands it off to an agent, verifies whether the result is actually right, persists what happened so nothing is forgotten, and reschedules itself for the next turn. Drop any one of those and the loop either stops turning or turns in place — quietly making the same mistakes at machine speed.

The hardest of those five moves is verification, and it is the one most often skipped. An agent asked to grade its own work tends to praise it — not because it is dishonest, but because it is grading its own homework, looking at the very chain of reasoning that produced the code. The reliable fix is structural: a separate evaluator, with different instructions and ideally a different model, that defaults to doubt and judges behavior by running the code rather than reading it. This is the decades-old maker-checker principle from banking — the person entering a transfer cannot be the person who approves it — applied to whether the loop is done.

Here is what struck us: ClusterCode is already most of a loop-engineering platform. It schedules work on a cron. It runs each task in an isolated, disposable container — the handoff, done right. It delegates to Claude, Codex, or Copilot as sub-agents. It connects to your tools over MCP. It keeps a durable record of every run. The one missing piece is the part that makes a loop a loop rather than a job you ran once: a goal that keeps iterating until a verifiable condition holds, graded by a separate model, with the guardrails to fail safely.

That is what we are building next, and we are building it as a glass box. When a loop decides it is done, you will see the gates it passed and the evaluator's reasoning. When it cannot make progress, it stops itself — not when the bill runs out, but the moment it detects it is spinning. When it hits a judgment call it should not make alone, it pauses and hands you a decision, rather than pressing on. Every loop runs on machines you own, and you can take over any run mid-flight.

It helps to see where this loop sits, because it is not the only one. The fastest loop is the agent writing code, running it, and iterating until it meets the spec — that one turns every few minutes. Around it runs a slower loop: you, reviewing what was built and steering it, updating the goal and the gates over minutes and hours. Around that, slower still, is the world — the people who use what you shipped, feeding back over days. ClusterCode builds the innermost loop and hands off cleanly to the one around it. When a loop reaches a decision only you should make, it pauses and gives you the controls — not because it failed, but because you hold a context advantage it does not: you know things about your users and your codebase that no agent has seen, and the pause is where that knowledge enters the system.

Because the honest truth about loops is that they make mistakes unattended just as cheerfully as they do work. A loop that ships twenty pull requests overnight is wonderful until three of them carry a subtle error the tests did not cover — and because the loop ran so smoothly, you stopped reading the batch, and your understanding of your own codebase quietly fell behind. Loop engineering does not remove judgment from software; it strips away everything that was not judgment and leaves judgment as the whole job.

So the design principle we keep coming back to, borrowed from Osmani's closing line, is this: build the loop, but build it like someone who intends to stay the engineer — not just the person who presses go. A loop is a faithful multiplier of whatever its builder brings. Bring understanding and it amplifies understanding; bring the wish to never understand again and it amplifies that too. The same loop, built by two people, ends in opposite places.

If you want to go deeper on the concept, read Addy Osmani's original essay Loop Engineering (June 2026), HuaShu's open, MIT-licensed field guide Loop Engineering: Stop Asking Me What It Is, and Andrew Ng's letter in The Batch on the three nested loops of 0-to-1 product building — all of which shaped our thinking and our design. We will share more as the feature takes shape.