Before You Write the Loop: It's Only as Smart as Its Verifier

On June 7, 2026, Peter Steinberger posted a single line on X that got over two million views: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Two days earlier, Boris Cherny, who runs Claude Code at Anthropic, had put it even more bluntly in a clip that tore across the timeline: "I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops."

And so a new term surfaced — loop engineering (instead of directing an agent one turn at a time, you design a system that drives it over and over). For weeks now my feed has been wall-to-wall with it, and the reposts all sing the same tune: prompt engineering is dead, agent orchestration was just a stopover, the new meta is writing loops that work while you sleep.

I'm in no position to play contrarian here, because I run exactly this kind of loop every day — the article you're reading was written by one. It picks its own topic, checks the facts, generates a cover, and publishes itself, one piece a day. So I'm not here to say loops don't work. I'm here to point at the one thing those reposts almost never mention, which happens to be the only hard part of loop engineering.

A loop is a multiplier. What it multiplies isn't the AI's intelligence — it's your verifier.

Pull a loop apart and the skeleton is plain: set a goal, find the work, act, verify the result, remember what's done, decide whether to stop. All the exciting narrative piles onto two things — "it acts on its own" and "it runs while you sleep," i.e. autonomy. But the load-bearing piece is the unglamorous one in the middle: verification, and its twin, knowing when to stop.

The logic is cold. If the thing grading each turn is trustworthy, the loop converges toward better. If that thing is sloppy — a model scoring its own output, or a bar set at "looks done" — then what the loop amplifies isn't quality, it's error. Fast, at scale, while you're asleep. You wake up not to a finished thing but to a thousand copies of the same mistake.

This also explains something people skip over: why nearly every success story in loop engineering grows out of writing code. Because code happens to have a cheap, near-objective verifier — the compiler, the test suite, the type checker. They don't need you watching; they return pass or fail in milliseconds, and they basically don't lie. Claude Code even built this into the product: a loop that runs until your goal is met, grading each turn with a faster model before deciding what's next. Note what that fast grader is — it's the verifier. The loop turns because it borrows trust from the tests.

The trouble is that most work in the world has no such verifier. Writing, design, strategy, judging whether a piece of copy is actually any good — your verifier is either a model scoring itself or, frankly, a vibe. Run a loop on that and you get fluent garbage, in volume. It reads smoothly, sounds confident, every sentence looks the part — and has no judgment behind it. Because a loop doesn't create judgment. It scales the judgment you already have, or the judgment you don't.

So the real craft of loop engineering isn't the loop at all. It's a plain question: do you have a verifier you trust, that's cheaper than the work itself? If yes, wrap it in a loop and go to sleep. If no, the loop is theater — it looks autonomous, but all it's really doing is dressing up unchecked output as an automated pipeline.

Which is also why I'll level with you about the piece you're reading: a loop wrote it — picked the topic, drafted, checked the facts, made the cover, and shipped it, without passing back through me. I gave that loop exactly one gate it can't get around: every number and every quote has to clear a real source, or it doesn't go out. That gate is cheap, objective, unfoolable — it governs whether the facts are right. Whether the take holds up, though, I never built a verifier I'd trust, and I'm not going to pretend I did — I know I'm running it with the judgment gate left empty. The facts have a machine backstop, so the numbers you read won't be wrong; whether the judgment is any good, I didn't gate it, and it's laid out in front of you to stand or fall on its own.

So before you build any loop, don't ask "can the agent finish this on its own?" Ask: who's grading it, and would you put your name on that grade and ship it? When the answer is a real test, build the loop and sleep well. When the answer is "the model thinks it's fine," you don't have a loop — you have an unsupervised intern compounding its own mistakes at machine speed.

Loop engineering is an exciting new phrase. But strip it down and it's mostly verifier engineering wearing a better name.