If you have used Claude Code, Codex, Workbuddy, or Kimi Work in the past six months, you have felt the shift: instead of instructing an AI sentence by sentence, you drop in a requirement and it writes, runs, hits an error, fixes itself, and keeps going until the thing exists. That self-turning quality has a name, and the name is becoming this year’s consensus engineering discipline: loop engineering.
In June, OpenClaw creator Peter Steinberger lit the fuse with a post that traveled far: you should not be writing prompts for coding agents anymore — you should be designing loops. Shortly before, Google engineering lead Addy Osmani had systematized the loop concept in a widely shared essay. And the person who first made loops shine, Claude Code creator Boris Cherny, published the four loop primitives built into Claude Code at the end of June. In under a month, loop engineering went from industry slang to mainstream focus.
Most commentary stops at the efficiency story. Go one layer deeper and something more consequential is happening: humans are being pushed out of the center of the loop. That structural change will matter far longer than the speedups.
From Writing Prompts to Designing Harnesses: What Agents Actually Gained
The old discipline of AI usage revolved around prompts. The finer your instructions, the better the output — for chat. But once models became agents, they stopped merely answering and started deciding: when to read a file, when to run a command, when to search the web, when to stop and ask a human. Prompt engineering was no longer enough.
What emerged first was harness engineering — the runtime frame around the model that wires up tools, manages permissions, injects context, and persists state. The model still does the reasoning, but it now lives inside an environment that can actually execute work.
Loop engineering is the next step out: it concerns how to make an agent revolve around a goal continuously. You give a goal; the agent interprets the task, gathers context, calls tools, observes results, judges completion, keeps fixing if unfinished, keeps running, keeps checking. It looks suspiciously like how people work: draft, find problems, redraft, until it ships.
The essence of a loop is not the word “cycle.” It is what you put inside the cycle — and who decides when the cycle stops.
Four Loop Primitives: Knowing When to Do What
Anthropic’s June post split loops into four types, and the taxonomy is more revealing than it looks:
- Turn-based — you send a message, it replies. The classic conversation pattern.
- Goal-based — “build me a login page,” and it writes, tests, and iterates until done. This is the default mode of Claude Code and Codex.
- Time-based — every two hours, check a pull request and review any updates. The agent acquires scheduled, standing vigilance.
- Proactive — the most aggressive. The agent notices something itself — say, test coverage declining — and goes to fix it unprompted.
The order is not accidental. From turn-based to proactive, each step transfers more trigger authority from humans to systems. The first two keep people as the ignition source: humans move first, agents follow. The last two hand over the keys along the time dimension and the state dimension. A proactive loop, at bottom, means the agent has acquired a primitive sense of “what is worth doing” — however rudimentary that judgment still is.
Andrew Ng’s Real Insight: Three Nested Loops
The most complete framework came from Andrew Ng’s June 30 letter, which placed loops inside the whole arc of building a product rather than inside a code editor. His model draws three concentric cycles:
| Loop | Cadence | Who runs it | What it decides |
|---|---|---|---|
| Agentic coding loop | Seconds to minutes | The agent itself | Write, test, iterate code until tests pass |
| Developer feedback loop | Tens of minutes to hours | Developers | Review direction, adjust specs, calibrate goals |
| External feedback loop | Hours to weeks | Users and market | Beta feedback, A/B tests, production data reshaping the product |
Notice the pattern: the further out you go, the slower the loop — and the more human the verifier. The innermost loop can self-verify with test cases; code that passes tests has passed, with no room for taste. The second loop requires a developer to judge whether the direction is right, whether the experience feels good — not automatable. The outermost loop takes days or weeks to converge, and no AI on earth can compress how fast users actually behave.
Ng also performed a quiet but important correction on a popular idea. Many people summarize the human residual value in the AI era as “taste” — an ineffable aesthetic judgment. Ng swapped in a more precise term: context advantage.
As long as humans know something the AI does not, humans need to be in the loop to inject that knowledge.
Taste sounds innate and unteachable. Context advantage tells you exactly what to encode into the loop: the facts about your users, your business, and your problem that you know and your model does not. That is the actual value you provide from outside the cycle — not “better taste than the AI,” but “knowledge the AI lacks.”
Who Decides “Done”? The Verifier Bottleneck
The framework exposes the most under-examined failure mode in loop engineering: the verifier bottleneck. In a closed loop with no human intervention, the agent runs until some stop condition is met. If that condition is poorly defined — if you failed to encode your context advantage into the verification mechanism — the agent will quietly become a very expensive garbage generator. As the AI Builder Club’s loop engineering guide put it: in any loop, the verifier is the bottleneck, not the model.
Each verification strategy buys speed with a different blind spot:
- Manual eyeballing drags the second loop’s cadence down to minutes. The human becomes the slowest component of a system built for speed.
- Test-case verification can check whether something works, never whether it is good.
- Model-as-verifier introduces cascading hallucination risk — one confident model grading another confident model.
- Deferring all verification to users pulls the weeks-long outer loop into the innermost cycle, and the whole system stalls.
This is why context advantage matters so much: the verifier bottleneck is not a model-capability problem. It is the cost of knowledge you possess but never wrote down. You know why users abandon your signup flow at step three. If that knowledge is not encoded into the acceptance criteria, the agent will grind forever without ever learning where the actual defect is.
The Framework Travels Well Beyond Coding
Run the three-loop model against other domains and it predicts failures with uncomfortable accuracy. A data-analysis agent runs SQL and builds charts in seconds; a data scientist reviews results, asks about the outlier nobody considered, and steers analysis in hourly cycles; the business unit consumes reports and reshapes the analytical framework over days to weeks. Many analysis products die at layer two — the scientist becomes a manual review conveyor belt. A customer-service agent resolves common issues in seconds, a QA team reviews transcripts and iterates the knowledge base hourly, and satisfaction surveys plus NPS data recalibrate strategy weekly — skip the outer loop and the knowledge base drifts away from what customers actually want. A sales-content agent drafts personalized email in minutes, a sales lead reviews tone and compliance hourly, and reply-rate data reshapes messaging over days — the classic failure is trying to automate all verification into the inner loop, which produces mountains of compliant email that nobody answers.
The pattern across all three: teams that cram layer-two and layer-three verification into layer one stall out; teams that keep the three cadences distinct, with humans and AI each holding their own layer, keep compounding. That is not a technology problem. It is a systems-design problem.
What It Means for You
Loop engineering is not another jargon drop; it is a structural renegotiation of the human-machine relationship. For three years the underlying pattern of AI use never changed — a human instructs, the AI executes, the human judges the result. The human sat inside the loop as its engine. Loop engineering is the first paradigm that moves the human from the center of the cycle to its perimeter: from driver to navigator.
- If you are a developer, your competitive edge is no longer prompt craftsmanship. It is the ability to define problems, design acceptance criteria, and encode what you know that the model does not into verification mechanisms. Stop asking “can the model build this feature” and start asking “how should this loop be designed so the agent can drive it to completion itself.”
- If you are a product manager, internal iteration speed is about to collapse to seconds at the coding layer — but product judgment and user feedback will not get faster. Team pressure migrates upward to the abstraction layer: the quality of your specs and acceptance criteria now directly caps the quality of what agents produce.
- If you own the business side, your specific, unencoded knowledge of the business is appreciating. Context advantage is not automated away — as long as you know things the model does not, you belong in the loop. What you need to learn is not prompt writing but the structuring of business knowledge into verification rules.
Everyone starts with the same instinct — the AI is a brilliant intern who needs watching. Loop engineering’s whole design goal is to turn that watching from micromanagement into management by objective. You are no longer supervising each step the agent takes. You are designing the system inside which it works effectively. That is the most important AI mental-model upgrade of 2026 — not about the models, but about our relationship with them.
Sources: Anthropic, Getting Started with Loops; Andrew Ng, The Batch, June 30, 2026; AI Builder Club Loop Engineering Guide (2026); public posts by Addy Osmani and Peter Steinberger.
