On June 7, 2026, Peter Steinberger — the developer behind the open-source agent project OpenClaw — posted twelve words that the AI-coding internet has not stopped arguing about since: you shouldn't be prompting coding agents anymore, you should be designing loops that prompt your agents. The post reportedly pulled in millions of views within days. The next morning, Google engineer Addy Osmani published an essay titled "Loop Engineering" that gave the idea a name and a shape. Reddit did what Reddit does: half the replies called it the next real abstraction layer, the other half called it a cron job wearing a hat. Both are describing the same fact from different elevations: the unit of leverage in AI work moved. It stopped being the sentence you type and became the system that sentence runs inside.
What Prompt Engineering Actually Was
Prompt engineering, circa 2023 through early 2026, was a real craft with real technique: role framing, few-shot examples, chain-of-thought nudges, explicit output formats, instructions for when the model should refuse or ask a clarifying question. People got paid to write these well, because a single well-built prompt could be the difference between a usable answer and a mess. The craft assumed a specific shape of interaction — you ask, the model answers, you read the answer and decide what to do with it. One shot, one judgment call, entirely on the human.
That assumption broke. Models got good enough to run unattended for long stretches, call tools, write and execute code, read the result, and try again without a person watching every step. Once an agent can act more than once before a human looks at anything, the thing worth engineering is no longer the ask. It's the loop the ask lives inside — what happens after the model responds and before a person sees the result.
The Loop: Act, Check, Correct, Repeat
A loop, in the sense practitioners mean it now, is a repeating cycle: the agent takes an action, the system observes what happened, a verification step checks the result against a defined standard of "done," and the agent either stops, corrects, or tries again. Osmani's essay laid out the working parts — automations, worktrees, skills, connectors, sub-agents, and persistent external state — and the common thread across all of them is that none of it depends on a person supplying a better sentence in the moment. The system supplies the structure; the model supplies the labor.
In any loop, the verifier is the bottleneck, not the model.
That line is the part worth sitting with. A model that writes decent code but has no test suite checking it, no defined stopping condition, and no gate before it marks a task "complete" is not running a loop — it's running in circles. The discipline that matters here is deciding what "good" and "done" mean well enough that a machine can check for them without a human re-reading every output. Teams building serious agent evaluation lean on automated scorers and LLM-as-judge review layers so the loop can grade its own homework before a human ever sees it.
You've already lived a small version of this if you've asked a model to draft something, told it what was wrong, and had it revise — twice, three times — before you touched it yourself. That's a loop with a human as the verifier. The shift practitioners are describing is putting the verification step inside the system too: a test that has to pass, a rubric an agent checks itself against, a rule that says stop after the same error shows up three times in a row instead of trying a fourth. Reflection techniques where a model critiques its own draft before returning it, and frameworks that let an agent call a tool to check its own reasoning, are the same idea in miniature.
Prompt Sellers vs. Loop Builders
The title's claim needs one honest caveat: prompts did not disappear. Every step inside a loop still runs on a prompt — the instruction that tells the sub-agent what to do, the rubric that tells the verifier what to check, the message that tells a tool when to fire. Loop engineering didn't retire prompt craft. It demoted it from the whole job to one component of a bigger one — a smaller job than the one prompt engineers were sold two years ago, and a more durable one.
So when someone offers to sell you "the prompt" for a business problem, ask what happens after the model responds. If the honest answer is "you read it and decide," you bought a prompt. If the answer involves a defined check, a retry rule, and a condition under which the system stops and flags a human, you're looking at a loop — and that's the version built to survive contact with a task that takes longer than one exchange to finish.
- Ask what the stopping condition is. "It looks done" is not one. A specific test, rubric, or check is.
- Ask what happens on a bad result. If the answer is "we'd notice and fix it manually," there is no loop, just a prompt with a human safety net.
- Ask how many times the system tried before you saw the output. One try dressed up in good formatting is still just a prompt.
Prompt engineering isn't dead. It's table stakes now, folded into a bigger discipline the way a well-worded email is folded into a functioning business process. The people shipping real agentic work in mid-2026 aren't the ones who found the perfect phrasing. They're the ones who built the system that keeps trying until the work is actually right.
