Three Generations:
This Isn't Replacement, It's Layering
The person who coined "design loops, not prompts" was OpenClaw author Peter Steinberger; his tweet in early June 2026 broke 6.5 million impressions within a week. Anthropic Claude Code lead Boris Cherny immediately endorsed it: "I don't prompt Claude anymore—I have a bunch of loops running; they prompt Claude, decide what to do next—my job is to write loops." Days later, Google Cloud AI Director and former Chrome engineering lead Addy Osmani wrote the article "Loop Engineering," naming the phenomenon and dissecting its anatomy.
One-sentence definition: Loop Engineering = replacing "the person prompting the agent" with "a system you design." Over the past two years, the way you got results from an agent was to write prompts, stuff in enough context, read what it returned, then type the next line—the agent was a tool, you held it in your hands turn by turn. Loop Engineering says: you build a small system that finds work, dispatches work, verifies work, notes what it did, decides the next step, and then this system pokes the agent—not you.
| Generation | Core Question | Leverage Point |
|---|---|---|
| Prompt Engineering (2022–23) | What should I say to get the best output? | Wording |
| Context Engineering (2024–25) | What information should I feed into the context window, and in what order? | Information orchestration |
| Loop Engineering (2026–) | What system should I build so the agent finds work, does work, verifies work, and remembers—without me throughout? | System architecture |
Osmani's original phrasing is the most concise: "You don't really need to be good at prompting anymore. What you need to be good at is the loop that prompts for you." But he immediately added a caveat—this is still early, he himself is skeptical, and you must watch token costs; the usage patterns of people with abundant tokens versus scarce tokens are worlds apart.
Four threads converge at the same time: writing code itself is becoming free (production cost trending to zero; cost shifts to maintenance and architecture debt); the human-machine division of labor has been empirically measured for the first time (Anthropic's analysis of 400K Claude Code sessions shows humans do ~70% of "what to do," agents do ~80% of "how to do it"); models are finally reliable enough to let them run on their own (six months ago a loop would spin 40 times to find a solution; now it often lands in 3–5 rounds); and an external shock (the strongest model disappearing overnight due to regulation) forced the methodological question "are you using AI, or are you prompting and praying?" onto the front stage.
From ReAct to /loop /goal:
A Four-Step Evolution
Loop Engineering isn't a term that appeared out of thin air—it's the moment an engineering lineage matured and got named: in 2022, ReAct-style reasoning loops let models alternate "reason + act"; in 2023, AutoGPT conducted the first large-scale experiment of "let the agent run on its own"; in 2025, independent engineer Geoffrey Huntley named the Ralph loop—a one-line bash script stuffing the agent into an infinite loop—which became the representative grassroots practice; in 2026, Codex and Claude Code baked these patterns directly into product commands /loop, /goal. Osmani points out the most surprising part: a year ago, if you wanted a loop you had to write a bunch of bash hacks and maintain them yourself; now these components ship with the product—Steinberger's checklist maps almost one-to-one to the Codex app, and maps almost identically to Claude Code.
Ralph Loop's Counter-Intuitive Insight: Context as Resource
The Ralph loop's core innovation isn't memory, but opening a brand-new context window every turn. The reason is that LLM quality degrades as context fills up—after roughly 100–150K tokens, quality measurably drops, which is called context rot. Mainstream loops fight forgetting by "persisting memory to disk"; Ralph instead fights rot by "resetting context every turn, reloading only from on-disk PROMPT.md/AGENTS.md + git history." The two strategies are two sides of one coin: external memory solves "it forgets"; fresh context solves "remembering too much makes it rot"—a good loop needs both.
There's a subtle but critical primitive distinction: /loop reruns on a schedule; /goal keeps running until a verifiable condition actually holds—and after each turn, a separate small model judges whether it's done. The agent writing code isn't the same one grading it. The same primitive is being implemented by both Codex and Claude Code; this is almost the paradigm缩影 of the entire thing.
A Loop's Five Components,
Plus One Memory
Osmani breaks a running loop into five basic elements + one external memory, and both Codex and Claude Code have nearly identically-named implementations:
| Element | Responsibility |
|---|---|
| Automations | Discover + triage on schedule; the heartbeat that makes a loop a "loop" rather than "ran once"—and an automation can directly invoke a skill |
| Worktrees | Isolate parallel agents (git worktree) |
| Skills | Write project knowledge into SKILL.md, so the agent doesn't have to guess every time |
| Plugins / Connectors | Connect the agent into tools you already use, via MCP |
| Sub-agents | One generates ideas, another checks them—maker/checker separation |
| State (Memory) | Markdown or written via connectors into Linear—the agent forgets, the repo doesn't |
A positive template: Osmani's own repeatedly-used "morning triage loop"—an automation runs on the repo every morning, reads CI failures, unclosed issues, recent commits, writes findings into a state file; for each finding worth acting on, opens an isolated worktree, dispatches a sub-agent to draft a fix, then dispatches a second sub-agent to review; the connector opens a PR automatically, and anything it can't handle drops into the inbox for a human. The state file is the spine of the whole thing—it lets tomorrow morning's run pick up where today stopped, and you only designed it once, without prompting any single step.
"Two people could build identical loops and get completely opposite results. One uses it to run faster on work they deeply understand; the other uses it to escape understanding that work. The loop can't tell the difference—you can."
Addy Osmani · "Loop Engineering"Making the Loop Actually Work,
Rather Than "Expensive Infinite Retry"
The community's discussion crystallized the watershed between "a loop that works" and "burning-money idle spinning" into four criteria:
| Element | Key Point | Antipattern |
|---|---|---|
| Verifiable exit conditions | Tests pass, diff < N lines, eval score exceeds threshold—the system can judge without a human | "Does it look okay?"—that's not a check, that's a chat |
| Cheap checks | Run deterministic checks first (compile, lint, unit tests); AI-as-judge only for what they can't cover | Using a frontier model as judge, paying flagship prices every turn |
| Hard circuit breakers | Max rounds, max tokens, max wall-clock time—every loop needs a ceiling | The worst loop isn't a failed one; it's one that ran for 6 hours burning $40 with nobody noticing |
| Human gates at the right level | Humans stand at both ends: "define specs" and "accept results" | Humans diving into every turn to manually nod approval |
fashn.ai co-founder Dan Bochman used a conversation retweeted thousands of times to precisely depict the opposite of this line: explain the task to Claude (5 min) → Claude implements (10 min) → "Why is this step necessary?" → "You're right! I over-engineered it!" → repeat ×87 times, consuming 13 hours. This isn't a failure of loop engineering; it's precisely its absence—the "check" here is "does the human think it's reasonable," which isn't a check, it's a conversation. A real loop has programmable criteria; humans only come in after the criteria are satisfied.
The Most Dangerous Antipattern:
loopmaxxing
The rapid popularization of loops isn't without cost. The biggest trap is called loopmaxxing—the same illusion as the earlier tokenmaxxing: believing that if you just let the agent run in an infinite loop, it will eventually produce the correct answer. It inevitably fails in three places:
- Subjective / unquantifiable goals—"improve the experience of this login page" has no binary criterion; the model can't compute a stopping point; the loop runs infinitely, turning cloud budgets into astronomical bills
- Local optima—even in deterministic environments like software engineering, unsupervised loops get stuck. Karpathy admits that in autoresearch, agents "get timid" on open-ended hard problems, nudging the learning rate by a few tenths of a percentage point for nominal improvement
- Comprehension debt—when the loop generates hundreds of lines of code faster than the team can review, developers inherit a codebase where "all design decisions are blank"
An academic yardstick confirms this boundary's real existence: the early-2026 SWE-EVO benchmark (arXiv 2512.18470) doesn't test "fix one bug" like SWE-Bench; instead, it constructs 48 "software evolution" tasks from 7 mature projects, averaging 21 files changed and 874 tests for verification—exactly the kind of work loops are meant to chew on. The same tier of models scores 72.8% best on SWE-Bench Verified, but drops to only 25% on SWE-EVO long-horizon evolution tasks. This doesn't negate loop engineering—it's precisely why it exists—but it also reminds us: don't mistake "can run for a long time" for "can do the right thing for a long time."
Total TypeScript author Matt Pocock raised a precise objection against one specific variant—the self-improvement loop: auto-generated memory, CLAUDE.md suggestions automatically applied after each session. His concern is that a bad suggestion in a self-improvement loop doesn't just produce one bad reply—it gets written into the agent's permanent context, polluting every subsequent reply, the loop amplifies errors and compounds harm. The practical implication is clear: loops are for task verification, not unsupervised self-rewriting; any instruction written by an agent must be human-reviewed before becoming persistent context.
Synthesis
Osmani's summary is worth remembering: intelligence isn't in the loop's idle spinning, but in the quality of triggers, the precision of goals, the design of verification steps. The four-stage progressive method provides a safe path for production environments—first observe with humans in the loop, then introduce deterministic exits, add stagnation circuit breakers, and finally distill predictable actions into deterministic scripts in the main harness. One-sentence principle: LLMs can do many things, but they may not be the most reliable tool for every one; adding deterministic code and human oversight where agents will fail lets you capture the loop's benefits while avoiding its pitfalls.
From Code Loops
to Company Loops
Can a company's operation also be described as a giant, layered loop? Management cybernetics' decades-old tradition already answered this—Stafford Beer's viable system model, Deming's PDCA cycle, Boyd's OODA loop, Argyris & Schön's double-loop learning are structurally isomorphic to what Loop Engineering gives software, except the executors are shifting from humans to agents. Strategy loops (year/quarter: vision → strategy → results → review), operations loops (month/week), team loops (day/hour: ticket → PR → review → merge), individual loops (minute-level, exactly the layer agents are now starting to run for you)—layered by cadence, each layer is a complete loop.
What's more interesting is that failure modes also map one-to-one, and management theory already named them: loopmaxxing corresponds to "projects with no clear metrics letting teams burn indefinitely"; local optima corresponds to "incrementalism,不敢做架构级重组不敢做架构级重组"; reward hacking corresponds to the classic Goodhart's law (when a measure becomes a target, it ceases to be a good measure); comprehension debt corresponds to management no longer understanding what the frontline actually does.
But this analogy has one critical fracture that must be maintained: the company's "agents" are humans, with their own goals, emotions, and politics, not clean reward maximizers; the company's objective function itself is contested, unlike autoresearch which has a nailed-down verification metric; the most important outputs (brand, trust, culture) have no compact exit condition, and forcing them into KPIs is precisely the biggest trap. So the conclusion is: the so-called "self-evolving company" is essentially designing the company explicitly as an engineered set of loops—handing loops with verifiable exit conditions to agents, leaving those without to humans. Steinberger's line "you still need a BRAIN as the master model" holds equally at the company level: that BRAIN is judgment, and the interrogation of the goals themselves—no number of loop layers can replace the human's position.
Build Your Loop,
but Like an Engineer
Loop Engineering formalizes one fact: large language models are a component within larger software systems, not standalone applications. An autonomous agent's efficiency is entirely determined by the deterministic constraints, test harnesses, and execution guardrails designed by engineers—no number of loop turns can rescue an unclear goal or an unprincipled architecture. As writing code itself trends toward free, as empirical measurements prove humans should stand at both ends of "what to do + verify what was done," the developer's core responsibility is no longer finding that perfect string of adjective prompts, but building the verification system that keeps autonomous loops converging toward verifiable endpoints.
The three variables worth tracking next: whether primitives like /loop /goal will become a de facto cross-tool standard; when the first public major billing incident caused by loopmaxxing will appear; whether enterprise selection will shift from "which model is stronger" to "whose loop primitives + guardrails + observability are more mature."