Stop Prompting. Start Looping: The Quiet Shift Reshaping AI Work

1. Stop Prompting. Start Looping: A Field Guide to Loop Engineering

The shift nobody announced — and then everybody did

For about two years, getting useful work out of a coding agent meant one thing: write a good prompt, hand it enough context, read what came back, type the next thing. You were holding the tool the entire time, one turn after another.

Then, in the second week of June 2026, a single reframing tore through the agent community and gave a name to something experienced builders had quietly been doing for months: stop prompting your agent, and start designing the loop that prompts it for you.

The phrase that stuck was loop engineering. The post that kicked it off reportedly crossed ~6.5 million views in days. Within 48 hours it had a vocabulary, an anatomy, and a fight on Twitter about whether it was the future of software or just expensive hype. This is a field guide to what it actually means — and how to build a loop without quietly setting fire to your token budget.

What loop engineering actually is

Loop engineering is the practice of designing the system that prompts, checks, remembers, and re-runs an AI agent — instead of you typing every next instruction by hand.

The key move is that the unit of work changes. It’s no longer a single prompt, or even a single conversation. It’s a loop: a repeating cycle in which the model takes an action, gets real feedback from its environment, uses that feedback to decide the next move, and keeps going until a defined stopping condition is met.

You stop being the person in the chat box and become the person who builds the machine that runs the chat box. You define a recursive goal — “make the auth tests pass,” “triage every open issue and draft fixes,” “refactor this module and keep all behaviour identical” — and the agent iterates against that goal until it’s genuinely done.

Stripped to its essentials, an agent loop looks less like a chat and more like a thermostat or a REPL:

state = init_state(goal)                  # the recursive goal + scratchpad

for step in range(MAX_STEPS):             # hard cap — never loop forever
    thought = model.reason(state)         # reason about what to do next
    action  = model.choose_action(state)  # ...then pick a tool call
    result  = tools.execute(action)       # touch the real environment
    state   = update(state, thought, action, result)
    state   = compact(state)              # keep context under budget

    if verifier.passes(state):            # deterministic check = the reward signal
        return success(state)
    if no_progress(state) or budget.exhausted():
        return escalate_to_human(state)   # stop circling a dead end

    return escalate_to_human(state)       # ran out of steps → hand back

Almost everything interesting in this discipline is a decision about one of those lines: what counts as verifier.passes, how compact stops the context window overflowing, how you detect no_progress, and which tools the agent is even allowed to touch. The model is a fixed black box in the middle. The engineering is the loop around it.

Where it came from: three people, two days

The term crystallised around a small group of practitioners in early-to-mid June 2026.

Peter Steinberger — the developer behind the OpenClaw agent project — argued the relevant skill was no longer prompting coding agents, but designing the loops that prompt them. Boris Cherny, who leads Claude Code at Anthropic, put it even more bluntly: “I don’t prompt Claude anymore.” His job now, he said, is to write the loops that prompt Claude and decide what to do next.

Then Addy Osmani — a software engineer at Google — published an essay simply titled Loop Engineering that turned a viral take into something you could build on. It gave the practice a name and, more usefully, an anatomy.

Why now? Because the underlying agents finally got good enough. By mid-2026, a single agent run could last an hour, touch dozens of files, and recover from its own mistakes well enough that the bottleneck moved. When the model can reliably write the code, the scarce skill is no longer authorship — it’s orchestration.

The ladder: prompt → context → harness → loop

Loop engineering didn’t appear from nowhere. It’s the fourth rung on a ladder that keeps climbing outward — from the words you type, to the information the model sees, to the environment it runs in, to the cycle that drives it. Each rung wraps the previous one instead of replacing it.

You still write prompts. You still curate context. You still build a harness. Loop engineering is simply the layer where all of it gets put in motion — and the intellectual ancestor is the ReAct pattern (reason, then act, then observe the result before the next step), which has been quietly powering agents since 2022.

The anatomy of a loop: five pieces and a memory

Osmani’s most useful contribution was breaking the loop into composable primitives — and noticing that they now ship inside the products (Claude Code, the Codex app) rather than living in a pile of bash you maintain forever. Five building blocks, plus one place to remember things:

1. ⏰ Automations — the heartbeat. A scheduled or event-triggered run that does discovery and triage by itself. This is what makes a loop an actual loop and not just one run you did once.
2. 🌳 Worktrees — isolation. A separate working directory per agent so two of them working in parallel can’t overwrite each other’s files. Same headache as two engineers committing to the same lines; same fix.
3. 📚 Skills — written-down project knowledge (SKILL.md). Without them, the loop re-derives your whole project from zero every cycle. With them, intent stops costing you over and over and the loop compounds.
4. 🔌 Plugins & connectors — reach. Built on MCP, these let the loop touch the tools you already use: the issue tracker, the database, the staging API, Slack. The difference between an agent that says “here’s the fix” and a loop that opens the PR, links the ticket, and pings the channel once CI is green.
5. 🤝 Sub-agents — the maker/checker split. One agent has the idea; a different one checks it. The model that wrote the code is far too generous grading its own homework.

And the sixth thing — 🧠 external state. A markdown file, a Linear board, anything that lives outside the single conversation and holds what’s done and what’s next. The model forgets everything between runs, so the memory has to be on disk, not in the context window. The agent forgets; the repo doesn’t.

A real loop snaps these together: an automation runs each morning, calls a triage skill that reads yesterday’s CI failures and open issues, writes findings to a state file, spins up an isolated worktree per task, sends one sub-agent to draft the fix and another to review it against the project’s skills and tests, then uses connectors to open the PR and update the ticket. Anything it can’t handle lands in your inbox. You designed it once. You prompted none of those steps.

Pick a pattern, don’t reinvent it

Loop engineering productised a line of research that’s been accumulating for years. Knowing the patterns saves you from rebuilding them badly:

• ReAct (Yao et al., 2022) — the base loop: reason, act, observe, repeat. Every modern loop is a descendant.
• Reflexion (Shinn et al., 2023) — adds memory and self-critique. After a failed attempt the agent writes a verbal lesson (“the patch failed because the import was wrong”) into a memory buffer that later attempts read back, so it gets better within a single session with no retraining.
• Plan-and-Execute — separate the planner that decomposes the goal from the executor that runs the steps. Reduces drift on long, multi-stage tasks.
• Evaluator-Optimizer (from Anthropic’s “Building Effective Agents”) — one model generates, a second grades against criteria, and they cycle until it passes. Shines when acceptance criteria are clear and articulable.
• Orchestrator-Workers — a central orchestrator splits a task into subtasks, hands each to a worker sub-agent with its own fresh context window, and synthesises the results. This is how overnight agent fleets get built.

The consistent advice from people running these in production: prefer the simplest pattern that works, and compose patterns rather than reaching for a heavy framework. A single ReAct loop with a deterministic verifier beats an elaborate multi-agent system you can’t debug.

The three hard parts (this is the actual curriculum)

If loop engineering has a syllabus, it’s these three. Get them right and a loop runs unattended for an hour. Get them wrong and it overflows, spins, or lies.

🧩 Context management. The context window is the agent’s working memory, and it has a hard limit. Every step appends thoughts, tool output, and errors — so the window fills and the model starts to suffer context rot, attending less reliably to what matters. The countermeasures are pure context engineering operating inside the loop: compact old steps into summaries, prune stale tool output, externalise state to files, and isolate sub-agents so a subtask runs in a clean window and returns only its conclusion.

🛑 Termination & no-progress detection. The signature bug of a naive loop is that it never stops. Robust loops carry several independent exits: a verifier that confirms success, a hard iteration cap, a token/time budget, and — the subtle one — no-progress detection. If the last few steps produced the same error or left the state unchanged, break and escalate rather than burn budget circling a dead end. Termination isn’t an afterthought; it’s half the design.

✅ Verification as the reward signal. A loop is only as good as the feedback it acts on, so that feedback has to be trustworthy. The gold standard is deterministic verification — tests, type checkers, compilers, linters — because they return an objective pass/fail the model can’t argue its way around. LLM-as-judge grading is more flexible and sometimes necessary, but it can be gamed or collude with the maker. Put a deterministic check in the cycle wherever one exists; reserve model judgment for the genuinely unquantifiable.

The failure modes to design against

The honest caveat: you might not need this yet

Loop engineering is having its moment, and hype outran reality in the first weeks. A widely shared rebuttal made the point that most developers don’t need agent loops yet — for a one-off task, an interactive session with a capable agent is usually faster and safer than engineering a full loop.

And a loop doesn’t remove you from the loop. You still own the goal, the definition of “done,” and the judgment about whether the output is actually correct. A loop that optimises a badly specified objective will pursue the wrong thing with great efficiency. Without genuine verification, a fast loop just produces wrong answers faster. Two people can build the identical 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 doesn’t know the difference. You do.

Build the loop. Stay the engineer.

The leverage point in AI work has moved again — from the prompt, to the context, to the harness, and now to the loop. That’s not a fad replacing the last one; it’s a new rung on a ladder you’ve been climbing the whole time.

Loop engineering is genuinely harder than prompt engineering, not easier — because designing a cycle that ships reliable work without quietly accumulating risk takes real systems thinking: a verifier you trust, sensible cadence and cost controls, and memory that lives on disk.

So go build a loop. Start small — one validation loop on a task with a checkable success condition (a failing test is a great first goal). Add worktrees and sub-agents later. Keep a real check inside every cycle. And build it like someone who intends to stay the engineer — not just the person who presses go.

👉 Your move

Pick one repetitive, verifiable task you do by hand every week. Write down its goal, its tools, and its stopping condition. That’s a loop spec. Build that one — then tell me what broke first.

Appendix: sources & further reading

• Addy Osmani — Loop Engineering (the essay that named and structured the concept) — addyosmani.com/blog/loop-engineering
• Peter Steinberger — on designing loops instead of prompting agents (OpenClaw project)
• Boris Cherny (Anthropic, Claude Code) — “I don’t prompt Claude anymore”
• Anthropic — Building Effective Agents (evaluator-optimizer, orchestrator-workers patterns), Dec 2024
• Anthropic — Effective context engineering for AI agents, Sept 2025
• Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models, 2022 (arXiv:2210.03629)
• Shinn et al. — Reflexion: Language Agents with Verbal Reinforcement Learning, 2023 (arXiv:2303.11366)
• AlphaSignal — Most Developers Do Not Need Agent Loops Yet (the counterpoint)

SEO notes — primary keyword: “loop engineering”. Suggested meta description (152 chars): “Loop engineering is designing the system that prompts, checks, and re-runs an AI agent for you. The anatomy, patterns, and pitfalls of the 2026 shift.”