Loop Engineering: When You Stop Prompting and Start Building the Loop That Prompts

Part 3 · The Agent Stack

The people who build the most-used coding agents have stopped hand-prompting. The unit of work is no longer a prompt. It's a loop that prompts, checks, remembers, and re-runs an agent for you.

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, something real has changed.

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 sits 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 put it plainly: 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. These layers build on each other; each new one still needs the ones below it:

• 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 is a stack of layers that all stay in use, and loop engineering is the one getting the attention right now because the newest models finally made it 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 is design a cycle that stays correct and pointed at the goal. Wording a single prompt matters far less.

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 1

Every 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. Without a hard stop, an unattended loop keeps spending until you notice.

Validation comes from the environment. 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 like tests, type checkers, linters, and 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 judge whether it's correct, because it marks itself too generously. 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 has stopped making progress; it's stuck. Detecting no-progress and escalating to a human is a first-class part of the design, built in from the start.

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. That's 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 are exactly the ones above: the termination condition, the verifier split, the iteration and cost caps, the escalation path. 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, covering friends-and-family testers, alpha testers, production users, and 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 keeps the human genuinely central, not as a sentimental afterthought. 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 keeps spending whether or not it's making progress. One 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). With those, reliability 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

The hype skips this part: three problems actually get worse 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. That's the comprehension debt 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 those two apart. You can. That's what makes loop design genuinely harder than prompt engineering. It won't spare you from understanding your own system; it only amplifies whatever grip on it you already have.

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 genuinely multiplies your output. Skip them and all you've automated is the speed at which you make a mess you don't understand. 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).