For about two years the job was steady: write a good prompt, hand the agent enough context, read what came back, type the next thing. You held the tool the whole time, one turn after another, and your ceiling was however long you were willing to sit there driving.
That posture broke in early June 2026, and it broke fast. Within about a week, Peter Steinberger — who built the popular open-source agent OpenClaw — told everyone to stop hand-crafting prompts and start designing loops that prompt the agents for you. Boris Cherny, who leads Claude Code at Anthropic, put it more bluntly: he doesn't prompt Claude anymore; his job is to write the loops that prompt Claude and decide what to do next. Addy Osmani gave the practice a name and an anatomy in an essay called "Loop Engineering," and Andrew Ng amplified it. When the people who build the most-used coding agents all say they've stopped prompting by hand in the same fortnight, it's not a meme — it's a phase change.
If you've read the first two pieces in this series, this one sits directly on top of them. The code-review gauntlet was about what a verifier checks. The orchestration guide was about running several agents without collisions. Loop engineering is the floor above both: the system that decides what work to hand out, keeps the agents moving, checks their output, records what's done, and figures out the next thing — so that you're not the one poking the agent every turn.
What loop engineering actually is
Strip away the excitement and the definition is simple. Loop engineering is designing the system that prompts, checks, remembers, and re-runs an agent, instead of you typing every next instruction. The unit of work is no longer a prompt, or even a conversation. It's a loop: the model takes an action, gets feedback from its environment, uses that feedback to decide the next move, and continues until a defined stopping condition is met.
The shape isn't new — it traces straight back to the ReAct pattern (reason, then act, then observe, then repeat) and evolved through self-critique and plan-and-execute into the long-running "while-not-done" loops that modern agents run. What's new is that the loop is now the object you engineer, deliberately, rather than an accident of how the agent happens to behave. A 2026 analysis of Claude Code made the point with a shrug: the core of the system is a simple while-loop that calls the model, runs tools, and repeats — and essentially all the hard engineering lives around that loop, in permissions, context management, sub-agent delegation, and state.
That's the tell that this is real and not just branding. The loop itself is trivial. Everything that makes it reliable is the engineering.
Where it sits in the stack
It's fair to call loop engineering the latest layer, as long as you don't mistake "latest" for "replacement." The lineage gets told a couple of ways — some draw it as prompt engineering → context engineering → harness engineering → loop engineering; others as prompt engineering → agent orchestration → loop engineering. Don't overthink the exact ordering, because these are complementary layers, not a relay race where each hands off and leaves:
- Context engineering manages what the model sees on any given turn.
- Harness engineering is the whole environment a single agent runs inside — its tools, permissions, memory.
- Orchestration coordinates several agents at once without them colliding.
- Loop engineering designs the repeating cycle that drives all of the above toward a goal.
And spec-driven development isn't even on the same axis — it's how you define the goal the loop chases. In Ng's framing, the slower human feedback loops are what shape your spec, which then drives the coding loop. So the honest picture isn't a ladder you climb and abandon rung by rung; it's a stack, and loop engineering is the layer that's currently getting the attention because it's the one the newest models finally made viable.
Which answers the "why now": the models got good enough. By mid-2026 a single agent run could last an hour, touch dozens of files, and recover from its own mistakes often enough to be trusted to keep going. Once that's true, the highest-leverage thing you can do stops being writing a sharper sentence and starts being designing a cycle that stays correct and pointed at the goal.
The anatomy of a real loop
Here's a minimal goal loop, deliberately written in plain shell so every moving part is visible. In practice you'd lean on the primitives your tools now ship (more on that below), but you should understand what they're doing for you.
# loop.sh — a minimal goal loop with a hard stop
GOAL="every test in packages/api passes"
MAX_ITERS=12
for i in $(seq 1 $MAX_ITERS); do
# 1. ACT — the maker makes ONE focused change, in an isolated worktree
agent run --role maker --worktree ../wt-fix \
--prompt "Goal: $GOAL. Make one focused change toward it, then stop."
# 2. VALIDATE — the environment is the source of truth, not the agent's opinion
if pnpm --dir ../wt-fix test --filter api; then
# 3. VERIFY — an INDEPENDENT agent checks the diff against the goal
if agent run --role verifier --worktree ../wt-fix \
--prompt "Does this diff satisfy '$GOAL' without weakening any test? Answer PASS or FAIL."; then
echo "done in $i iterations"; open_pr ../wt-fix; exit 0
fi
fi
# 4. SPIN GUARD — if the last two changes were identical, we're not learning
same_as_last_change ../wt-fix && { escalate "loop is spinning"; exit 1; }
done
escalate "hit iteration cap without passing"; exit 1Every design decision that separates a loop that works from one that spins is in those twenty lines:
The goal is explicit and the stop is hard. GOAL is a verifiable
condition ("tests pass"), not a vibe. MAX_ITERS guarantees the loop terminates even if
nothing else does. A loop without a hard stop is a bill, not a feature.
Validation comes from the environment, not the agent. The pnpm test
result is ground truth. This is the single most important move in loop design: the loop converges
because it corrects against real signals — tests, type checkers, linters, runtime errors — rather than
against the model's self-assessment.
The verifier is a different role than the maker. This is the guardrail Osmani stresses hardest: you cannot let the model that wrote the code grade its own homework, because the grades come back inflated. Splitting maker and verifier is what makes the loop's "it's done" mean something. It's also exactly the review-gauntlet discipline from the first article, now automated and moved inside the loop.
There's a spin detector. A loop that retries the same action after the same error isn't iterating, it's stuck. Detecting no-progress and escalating to a human is a first-class part of the design, not an afterthought.
Isolation is assumed. Every change happens in a worktree, so a running loop can't corrupt your working tree and several loops can run at once without colliding — the orchestration primitive from the second article, now the substrate the loop runs on.
The primitives are shipping in the tools
A year ago, a loop meant a pile of bash you owned and maintained forever. That's ending. The tools
now ship the primitives directly: OpenAI's Codex exposes a /goal that keeps working
across turns until a verifiable stopping condition holds, with pause, resume, and clear; Claude Code
offers the same primitive under its own surface. Steinberger's checklist of what a loop needs maps
almost one-to-one onto both products. Anthropic has even started categorizing the loops themselves
into types — the basic turn-based loop where you send a message and it replies, the goal-based loop
that writes, tests, reads errors, and revises until the tests pass, and others above them.
The practical upshot: you'll increasingly configure loops rather than script them. But the configuration choices — the termination condition, the verifier split, the iteration and cost caps, the escalation path — are exactly the ones above. The bash is going away; the engineering decisions are not.
Ng's three loops: not everything runs at the same speed
One framing worth stealing from Andrew Ng: there isn't one loop, there are nested loops running at different cadences. The inner agentic coding loop turns in seconds to minutes — act, test, revise. A developer feedback loop wraps it at the scale of hours, where you review what the agent produced and adjust direction. And an external feedback loop — friends, alpha testers, production users, A/B tests — runs over days or weeks and reshapes the product vision, which then rewrites the spec that drives everything below.
The reason this matters is that it puts the human back at the center honestly, rather than as a nostalgic footnote. Ng's own phrasing is that humans hold a context advantage — we know more about the users and the situation than the model does — and that advantage lives in the outer loops. The agent is fast in the inner loop; you are irreplaceable in the outer ones. Loop engineering done well is mostly about wiring those cadences together so the fast loop stays aimed at what the slow loops learned.
Failure modes, and the guardrails that answer them
Loops fail in a small set of well-known ways. Design for each from the start:
Spinning. The loop retries the same failing action forever. Guardrail: a no-progress detector and a hard iteration cap.
Cost blowout. An unattended loop is an unattended meter. A loop that re-loads context and re-explores every turn can burn a startling amount of money overnight. Guardrail: a cost budget that halts the loop, plus tight per-iteration context.
Self-grading. An agent that evaluates its own output reports success it didn't earn. Guardrail: an independent verifier role, separate from the maker.
Prompt injection through what the loop observes. This one is under-covered and it matters more as loops get more autonomous. Every web page, issue, or file the loop reads is untrusted input, and a loop that takes real actions on the strength of that input is a loop that can be steered by it. Guardrail: run the loop in an isolated sandbox, and scope its permissions to the minimum the goal requires.
How to measure a loop
Most write-ups describe loop patterns and never tell you how to judge one. Three numbers do the job: goal success rate (how often the loop reaches a correct, complete result), iterations to done (how efficiently it gets there), and cost (tokens and dollars per completed goal). Reliability stops being a hope you have about a clever prompt and becomes a property you can measure and tune — which is precisely why the practice earns the word "engineering."
The risks that get sharper as the loop gets better
Here's the part the hype skips: three problems get worse, not better, as your loop improves.
A smoother loop makes mistakes faster and unattended. The verifier saying "done" is a claim, not a proof, which is why human review of merged changes stays in the loop no matter how good the automated check gets. A faster loop also widens the gap between what's in the repo and what you actually understand — the comprehension debt that AI-assisted coding always carried, now accelerating, because a good loop ships code you didn't write faster than you can read it. And an autonomous loop with connector access can reach production systems, which turns a lax permission model from a code-quality problem into a security one.
Osmani has the sharpest line on all of this: two people can build the exact same loop and get opposite results. One uses it to move faster on work they understand deeply; the other uses it to avoid understanding the work at all. The loop can't tell the difference — you can. That's what makes loop design genuinely harder than prompt engineering. It isn't a shortcut around understanding your system; it's a force multiplier on whatever relationship you already have with it.
The skill moved up a floor again
Every layer of this stack has been the same move repeated: the leverage keeps climbing to a higher level of abstraction, and the scarce skill climbs with it. Prompt engineering was about the sentence. Context engineering was about the window. Orchestration was about the team. Loop engineering is about the cycle — and the thing you're really engineering is the point at which "done" becomes trustworthy without you watching.
Which is why this piece is the top of the series and not a replacement for it. A loop is only as good as the verifier inside it (that's your review gauntlet) and the isolation it runs on (that's your worktrees and sequential merges). Build those well and the loop is a genuine multiplier. Skip them and you've just automated the process of digging yourself into a hole faster than you can climb out. Set up your loops — and keep reading what they produce.
Companion pieces: "The AI Code Review Gauntlet" (what the verifier inside your loop should actually check) and "Running a Team of Agents Without the Chaos" (the worktree isolation and sequential merges a loop runs on).