What a Loop Actually Is: Boris Cherny’s Three-Stage Definition

Photo by Patrick Tomasso on Unsplash

Boris Cherny created Claude Code as a side project in September 2024. It now reportedly sits behind close to four percent of all public commits on GitHub. On stage at the Acquired Unplugged event hosted by WorkOS on June 2, 2026, he gave the clearest definition of a loop you will find anywhere in the discourse.

He described it as three stages that map to where most developers currently are in their relationship with AI coding tools.

A year ago, he wrote code by hand with autocomplete assistance. The model was a tool he directed line by line. Stage one.

Then he ran five to ten Claude sessions in parallel and prompted each one manually. He was still the human inside the process, initiating each interaction. Stage two.

Now he does not prompt at all. He writes the loops that prompt Claude, and a couple hundred agents read his GitHub, Slack, and Twitter and decide what to build next. Stage three.

His own words from the WorkOS event are the most precise description available. “Now it’s actually leveled up, I think, again, to the next wave of abstraction where 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.”

The plain version is this. A loop is a small program you write that prompts the coding agent on your behalf, reads what the agent produced, decides whether the task is complete, and if not, prompts the agent again with updated context. You stop being the entity inside the loop entering prompts. You become the author of the loop itself. The model becomes a subroutine called by your program rather than a tool you operate directly.

He has the receipt to back up the claim. In the last 30 days of December 2025, 100% of his contributions to Claude Code were written by Claude Code itself. He landed 259 pull requests. He deleted his IDE in November 2025 and has not opened it since.

The nuance the prompt-engineering-is-dead crowd consistently skips is that Cherny is not saying engineers are obsolete. He says explicitly that great engineers matter more than ever. Someone still has to decide what to build, talk to customers, coordinate teams, and determine what the loops should be trying to accomplish. The job did not vanish. It moved up an altitude, from writing the code to writing the thing that writes the code.

The Five-Stage Lineage That Nobody Is Explaining

The confusion in the discourse is partly because the word loop is being used to describe five meaningfully different things that evolved over five years. Placing yourself on the correct stage of this ladder is the fastest way to understand what Steinberger and Cherny are actually talking about versus what most people are describing when they use the same word.

Stage one is the academic while-loop formalized in the ReAct paper in 2022. The architecture was straightforward: the model reasons about a task, calls a tool, reads the result, and repeats until the task is complete. One model, one loop, a human watching and able to intervene. This established the basic pattern of thought plus action plus observation cycling until a stopping condition is met.

Stage two is AutoGPT in 2023, which took the ReAct loop and gave it a goal it could pursue autonomously, prompting itself without human intervention at each step. AutoGPT became famous for spinning indefinitely without meaningful progress, which seeded several years of the widespread belief that agents were toys rather than useful tools. The failure mode was real: without proper stopping conditions and feedback mechanisms, an autonomous loop generates confident activity that doesn’t converge on anything.

Stage three is the ralph loop, published by Geoffrey Huntley in July 2025. Ralph is almost insultingly simple: a bash one-liner that pipes the same prompt file into the coding agent repeatedly. Its real innovation was discipline rather than sophistication. Every iteration resets the conversation context to a fixed set of anchor files rather than letting the conversation history grow indefinitely, which keeps the model from drifting as the context window fills with previous exchanges. Huntley built an entire programming language using this approach for approximately $297. The reply in Van Horn’s research thread that described ralph as old hat was correct. It is old hat now. But it was genuinely important when it shipped.

Stage four productized stage three. In spring 2026, both OpenAI’s Codex and Anthropic’s Claude Code shipped a /goal command that runs the ralph loop pattern until a small validator model confirms the task is complete. This moved the basic loop from a bash script that practitioners built manually to a first-class feature in mainstream AI coding tools.

Stage five is what Steinberger and Cherny are actually describing, and it is genuinely different from the previous stages rather than just renamed. Four things changed simultaneously to create it.

The loop became the unit of work rather than the task being a single prompt session. Loops started supervising other loops, running concurrently and on a schedule rather than sequentially. Scheduling replaced the human kickoff, meaning loops run on infrastructure time rather than requiring a person to initiate them. And durability became explicit, with state stored in git and crash recovery built in, because production systems have to survive restarts and failures. The ralph loop assumed your terminal stayed open. The 2026 version assumes it does not.

That is the multi-agent continuous orchestration loop that a reply in the original thread described as the new thing while correctly calling the ralph loop old hat.

The Cron Job Objection and Why It Deserves a Straight Answer

The sharpest skeptic reply in the entire discourse was four words: “Cronjobs have funny re-branding rn.”

This objection deserves a direct answer rather than dismissal because it is half right.

Yes, the scheduling layer in a 2026 loop is cron. Boris Cherny literally runs his on cron. The /loop command in Claude Code uses cron under the hood. If your complete definition of a loop is a thing that runs on a timer, then cron has done that since 1975 and the naming change accomplishes nothing.

What cron never had is the decision logic in the middle. A cron job runs a fixed script. Every execution follows the same path regardless of the current state of the world. A loop runs a model that looks at the current state, decides what action to take based on that state, takes the action, checks whether the action worked, and decides whether to continue or halt. The decision at each step is the model’s, not a hardcoded branch in your script.

Stack multiple loops where one supervises others, give them durable shared state that persists across restarts, and you have something cron cannot express regardless of how long cron has existed.

The honest framing is that a loop is cron plus a decision-maker in the body, and all the interesting engineering is what you wrap around that decision-maker to prevent it from doing something catastrophic.

What Building One Actually Looks Like

The on-ramp is a single line. Claude Code shipped /loop and Cherny’s own example is the canonical starting point.

The command is: /loop babysit all my PRs. Auto-fix build issues, and when comments come in, use a worktree agent to fix them.

That instruction sets a loop running in the background that monitors your open pull requests, fixes failing builds automatically, and responds to review comments by spawning a separate worktree agent to implement the requested changes. You did not write the specific steps. You wrote the intent and the stopping behavior. The loop determines the implementation details on each iteration.

Cherny posted five tips for running the model autonomously for hours or days. Use auto mode for permissions so the model does not ask for approval at every step. Use dynamic workflows to have the model orchestrate hundreds or thousands of sub-agents for complex tasks. Use /goal or /loop to tell the model to keep going until the task is verifiably complete. Use the cloud version so you can close your laptop without stopping the work. Make sure the model has a way to verify its own work end to end.

That fifth tip is the one the hype consistently skips and the practitioners consistently emphasize. A loop is only as trustworthy as its ability to check its own output. A loop that writes code without a feedback mechanism is a machine for generating confident mistakes at scale. A loop that writes code, runs the tests, reads the test results, identifies failures, and corrects them before moving forward is the thing that actually works in production.

The deep end of this architecture is Steve Yegge’s Gas Town, launched in January 2026. The system coordinates twenty to thirty Claude Code instances managed by a Mayor agent, with patrol agents that run continuous loops and state stored entirely in git so the work survives crashes and restarts. This is the continuous orchestration loop supervising other threads that practitioners were reaching for when they tried to articulate what stage five actually looked like.

The Plot Twist: The Loop Is Now the Expensive Part

Here is where the discourse shifted from philosophy to finance, and where the most grounded observation in the entire thread came from a working engineer rather than a thought leader.

“Every AI agent I shipped this year is a for-loop, an LLM call, and a try/catch around the json parsing. The only thing agentic about it is the Anthropic bill at the end of the month.”

That bill is not a joke and the receipt is real. Uber capped its engineers at $1,500 per person per tool per month for Claude Code and Cursor after burning its entire annual AI budget in four months. Once the model writes code for nearly nothing per token, the cost moves to managing the loop that keeps calling the model.

As one practitioner put it directly: the costliest thing in AI coding is no longer writing code, it is managing the agent loop. And the failure mode that everyone in production is scared of is the loop that does not stop.

Without guardrails, you get infinite loops and billing surprises orders of magnitude over budget. Which is why every serious 2026 treatment of loops converges on the same three hard stops as non-negotiable engineering requirements. A maximum iteration count that prevents the loop from running forever regardless of whether it thinks it is making progress. No-progress detection that identifies when the loop is cycling without producing meaningful change and halts before more tokens are consumed. A token or dollar budget ceiling that kills the loop when cumulative cost exceeds a defined threshold.

The romantic version of loops is that you write the intent once and a thousand agents build your product while you sleep. The production version is that you write the loops, define the stopping conditions carefully, monitor for billing anomalies, and most of your actual engineering work is making sure they halt. Gartner places agentic AI at the peak of inflated expectations with approximately 17% of organizations actually deploying agents in production. The gap between the discourse and the receipts is the real state of play.

Skills Are the Asset, Loops Are the Plumbing

This is where Van Horn lands after a week of research and where the most durable insight sits.

The loop is plumbing. The asset is the skill it calls.

Steinberger’s other recurring point pairs with the loops observation and is the more lasting half of what he is actually saying. If you do something more than once, turn it into an automated skill. If you do something hard, turn it into a skill afterward so the next time is free. A loop with no reusable skills inside it is just a while-true wrapped around a stranger. A loop that calls a library of sharp, tested, named skills is a system that compounds. Every time you add a skill to the library, every future loop that calls it gets better without additional work.

The practical test for whether you have built a loop or just a fancy script is whether the skills inside it are reusable across different loops. If the only way to use the knowledge is to re-derive it from scratch in each new loop, you have not actually built anything that compounds. If the skills are modular enough to be called by any loop that needs them, you are building infrastructure rather than one-off automation.

What This Means for How You Should Think About AI Coding in 2026

The honest answer to what a loop is has five components that fit together.

A loop is cron plus a decision-maker in the body. The model, not a hardcoded branch, picks the next action at each iteration based on current state. The scheduling is familiar technology. The judgment is not.

The lineage is real and matters for understanding what stage you are at. The academic ReAct loop in 2022, AutoGPT’s failures in 2023, ralph’s discipline in 2025, the /goal productization in spring 2026, and the multi-agent orchestration architecture now are five meaningfully different things that the same word describes. Single-agent ralph is genuinely old hat. Multi-agent supervision with durable shared state is the current frontier.

The loop is only as good as its feedback mechanism. Continuous review, validation gates, and the ability for the loop to verify its own output are what make it trustworthy rather than a confidence-generating machine for mistakes. This is the tip that practitioners obsess over and hype cycles skip.

The expensive resource shifted from tokens to loop management. Cap iterations, detect no-progress, set a dollar budget ceiling, and treat these as non-negotiable engineering requirements rather than optional safeguards.

The reusable unit inside the loop is a skill, not a prompt. Loops that call a library of sharp named skills compound in value over time. Loops that re-derive everything from scratch on each run just burn money and tokens without building anything durable.

The practitioner on Reddit who said their ears were perked up while others were rolling their eyes had the most accurate read of the situation. The timeline version of this conversation is noise. The production version, the one involving actual billing receipts, git-backed state, worktree isolation, validation gates, and skill libraries, is where the real engineering is happening.

Steinberger and Cherny are describing the same thing from two sides. Stop being the entity inside the loop. Write the loop once. Give it skills worth calling and feedback so it can check itself. Cap it so it halts. Let it run on cron while you go think about what to build next. The on-ramp is a single slash command. The hard part, the part that makes it actually work in production, is everything that happens before you type that command.