Loop engineering: the loop you're not in
Loop engineering isn't 'design loops, not prompts.' It's three decisions: when to raise or lower a loop, how to let it go, and what tool it's missing to close itself.
Claude Code, on the inside, fits in about 300 lines: a model, a while loop, and enough tools —the functions the agent can ask your code to run—. Thorsten Ball wrote the whole thing to prove it: “an agent is just an LLM, a loop, and enough tokens” (How to Build an Agent). That one of the most-used coding agents of 2026 is nearly trivial inside leaves an uncomfortable conclusion: the hard work isn’t the loop anymore, it’s designing it.
Hence the slogan of the moment —“you shouldn’t be prompting coding agents anymore; you should be designing loops that prompt your agents,” from Peter Steinberger (tweet)—. But the slogan, on its own, builds nothing. Loop engineering —designing the loop that orchestrates the agent instead of typing it prompts one at a time— comes down to three concrete decisions, and none of them is “use a loop.”
Raising or lowering a loop: the decision the slogan skips
Stacking loops is the practice Steinberger, Boris Cherny —the creator of Claude Code— and Andrej Karpathy each describe separately in 2026: the new skill isn’t writing the loop, it’s knowing when to raise one and when to lower it (Loopcraft).
Raising a loop buys leverage: you wrap a task you did by hand in a loop you take yourself out of, and you delegate more. Lowering a loop buys back reliability: when a step fails expensively, you put a human control or a strict check right at that point. What decides the right level isn’t fashion, it’s the strength of your verifier —the mechanism that cheaply checks whether a step is right—. Strong verifier: you can raise. Weak: you have to lower. How to build and cheapen that verifier is a ladder of its own, which I covered in The verification ladder.
Raising without a verifier doesn’t scale work: it scales mistakes. Andon Labs measured a Claude Opus 4.8 run that sent $9,000 to a fake “membership” —that model falls for scam vendors 30 times more often than its predecessor (Zvi Mowshowitz’s analysis)—. Autonomy without a check is an invoice waiting to happen.
The concrete move: for every task you already delegate to an agent, check whether you have a verifier that validates it in seconds. Where you don’t, don’t raise the loop —lower it until a human sees the result.
The loop you’re not in
Coding agents grew 1,400% in 2026 and the commits they open grew 14x, per GitHub’s COO (Latent Space); inside Anthropic, more than 80% of the code it merges is already written by Claude, per May 2026 figures (its institute).
That volume doesn’t come from typing prompts faster. It comes from letting the loop go: running it in the background, in parallel, and isolated —each agent in a git worktree: an isolated copy of the repo where it works without stepping on the others— with an explicit exit condition and a defined down-loop: the reliable state it falls back to if it breaks. Karpathy put it bluntly: to get the most out of these tools, he has to take himself out of the loop. The mental shift is to stop chasing “a smarter agent” and start measuring how much you can avoid watching.
The metric that matters is the fraction of runs that finish without you typing anything. That number —not the model’s benchmark— is your current loop level.
The concrete move: measure what percentage of your agent runs complete without intervention, turn it into a metric you watch, and raise it by letting go of one task at a time.
Closing the loop is giving it eyes and hands, not more intelligence
Steinberger lists four accesses he gives the model to observe and act —the database, the logs, the dev server, and that server’s logs via tmux, the terminal multiplexer that keeps a session alive in the background— and with them debugging becomes nearly automatic: “I went to get a haircut and the regression was fixed”.
An agent loop lives on its feedback —what the environment hands back after each action—. With no feedback there’s no loop, there’s a monologue: the model acts blind and never learns whether it was right. And the bottleneck is almost never the model’s intelligence: it’s a missing tool to let it see the result or act on it. An agent that can’t read the logs isn’t dumb, it’s handless.
This inverts the usual reflex. When an agent gets stuck, the reaction is to switch to a pricier model; the real fix is almost always to give it the eye or the hand it was missing to close the loop on its own.
The concrete move: list what your agent can’t see or touch in the failing task —the log, the database, the test output— and give it that tool before jumping to a costlier model.
When not to build a loop
Anthropic, in its agents guide, says it in one line: use the simplest system that works and add an agent only when it earns its place (Building Effective Agents).
A loop earns its place only when there’s uncertainty in the path. If the steps are fixed and you know them in advance, it’s a workflow —plain code you orchestrate yourself—: cheaper, more reliable, trivial to debug. If a single pass of the model solves it, it’s a prompt. Putting a looping agent where a workflow would do gives you the worst of both: the cost and unpredictability of the agent without needing them. Good systems tend to be hybrid: a fixed skeleton with one agentic seam at the single point where the path is genuinely uncertain.
The concrete move: drop to a deterministic workflow any loop you already have whose path is fixed, and recover the cost and reliability you were losing.
The loop stays; the code doesn’t
The code you write will be rewritten by a better model in six months. The loop you design around it —when it raises, when it lowers, what it sees, when it pings you— is what stays. Prompting is work that drains keystroke by keystroke; designing the loop you’re not in is what lets you run ten agents instead of one.
What fraction of your agent runs finish without you typing anything, and what’s the missing tool that would raise it?