On June 2, Boris Cherny, who leads Claude Code at Anthropic, told an interviewer he no longer prompts Claude. "I have loops that are running," he said. "They're the ones that are prompting Claude and kind of figuring out what to do. My job is to write loops." (Acquired Unplugged with WorkOS, June 2, 2026.) Five days later Addy Osmani gave the practice a name, loop engineering, and by June 10 The New Stack was mapping its building blocks onto both Claude Code and Codex.
I have been writing loops for months, and here is what I learned the slow way. Once a person stops prompting and starts writing loops, the loop becomes infrastructure. It needs a machine that is not the founder's laptop, isolation for each run, a wake-up when the agent stops, and a record of what every iteration did. The model was never what broke. Those four things were.
Three stages, and who holds the work at each
Cherny described the change in three steps in the same interview. A year ago he wrote code by hand with autocomplete in an IDE. By November he had uninstalled the IDE because he had not opened it in a month, and he was running five to ten Claude sessions in parallel, prompting each one himself. Now loops do the prompting.
The middle stage was already enormous. In late December he posted that in the previous thirty days he had landed 259 pull requests, 497 commits, 40,000 lines added and 38,000 removed, and that every line was written by Claude Code with Opus 4.5 (quoted by Simon Willison, December 27, 2025).
Look at what the person was doing in stage two besides prompting. They kept the machine awake. They kept ten sessions from touching the same files. They noticed when a session went quiet and decided whether it had finished or given up. They remembered which session had tried what. None of that was written down anywhere, because the person was doing it with their eyes.
Stage three removes the person from the seat, and every one of those chores still needs an owner.
The laptop was the first thing to go
My first loops ran on my laptop, because that is where the terminal was. It lasted about as long as it takes to learn two lessons. Agent windows stole focus while I was typing in something else. A full test suite started by an agent froze the machine I was using to read its output. A loop and a person cannot share one computer for long: the person wants it quiet and responsive, and the loop wants every core.
So I moved the agents onto a few spare machines and took my own laptop out of the pool on purpose. It is the one place no agent is allowed to run. That sounds like housekeeping. It turned out to be the first piece of infrastructure, because the moment the loop lives somewhere else, you need a way to start work there, see it, and stop it without walking over.
Each iteration gets its own room
The second thing that broke was isolation. Two iterations of the same loop, or two loops pointed at one repository, will eventually edit the same file, install conflicting dependencies, or leave a half-finished branch for the next run to trip over. Osmani's list of loop primitives puts worktrees second, right after scheduled automations, so that parallel agents stay out of each other's way, and The New Stack's table shows both vendors shipping a worktree per thread or per subagent.
A worktree separates files. A loop that runs unattended also needs its processes, ports, credentials and network kept apart, because the iteration you are not watching is the one that runs rm in the wrong directory. The unit of isolation that matches a loop is the iteration: one fresh, disposable machine per run, thrown away or parked when the run ends, so a bad iteration cannot poison the next one.
Agents stop, and something has to notice
The third failure is the one nobody warns you about. Agents stop on their own. They end a turn, decide the job is done, or wait politely for an answer nobody is there to give. In stage two a person sees the idle window. In stage three the loop sits there until morning.
Two mechanisms carry most of my weight here. The first is a stop-hook: when an agent tries to end its session while its pull request is still open, the hook refuses and tells it what is left. The second is a timed wake-up that re-invokes the same session later, with its full context, to check on a team of agents it dispatched. Both vendors now ship a version of the first idea: a /goal command that keeps an agent working until a verifiable stopping condition holds, per The New Stack. The second still needs a scheduler that can reach a session after its process has exited.
The record is the part you read later
The last piece is the one you only miss afterward. A loop that runs while you sleep ships changes you did not watch being made. The New Stack's summary of Osmani's warning calls the result comprehension debt: the gap that widens when a system ships code you never read, and the same article notes that "a loop running unattended is also a loop making mistakes unattended."
When something goes wrong in iteration forty, a final diff tells you what changed. It does not tell you what the agent read, which command failed first, or why it chose the fix it chose. For that you need the trajectory: every prompt, tool call and result, kept per iteration, so you can open the one that went sideways and read it like a log. Memory files help the next run resume. The trajectory helps the person who owns the loop understand the last one.
The New Stack makes a useful distinction here: the scheduling layer of a loop is often plain cron, but "a cron job runs a fixed script, while a loop runs a model that reads the current state and chooses its next action." Cron could get away with a log line because the script was the same every night. A loop's iteration can do something new each time, so it needs to be kept apart while it runs and recorded in full afterward.
What changes when the loop is the unit
I wrote in April that agents make an organization's judgment loops executable: signal, plan, critique, implement, verify, ship. Loop engineering is that idea arriving at the level of one engineer's day. And as with every workflow shift, most of the value sits in the work around the model, the workflow bet from the three-bet era. BCG's 10/20/70 rule (October 19, 2020) puts numbers on it: AI is 10% algorithms, 20% technology and 70% business process transformation.
The questions change with it. In stage two you ask which model to prompt. In stage three you ask where the loop lives, what keeps one iteration away from the next, what happens when the agent goes quiet, and where you will read what it did.
Where Rush fits
This is the problem we build Rush for. A run is a request: an agent does the work in a cloud sandbox (a pod on our cluster) with its own git worktree and a headless browser, and the result comes back with proof, a PR with checks for code, plus the full trajectory of what the agent did. A follow-up continues the same run, so a loop can come back to where it left off instead of starting cold, and you can cancel while it works. A run that is missing its proof ends as needs_review. The laptop stays out of it.
Cherny's job is to write loops. Somebody's job is to give them a machine, a wall between iterations, an alarm when they stop, and a log you can read in the morning.
