Watch yourself work with a coding agent for an hour. You type a request. You wait. You read what comes back. You decide whether it’s right. You type the next thing. And between every one of those steps, the agent sits idle — waiting on the slowest, most expensive component in the whole system: you, reading and deciding and pressing go.
For two years that was the deal, and it was a good deal. The model needed a human to aim it one turn at a time. The quietly radical claim now going around is that it doesn’t — not for every step, not anymore.
Boris Cherny, who runs Claude Code at Anthropic, put it about as plainly as it can be put: he doesn’t prompt Claude anymore. He has loops running that prompt Claude and figure out what to do next, and his job is to write the loops. Peter Steinberger, building in the same world, said the same thing from the other direction — stop prompting your coding agents, and start designing the loops that prompt them for you.
It’s a strange sentence the first time you read it. So let’s take it apart. Fair warning up front: this is early, the best practices are still being invented, and there are real reasons to be skeptical — cost being the loudest one. I’ll get to all of that. But the shape underneath is worth understanding now, because it’s probably where the work is heading.
You were the loop
Here’s the reframe that makes the quotes click. In the old rhythm — prompt, read, correct, prompt again — you were the loop. The agent was a tool you held the entire time, and every cycle ran through your hands. Find the next thing to do, hand it to the agent, check what came back, decide what’s next. You were doing four jobs and calling one of them “using AI.”
Loop engineering is the practice of building a small system that does those jobs instead of you. It finds the work, hands it out, checks the result, writes down what’s done, and decides the next move — and then it pokes the agents, so you don’t have to. A prompt is an instruction for one turn. A loop is a standing job: you define what “done” actually means, and the system grinds toward it on its own, run after run, until the condition you wrote comes true.
If you’ve read our piece on the software factory, this lives one floor below it. The factory is the whole circle — a signal from the outside world becoming shipped, monitored software with the machine handling the legwork. A loop is the engine that turns that circle. Think of it as the agent’s workspace with a clock bolted to the wall, a to-do list it writes for itself, and a door it can send helpers through. Same room as before. Now it runs on its own time.
What a loop is made of
The genuinely new thing isn’t the idea — people have been hand-wiring loops out of shell scripts for years. It’s that the pieces now ship inside the products. You used to maintain a pile of bash forever; now the same capabilities are features you switch on. There are six of them, and a loop holds together or quietly leaks depending on whether you have all six.
Automations are the heartbeat. This is what makes a loop a loop and not a thing you ran once. In Claude Code you have a few ways to set the rhythm: /loop re-runs a prompt on a timer inside your session; /goal keeps working across turns until a condition you wrote is genuinely true; hooks fire shell commands at points in the agent’s lifecycle; and /schedule (or a cron task, or CI) keeps the whole thing running after you’ve shut the laptop. The one closest to the heart of this is /goal — you hand it something like “every test in test/auth passes and the linter is clean,” walk away, and it works until that holds. Picking between an in-session timer and a calendar job is its own small decision, which we untangle in scheduled agent vs /loop.
Worktrees keep parallel from turning into chaos. The moment you run more than one agent, files start colliding — and two agents writing the same file is the exact headache as two engineers committing to the same lines without talking first. A git worktree solves it cleanly: each agent gets its own working directory on its own branch, sharing the repo’s history but never touching the others’ checkout. Claude Code gives you this through the --worktree flag to open a session in its own checkout and an isolation: worktree setting you hang on a subagent so each helper works in a fresh copy that cleans itself up afterward.
Skills are project knowledge written down once. A skill is a folder with a SKILL.md inside it — your conventions, your build steps, the “we don’t do it that way because of the incident last spring.” Without it, the loop re-derives your entire project from zero on every cycle, filling each gap in its understanding with a confident guess. With it, the knowledge compounds: written one time, read every run. A loop without skills is a new hire who forgets everything overnight, every night.
Plugins and connectors give the loop hands. A loop that can only see your filesystem is a small loop. Connectors — built on MCP, the open standard we cover in how to use MCP with Claude Code — let the agent read your issue tracker, query a database, hit a staging API, or drop a message in Slack. This is the difference between an agent that says “here’s the fix” and a loop that opens the pull request, links the ticket, and pings the channel once the tests go green, by itself.
Subagents keep the maker away from the checker. This is the most load-bearing structural move in the whole design, and it’s easy to skip. The model that just wrote the code is a soft grader of its own work — it’ll talk itself into calling it done. A second agent, with different instructions and sometimes a different model entirely, catches what the first one rationalized past. The reliable split is one agent that explores, one that implements, and one that verifies against the spec. You define them as files in .claude/agents/, and it’s exactly what /goal is doing under the hood: a fresh model, not the one that did the work, decides whether the loop is finished. (When a job needs a whole fleet of these spun up on the fly, that’s a dynamic workflow — a loop can call one as a single step.)
Memory is the spine. The model wakes up with amnesia every run — it remembers nothing between conversations. So the memory has to live on disk, not in the context: a markdown file, a tracker board, anything outside the single session that holds what got tried, what passed, and what’s still open. It sounds far too dull to be the thing the whole design rests on. It is exactly the thing the whole design rests on. The model forgets; the file remembers; tomorrow’s run picks up precisely where today’s stopped.
What one loop actually looks like
Wire those six together and a single thread becomes a small control panel. Here’s a shape worth stealing.
An automation runs every morning against your repo. Its prompt calls a triage skill that reads last night’s failed tests, the open issues, and the recent commits, then writes its findings into a markdown file. For each finding worth acting on, the loop opens an isolated worktree and sends one subagent to draft the fix — and a second subagent to review that draft against the project’s skills and existing tests. A connector opens the pull request and updates the ticket. Anything the loop can’t safely handle lands in an inbox for you. The state file is the spine: it remembers what was tried, what passed, what’s still open, so tomorrow morning the run resumes instead of restarting.
Now notice what you did there. You designed that once. You prompted none of those steps — not the triage, not the draft, not the review, not the pull request. That’s the whole claim made concrete. And it’s deliberately described in tool-neutral terms, because the pieces are the same pieces wherever you build it; the loop is the design, not the brand.
Open the loop slowly
Not all loops are equal, and the distinction is the practical heart of doing this without regret.
A closed loop is one where you drew the path first. Clear goal, defined steps, a check at each step, and a point where it stops or hands back to you. The agents still loop, but inside a frame you built — so it gets better every run because each pass feeds the next, and it stays affordable because the path is tight. An open loop is the exciting end: you hand the agent a goal and let it roam, discovering its own route, building things you never fully specified. That’s powerful, and it’s roughly what the people at the frontier are doing. It’s also where the bill gets frightening, and where — pointed at work with loose standards — it turns into a fast, expensive slop machine.
Which brings up the catch nobody puts on the brochure: loops burn tokens, and they burn them in a way that depends entirely on whether you’re token-rich or token-poor. Every retry costs. Every subagent costs. Every verification pass costs. A medium task can run through tens of thousands of tokens; a fleet of specialists, far more; a daily schedule, that much again every week. If you have effectively unlimited budget, none of this registers and you can let loops roam. If you don’t, an open loop will hollow out your month in days. The discipline is the same one we lean on for dynamic workflows: bound the scope, set a token ceiling right in the prompt, and earn the open loop by mastering the closed one first. Start closed. Open up only once the quality gates are real.
Build the loop, stay the engineer
Here’s the counterweight, and it’s the whole reason this is harder than prompting rather than easier. A loop changes the work; it doesn’t delete you from it. Three problems actually get sharper as the loop gets smoother.
Verification is still yours. A loop running unattended is also a loop making mistakes unattended — and “done,” as declared by a model, is a claim, not a proof. The reason you split the verifier from the maker is to make that claim mean something, and even then your job is to ship code you confirmed works. This is the leverage point we argue is now the most valuable skill in software, in writing got cheap, understanding didn’t: when the machine produces faster than you can read, attention is the scarce resource, and you spend it where being wrong actually hurts.
Your understanding rots if you let it. The faster a loop ships code you didn’t write, the wider the gap between what exists and what you actually grasp — and a smooth loop just grows that gap faster, unless you read what it made.
And the comfortable posture is the dangerous one. When the loop runs itself, it’s tempting to stop having an opinion and take whatever comes back. The unsettling truth is that 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 can’t tell the difference. You can.
So go ahead and build loops — but build them like someone who intends to stay the engineer, not just the person who presses go. Cherny’s point was never that the work got easier. It’s that the leverage moved: from writing the perfect instruction to designing the system that produces a verified outcome on its own. If you want to feel it this week, take one prompt you find yourself typing over and over, give it a clear stop condition, add a single verifier subagent and a memory file, and let it run closed. That’s a loop. It’s a smaller thing than the quotes make it sound — and a bigger shift in your job than it first appears.