A few months ago, a developer's evening was a ritual of endless prompting. Open the coding agent, type an instruction, wait, read the output, paste the error message, wait again, nudge it in a slightly different direction, and repeat until the feature worked or it was time to sleep. The agent was doing real work, but the human was still holding it the entire time, one turn after another, like driving a car that needs a hand on the wheel every three seconds.
That evening looks different now for a growing number of engineers. They write one instruction, close the laptop, and return the next morning to a draft pull request, a triaged issue list, or a green CI build, along with a readable trail of what the agent tried and why. Nobody stood over it, typing the next prompt. What changed wasn't the model. It was what got built around the model. The name that stuck for that shift is loop engineering, and it went from a niche phrase to a topic of heated debate across every timeline within about a week in June 2026.
What is Loop Engineering?
Loop engineering is the practice of designing the system that prompts, checks, remembers, and re-runs an AI agent, instead of a person doing all of that by hand, turn by turn. The unit of work stops being a single prompt or even a single conversation. It becomes a loop: a repeating cycle where the model takes an action, gets feedback from its environment, uses that feedback to decide what to do next, and keeps going until a real, checkable condition is met.
It helps to hold this next to the thing it's replacing. A chain runs in a fixed order: step A leads to step B, which leads to step C, and that's it. A loop is dynamic. The agent might go from A to B, discover B didn't work, revise its approach, and only then move to C, or it might loop back to A entirely. The concept is simple: a loop continues until a task is genuinely complete, a stopping condition triggers, or the agent determines it can't go any further. That's a fundamentally different shape of work than "ask once, get an answer, copy it out."
The other framing worth sitting with is the "purpose-driven" idea. Instead of typing each next step, you define a purpose, something like "review this pull request" or "fix all failing tests," and the agent iterates on its own toward that purpose: inspect the code, make a change, run a check, read the outcome, decide the next move. The skill shifts from writing one very good sentence to designing a cycle you trust enough to walk away from.
The June 2026 Tipping Point
It's worth being specific about the timeline here, because the speed is part of the story. On June 7, 2026, developer Peter Steinberger, known for the OpenClaw agent project, noted that the relevant skill had already changed: you shouldn't be prompting coding agents anymore, you should be designing the loops that prompt them for you. That post reportedly crossed 6.5 million views within days and dominated agent-focused conversation for the following week.
The very next day, Google engineer and author Addy Osmani published an essay that took Steinberger's claim and gave it an actual anatomy: automations, worktrees, skills, connectors, and sub-agents, plus a sixth piece underneath all of it, external memory. That essay turned a viral take into a vocabulary that other people could build on and argue about.
It wasn't only outsiders making this case. Boris Cherny, who leads Claude Code at Anthropic, is quoted by Osmani as saying, "I don't prompt Claude anymore. I have loops running that prompt Claude, and figuring out what to do. My job is to write loops." When the person building one of the most-used coding agents on the market says he's stopped prompting it directly, the idea has clearly moved past a fringe opinion.
The timing makes sense once you look at what changed underneath it. By mid-2026, coding agents had gotten good enough to run unattended for genuinely long stretches, recovering from their own mistakes along the way, rather than needing correction every second or third step. Once a single agent run can last an hour and touch dozens of files, the bottleneck isn't the sharpness of your prompt anymore. It's whether you've built a cycle that keeps the agent productive, checked, and pointed at the right goal for the whole hour, including the part where nobody's watching.
The Evolution from Prompting to Loops
Loop engineering didn't appear out of nowhere, and it helps to see it as the newest layer in a steady progression outward, each one wrapping the previous layer rather than replacing it. Prompt engineering came first, roughly 2022 through 2024. The skill was wording: giving the model a role, breaking a task into steps, providing examples, and asking it to reason step by step. It optimized expression, and its ceiling was real, even a perfectly worded prompt can't hand the model facts it was never given.
Context engineering followed in 2025. The focus moved from the words themselves to everything the model actually sees at the moment it responds: conversation history, retrieved documents, tool output, and any other information assembled for that step. Prompt engineering effectively became one ingredient within context engineering rather than a separate discipline.
Harness engineering arrived in early 2026 as agents started doing longer, more autonomous, multi-step work in real production settings. The harness is the full environment around an agent, the scaffolding, the tools it's given, the constraints it operates under, and the feedback loops that catch its mistakes. It's what makes an agent dependable instead of merely capable, and it nests both prior layers inside it: a harness contains context, and context contains prompts.
Loop engineering is the layer sitting on top of all three. Where harness engineering asks what environment an agent needs, loop engineering asks a narrower, more operational question: what cycle keeps the agent working toward the goal, and when exactly does that cycle stop? None of these layers replaced the one before it. You still write prompts, you still curate context, you still build a harness. Loop engineering is simply the part where all of that gets put into motion and given a rhythm.
The Research Lineage: ReAct and Reflexion
It's tempting to treat loop engineering as something invented in a single week in June, but the mechanics behind it are closer to five years old, and knowing the lineage is what separates a real understanding of the idea from just repeating the trend piece. The direct ancestor is the ReAct framework, short for Reason plus Act, introduced by Yao and colleagues in 2022. The core idea was to interleave reasoning steps with action steps: the model thinks about what to do, takes an action, observes what actually happened, thinks again in light of that observation, and acts again. That interleaving, reason, act, observe, repeat, is the base loop that essentially every modern coding agent still runs today.
A year later, Reflexion, from Shinn and colleagues in 2023, added something ReAct didn't have: memory and self-critique. A Reflexion-style agent runs three distinct roles instead of one: an Actor that does the work, an Evaluator that scores the result, and a Self-Reflection step that writes an actual verbal lesson, something like "the patch failed because the import path was wrong," into an episodic memory the agent reads back on its next attempt. That's the mechanism behind a loop that visibly improves within a single session, without anyone retraining the underlying model.
Anthropic's own December 2024 guide, "Building Effective Agents," named two more patterns worth knowing. The evaluator-optimizer pattern has one model generate a candidate solution while a second model checks it against explicit criteria and hands back feedback, cycling until the evaluation actually passes. The orchestrator-workers pattern has a central model that dynamically breaks a large task into smaller pieces, hands each piece to its own worker with a clean context window, and then combines the results. If Osmani's "sub-agents" and "worktrees" sounded familiar, this is the formal version of the same idea.
The point of walking through all four of these isn't trivia. It's that "loop engineering" is a product name and a rallying phrase for a research direction that's been quietly accumulating results since 2022. The June 2026 moment didn't invent the loop. It gave regular developers, not just researchers, a reason and a vocabulary to start building one deliberately.
The Anatomy of a Reliable Loop
Strip away the branding and a loop that's actually reliable, rather than one that spins its wheels or runs forever, tends to have the same handful of components, no matter which tool or team built it. It needs a goal with a genuinely testable termination condition. "Make the app better" gives an agent nothing to check against, so it either runs forever or stops arbitrarily based on a guess. "Make every test in the auth module pass" is checkable in a literal, mechanical sense, and that difference is the whole ballgame.
It needs tools that actually touch the real environment: code execution so it can see whether something runs, file system access to read and write, a terminal for commands, a test runner and a linter to generate honest feedback. A loop's feedback is only as trustworthy as the tools producing it. An agent that can reason brilliantly but can't run its own code is just guessing with extra steps.
It needs context management. Every iteration of a loop adds more to the record, the code written, the errors hit, the decisions made along the way, and a context window is a fixed size. Left unmanaged, a long loop either overflows that window or, more insidiously, starts attending less carefully to what actually matters as the transcript grows, a problem people increasingly call context rot.
It needs termination conditions: a real success condition, a real failure condition (a maximum number of iterations, a token or time budget, repeated identical errors with no progress), and a defined path to hand the problem to a human instead of continuing to burn resources on a dead end.
And it needs error handling that actually distinguishes a recoverable problem, a bad import, a failing assertion, from a hard blocker, such as a missing credential or an undefined API. A loop that retries the exact same action after the exact same error isn't adapting. It's spinning.
From Theory to Practice
Not every task calls for the same shape of loop, and picking the wrong one is a common source of wasted tokens and unnecessary complexity. The retry loop is the simplest version: try something, check if it worked, retry if it didn't. It suits short, atomic tasks with a clear pass or fail line, like writing a function against a known test. The failure mode to watch for is retrying the same broken approach indefinitely without varying the strategy.
The plan-execute-verify loop generates a plan first, then works through it step by step, checking each step before moving to the next. It fits multi-step work where order matters and an early mistake compounds, like refactoring a shared module. The risk here is over-committing to a plan that turns out to be wrong two steps in, rather than revising it.
The explore-narrow loop tries several approaches, either at once or in sequence, and narrows toward whichever one is producing the best intermediate signal. It's the right shape for genuinely unfamiliar territory: debugging an error nobody's seen before, or exploring an unfamiliar API's actual behavior. The cost is context: running several paths at once is expensive, so pruning early and often matters more here than anywhere else.
Human-in-the-loop deserves to be named as a real pattern rather than treated as a fallback tacked onto the others. The agent runs until it hits genuine ambiguity or the end of a decision with real stakes, pauses, and waits for a person before continuing. It's the right choice whenever a wrong assumption is expensive to unwind, like a production database change. The failure mode is the opposite of the others: interrupting so often that the human isn't actually saving any time by having an agent in the loop at all.
The most useful place to start is the simplest possible version of everything described above, not the fully stacked, four-layer system. One goal, stated specifically enough to be checkable. One deterministic verifier, an actual test suite rather than a model's self-assessment. A hard cap on iterations. And exactly one escalation path for when the loop gets stuck, rather than several half-built ones. The task worth picking first is something recurring and genuinely low-stakes: a nightly triage pass over new issues, a scheduled report summarizing the week's activity, a lint-and-fix pass over a single directory. Resist the urge to reach for parallel worktrees, sub-agents, or a full hill-climbing layer before that first, simple loop has actually run cleanly for a couple of weeks.
The real shift underneath all of this isn't that the work got easier. It's that the leverage point has moved. When a model can write the code itself, the scarce skill stops being the ability to phrase one very good instruction and becomes the ability to design a cycle that stays correct, verified, and pointed at the right goal while nobody's actively watching it. That's a systems-engineering habit, closer to designing a thermostat than to writing a sentence, and it's exactly why the people closest to this work insist on calling it engineering rather than a trick. Build the loop. But build it the way someone who intends to stay the engineer would, checking what it produced, understanding why it stopped where it did, and treating "done" as a claim worth verifying rather than one worth taking on faith.