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 interaction is no longer a prompt. It's a loop that prompts, checks, remembers, and re-runs an agent for you.

For about 2 years people generally would write a good prompt, hand the agent enough context, read what came back, and then move on to the next prompt. You hand-held the tool the entire time, one prompt after another, only limited to however long you were willing to sit at your desk.

That pattern broke fast in early June 2026. 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, said he doesn't prompt Claude anymore. His job is to write the loops that prompt Claude and decide what to do next. Addy Osmani coined the term in his essay "Loop Engineering," and Andrew Ng helped bring it wider attention. When the people who build the most-used coding agents all say they've stopped prompting by hand within a couple weeks of each other, the mindset has shifted.

If you've read the first two pieces in this series, this one follow up perfectly. 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 task so you don't need to sit there every step of the way.

What loop engineering actually is

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 concept goes 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, rather than a coincidence of how the agent happens to behave. A 2026 analysis of Claude Code said 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.

The loop itself is trivial, but everything that makes it reliable is the engineering.

Where it sits in the stack

Loop engineering can be considered the latest layer, not a replacement. Some prioritize it as prompt engineering → context engineering → harness engineering → loop engineering; others as prompt engineering → agent orchestration → loop engineering. These layers build on each other and 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 concept, 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.

This has picked up steam because the models have finally become more powerful. 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.

The anatomy of a real loop

Here's a minimal goal loop, written in plain shell so every moving part is visible.

# 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 20 lines:

The goal is explicit, with a hard stop. GOAL is a verifiable condition ("tests pass"), not a vibed prompt. 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 potentially bias self-assessment.

The verifier is a different role. This is the guardrail Osmani stresses the most: 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.

Infinite loop or stalled progress detection. 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.

These concepts are now shipping in the tools

A year ago, a loop meant a pile of bash you owned and maintained forever. 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.

Ng's 3 loops: not everything runs at the same speed

There isn't 1 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. 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 to put in place

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 crazy 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. These 3 are a good measure: 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.

The risks that sneak in as the loop gets better

3 problems actually get worse as your loop improves.

A smoother loop makes mistakes faster and unattended. The verifier saying "done" is a checked off box, not 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. 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 said 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 2 apart, but 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

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).