Stop Prompting. Write Loops

“You shouldn’t be prompting coding agents anymore. You should be designing the loops that prompt them for you.” — Peter Steinberger

Back in November, Boris Cherny — the creator of Claude Code — deleted his IDE. Stopped using it. In a recent interview he says it plainly: “I don’t prompt Claude anymore. I have loops running that prompt it and decide for themselves what to do. My job is to write the loops.” And he adds: this is a transition the market will spend the rest of the year living through.

The shift is simple to say and enormous in its consequences. Before, you’re in a chat: prompt → answer → edit → prompt again. The human is the bottleneck on every iteration. Now you design a system once, and it finds the work itself, hands it out to agents, checks the result, writes down what got done, and decides what comes next. It pokes the agents instead of you.

The ladder of abstraction

Daniel Demmel laid this out as a ladder, with prompting on the bottom rung:

1. Prompt engineering — how to phrase the request.
2. Context engineering — what to put in the context.
3. Feedback-loop engineering — letting the agent see the consequences of its own work: tests, logs, real APIs.
4. Harness engineering — running the whole apparatus: what launches, what verifies, when to call a human.

The trend is a move up the ladder. You stop machining the part and start designing the assembly line. Why it all lined up right now: models got reliable enough to trust with a step you don’t check on every iteration; parallelism got cheap; and the infrastructure drove straight into the tools.

Anatomy of a loop

A loop closes without a human for one reason: the code has a cheap, objective oracle — compilation, tests, lint, execution. The agent sees for itself where it lied. That’s how you build a closed-loop: agents compile, run, screenshot, hit real keys — they verify themselves.

The loop itself boils down to a formula: find work → bounded action → verification → report → escalation. You formalize this as a one-page contract for each loop:

trigger:  when it fires
scope:    what it touches / what it doesn't
budget:   max attempts / time / files
stop:     conditions for escalating to a human
report:   where to write the outcome

Six orchestration primitives

Anthropic described six patterns that an agent assembles into a harness for a specific task — like snapping together building blocks:

• Classify-and-act — routing by type. Whatever comes in (an issue, an email, a ticket, an error) gets classified, and each type goes to its own handler. This is the “dispatcher” at the front of the loop: don’t treat everything the same, first figure out what actually arrived.
• Fan-out-and-synthesize — the task is split into independent pieces, each solved in parallel in a clean context, then the results are pulled back into one. This is how an agent analyzes a large codebase with a dozen sub-agents at once, while a synthesizer assembles the whole picture. Parallelism where the pieces don’t depend on each other.
• Adversarial-verify — a separate skeptic agent checks the result against a rubric, and its job is to disprove, not to confirm. This removes self-preferential bias: the author shouldn’t be the one grading their own work. The core trust pattern is that whoever checks isn’t whoever did.
• Generate-and-filter — produce many candidates, filter by quality, throw out the duplicates. Useful when it’s cheaper to produce ten options and pick than to try to guess the one right answer on the first try.
• Tournament — several agents solve the same task with different approaches, and judges compare them pairwise until one winner is left. This is for cases where the solution space is wide and it isn’t clear in advance which path is best.
• Loop-until-done — spawn agents until a stop condition holds: nothing new is found, zero errors, the goal is reached. This is how you do an exhaustive sweep — for example, hunting bugs until two passes in a row come back empty.

Notice the key thing: almost every primitive rests on the verification step — adversarial-verify checks, filter selects, until-done watches for “zero errors.” Which means they all bottom out in the oracle again. Without a way to say objectively “this is correct,” the primitives turn into a pretty imitation of work.

Order matters: tests before code

And here’s the nuance that decides accuracy. If the agent writes the code and then the tests, it’s checking itself: the tests inherit the same misunderstanding as the code, they converge, and a green build means nothing. If tests come before code, the oracle becomes independent of the implementation: the test encodes the intent before there’s a solution. Then “tests passed” is a real signal. Test-first turns the test from a check into a spec-as-oracle, and the loop’s accuracy climbs sharply.

The trap: the agent can write weak tests or bend them to the code just to get green. So the test has to be derived from the contract and the acceptance criteria, not invented by the agent, and it has to be protected from rewrites. With that discipline the loop converges on the correct thing, not the convenient one.

And where there’s no oracle at all — design, a product decision, a specification — the loop doesn’t converge on its own, and a human has to stand at the gate.

The sober risk

Addy Osmani puts it honestly: the loop makes mistakes unsupervised — and they stay unnoticed. Comprehension debt grows: the code moves faster than your understanding of it. And there’s “cognitive surrender” — when you stop forming an opinion and accept whatever the machine produced. His formula: “Build the loop. But build it as someone who intends to stay an engineer, not just hit ‘run.’”

What it looks like in practice: from contract to dev loop

If code agents work in loops, the bottleneck moves: it’s not in writing the code, but in the quality of the contract the loop checks itself against. The loop is exactly as good as your definition of “done” is precise.

Step 0. The requester hands over a contract, not a task. It has three things that make it loop-ready:

• claims about the code are grounded — a method/field actually exists, verified, not “should be there”;
• acceptance criteria are observable — you can run them, not eyeball them;
• the why is written down — so the decision transfers instead of being re-invented every time.

Step 1. The dev loop starts from acceptance, not from code. The agent reads the criteria → writes tests that encode them (test-first, from the contract) → implements → runs tests and lint → fixes red itself within budget → repeats until green.

Step 2. Escalation only on real forks. The loop calls a human when “the contract says X but the code does Y” or “the criterion is ambiguous.” It doesn’t call over a missing bracket.

Step 3. The output is a PR and a test run. Review happens over the PR and the contract, not step-by-step behind the agent.

What changes for the developer, concretely:

• routine verifiable pieces stop being hand-written — the loop drives them;
• the role shifts from implementer to loop owner and PR reviewer;
• the engineer’s judgment moves to where there is no oracle — an architectural fork, a non-obvious tradeoff — instead of “implement the obvious thing.”

The honest boundary. This works where acceptance is objective and the contract is grounded. Where there’s no oracle — design, the product choice of “are we building the right thing” — a human is at the gate, the loop doesn’t converge on its own. And test-first is mandatory: without it, the agent grades itself.

So why keep a senior engineer?

Let’s follow the logic all the way, without flinching. If the requester hands over a verifiable contract, and the loop implements and verifies it — why keep a senior engineer?

There’s an error hidden in the question. It assumes that the architecture that satisfies the contract is itself unambiguous. For the simple case — yes. For the complex one — no. The contract specifies the WHAT and the acceptance. It doesn’t specify the HOW: the data model, the transaction boundaries, where the lock goes, the routing, the behavior on a network partition, the migration strategy. In that gap between the “what” and a sound “how” there’s no test-first oracle, because the solution space is open and the tradeoffs run deep.

So the contract doesn’t transfer in a single act — it’s an enrichment chain:

Three things make this work.

The technical contract is also verifiable, and its criteria are the oracle. The senior doesn’t enrich with prose: the technical acceptance criteria are observable and become the very tests-before-code. The senior finishes writing the oracle — after which the loop can run.

Validation runs upward. If the contract is ambiguous or unbuildable, the senior sends it back to the requester rather than quietly patching it. The contract isn’t “handed down,” it’s negotiated between two gates.

The amount of enrichment scales with architectural novelty. A trivial feature — nothing to enrich, the loop runs almost straight from the contract, the senior barely touches it. A complex one — the enrichment is the senior’s core value. Involvement scales with complexity, not with the number of features.

From this comes the symmetry that holds the whole conclusion. The requester owns the intent gate — “is this the right feature” has no oracle. The senior owns the architecture gate — “is this the right design, is it correct under load, under a race, under attack” has no oracle either. The loop fills the verifiable middle. Remove either gate and you get confident-wrong at scale: either the wrong feature, or a beautifully described feature on a naive, insecure architecture that passed shallow tests.

The honest, uncomfortable part: the headcount drops. The “implementer of clear specs” engineer is in the danger zone. The “architect and loop owner” engineer is needed more than ever. For the business, that’s exactly the point: the same number of people delivers several times more. Leverage.

The one-line takeaway: the loop pushes everyone up — to where there is no oracle — and erases the middle that the oracle covers. It doesn’t remove the role, it removes the oracle-coverable part of the role. The requester on intent. The senior on architecture. The loop in between, running exactly as far as the contract is verifiable from both ends.

Building on Boris Cherny, Peter Steinberger, Addy Osmani, and Anthropic Engineering.