A claim has been making the rounds in AI coding circles: stop prompting your coding agents and start designing loops that prompt them for you. Like most things, it gets repeated far more than it gets explained. This is the practical version — what an agent loop is, why it matters, and what one actually looks like in production.

Table Of Contents

• Where the claim comes from
• What a loop actually is
• “Loop” means at least five things
• The parts you actually assemble
• A concrete loop: the PR babysitter
• A concrete Claude Code loop with /goal
• Running many loops unattended
• crabfleet: orchestration as a product
• Where the cost goes now
• When not to loop
• What can go wrong
• How to build your own

Where the claim comes from

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

— Peter Steinberger

Boris Cherny, the creator of Claude Code, makes the same point from the other side:

“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”

— Boris Cherny

This is not an argument that prompt engineering is dead. With loop engineering, the work moves up a level — from writing code to writing the system that writes the code. Developers furthest along this path report months where they shipped hundreds of PRs without opening an IDE, every line written by the agent.

What a loop actually is

A loop is a small program that does four things:

1. Prompts the coding agent for you
2. Reads what it produced
3. Decides whether it is done
4. If not, prompts it again with the error or the next step

You stop sitting inside the loop typing prompts. You write the loop, and the model becomes a subroutine it calls.

The shape is always the same: set a goal, act, check, feed the error back, and repeat until the check passes or the loop stops itself.

“Loop” means at least five things

Much of the disagreement is people using one word for five different ideas. Oldest to newest:

• ReAct (2022). The original research pattern: reason, act, observe, repeat.
• AutoGPT (2023). A self-prompting goal loop, notorious for not knowing when to stop.
• ralph loop. A deliberate context reset between iterations so the agent does not drown in its own history.
• /loop and /goal. Cadence and completion conditions are built into the agent, carrying state across turns.
• Orchestration. One author fans out many agents that read your GitHub, Slack, and chat, and decide what to build next.

The parts you actually assemble

The same six parts show up in every loop. Most now ship inside the coding tools themselves, rather than custom scripting you maintain separately.

A trigger is what starts the loop without you pressing go — a schedule, a webhook, a file change, a label landing on a PR. This is what separates a real loop from a single run you repeat by hand.

Isolation means a private checkout per agent, usually a git worktree, so two agents running at once cannot overwrite each other’s files. Once you run more than one, this stops being optional.

Written-down context is where you put the conventions, build steps, and project-specific rules — somewhere the agent reads them on every run. Skip it, and the loop re-derives your project from scratch each pass and guesses at the gaps.

Tool connectors let the loop open the PR, link the ticket, and post the result instead of printing a fix and waiting for you to carry it the rest of the way.

A second agent checks. Keep a separate worker that grades the output away from the one who produced it. A model reviewing its own work passes almost everything.

State on disk is a markdown file, a board, or a queue — anything outside the conversation that records what is finished and what is next. The model forgets between runs; the file does not.

Put those together and you have a working loop. You used to hand-build all of it; now most ships as built-in features, which is why the pattern has moved from fringe technique into common practice.

A concrete loop: the PR babysitter

One you can build today:

• Trigger. Every 15 minutes.
• Scope. Open PRs labeled agent-watch.
• Action. If CI is red for a deterministic reason, attempt one fix. If main has moved, rebase once.
• Budget. One fix attempt per PR, five minutes, ten files changed.
• Stop condition. CI green, or budget exhausted — stop and ping a human.

You come back to merged PRs instead of a backlog of broken builds. The same shape covers most ops work:

• CI health. Every 30 minutes, pull failing runs and cluster them by signature, so ten red PRs with one root cause become one thing to deal with.
• Deploy verification. After a push, hit your endpoints, confirm 200s and expected content, flag regressions before users do.
• Feedback clustering. Every 30 minutes, pull comments from your channels, group into themes, map each cluster to the file or doc that owns it.

A concrete Claude Code loop with /goal

The babysitter is a loop you wire up yourself. It also helps to see one that ships inside the agent. In Claude Code, the smallest complete loop is /goal: hand it a verifiable end state, and it keeps taking turns until that state is true.

$ claude                             # launch Claude Code
$ /goal tests in test/auth pass      # set the goal inside the session

Same act–check–repeat shape, with the verifier built in.

A strong /goal reads less like a prompt and more like a contract. The good ones specify four things: the end state you want, the evidence that proves you reached it, the constraints the agent must not break getting there, and the budget of work it is allowed to spend. Leave any one of those vague, and the model fills the gap with the easiest reading — stops early, takes a shortcut, or redefines success so the transcript looks done while the actual system is still broken.

How a /goal run flows:

1. Set the condition. Type /goal plus a checkable end state, for example /goal tests in test/auth pass. The first turn starts immediately.
2. The agent works a turn. It edits, runs the tests, surfaces the results.
3. An evaluator checks. A fast model reads the transcript and decides met or not met, so the agent is not grading its own work.
4. Loop or finish. Not met means another turn with guidance; met means the goal clears and the run stops.

State carries across turns, so it does not quit early or drop a constraint partway through. A few things keep it reliable:

• Make the check measurable. A test result, an exit code, a file count, an empty queue. npm test exits 0 is a goal; “make it better” is not.
• Bound the run. Append something like “or stop after 20 turns” so a stuck loop halts instead of burning indefinitely.
• Pair it with auto mode so turns run unattended, and use /goal clear to abandon it early.

The evaluator step hides something worth pausing on: the checker does not have to be the same model as the coder. Once the loop has distinct roles — planner, executor, evaluator, vision reviewer — each can run on a different model. Choosing which model fills which role becomes an architecture decision rather than a single bet on one “best” coding agent. Some models plan better, some execute more cheaply, some are better at reading a screenshot. A good orchestrator lets you swap them per role instead of waiting for one vendor to win every category.

/goal works well for API migrations (move every call site until it compiles and tests pass), refactors (split a file until each module is under budget), issue backlogs (work a labeled queue until empty), and eval loops (tune a prompt until the score clears a threshold). /loop is the counterpart for work with no single finish line — instead of a completion condition it re-prompts on a schedule, which is how a loop like the PR babysitter keeps running.

Running many loops unattended

A single /goal loop is one agent working toward one finish line. Running many unattended processes raises the stakes, because a loop is only as trustworthy as its ability to check its own work. Cherny’s setup for running Opus autonomously for hours comes down to five things:

1. Auto-approve permissions so the agent does not stop to ask on every tool call.
2. Use dynamic workflows (drop Ultracode into the prompt) to fan out across many agents instead of one serial thread.
3. Use /goal or /loop to keep it going — /goal sets a completion condition, /loop re-prompts on a schedule, and both carry state.
4. Run it in the cloud (desktop or mobile app) so the session survives when you close the laptop.
5. Give it a way to self-verify end-to-end. Claude in Chrome for web, a simulator MCP for mobile, a live server for backend. This is the step that makes the other four safe.

The full sequence:

claude --permission-mode auto                           # 1 · no approval prompts
ultracode  orchestrate sub-agents to ship the feature   # 2 · fan out
/goal all tests pass and the demo loads clean           # 3 · keep going
→ cloud / desktop app                                   # 4 · close the laptop
→ chrome ext · sim MCP · live server                    # 5 · self-verify, then halt

crabfleet: orchestration as a product

Orchestration is easier to picture with a concrete tool. Peter Steinberger’s crabfleet, an OpenClaw project billed as “mission control for agent runs,” is a loop packaged as a product — its shape maps onto everything above.

Tasks are cards on a board, built from a prompt, a GitHub issue, or a PR, moving through todo, running, human review, and done. That board is the loop’s queue and stop-and-report step, made visible.

Each run is tracked with heartbeats, so it keeps going when you look away and survives a closed laptop. You take over only when the runtime signals it supports handoff. A run can start child sessions, send messages, read transcripts, and update its own summary from inside a sandbox — on-disk memory and fan-out in one place.

It runs on disposable cloud sandboxes with browser-based terminals, which is what makes walking away from an unattended run safe. The point is not crabfleet specifically but that the loop has hardened into infrastructure: a queue, durable execution, fan-out, and a human-review gate are now things you configure rather than hand-script every time.

Where the cost goes now

For two years, the cost question in AI coding was: which model, and how many tokens. Inside a loop, that instinct points at the wrong layer. The spend is no longer a single call — it is how many times the loop goes around. A loop that retries six times before converging costs six times as much as one that lands on the first pass, on the same model.

Iterations are the budget line, not tokens. A cheaper model that loops twice as often is not cheaper. Track cost per finished task, not cost per call.

A weak verifier is the most expensive bug you can ship. If the check that decides “done” is loose, the loop either stops early on broken work or grinds on work that was already fine — both waste whole iterations. Tighten this before anything else.

Failing fast is also a cost control. A loop with no cap on consecutive failures does not eventually succeed; it eventually drains the account. The stop condition protects the bill as much as the codebase.

You used to tune the prompt. Now you tune the loop, because that is where the cost accumulates.

When not to loop

Loops pay off when a task repeats and a machine can tell when it is done. Outside that, a loop only automates churn.

One-shot edits do not need one. If you can finish it in a single pass, a loop is pure overhead.

Unscoped or exploratory work has no pass condition, so the loop never converges. “Figure out why users are churning” is not a loop-able goal.

Anything without a cheap automated check means you are still inside the loop yourself. Build the check first, or do the task by hand.

What can go wrong

A loop that runs while you sleep also makes mistakes while you sleep. The failure modes are not surprising.

The loop writes faster than you can review. If you stop reading the diffs, you have not removed the work — only deferred it. The verification burden does not go away; it gets bigger.

Shipping code you did not write, faster than you can absorb it, erodes your mental model of the system. That debt comes due during the next incident.

A weak verifier lets wrong-but-passing work through on every iteration. The loop looks productive while it digs a hole.

None of this is an argument against loops. It is why the engineer who designs the loop matters more, not less.

How to build your own

1. Pick one repeatable task. Babysitting PRs, fixing CI, verifying deploys — start with routine work.
2. Scope it tight. “Fix the billing webhook validation, only touch app/api/billing and lib/billing” beats “fix the bug.” A loose loop wanders.
3. Give it a budget and a stop condition. Max attempts, max runtime, max files, max spend, max consecutive failures. A loop running unattended is also a loop making mistakes unattended.
4. Add an independent verifier. A separate sub-agent grades the work, because the agent who wrote the code is the worst judge of whether it is done.
5. Run it on a cadence. /loop for an interval, cron for a schedule, hooks at lifecycle points, or GitHub Actions so it survives a closed laptop.
6. Keep memory on disk. The model forgets between runs, so state lives in markdown or a board, not in the context window.

The loop, not the model, is now the expensive and failure-prone part. Build it like someone who intends to stay responsible for the output — not just the person who started the run.