2.2 million people saw the tweet. The replies spent the day arguing about what it meant.
"You should be designing loops that prompt your agents." Everyone shared it. Almost nobody could explain it. The builders who can are staring at their billing dashboard.
On June 7, Peter Steinberger posted a single sentence on X.
"Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
2.2 million views. Thousands of reposts. The phrase "designing loops" was in every AI coding thread for 48 hours straight.
The most honest reply came from Matthew Berman, who wrote four words that accidentally became the whole story.
"nobody knows but him and boris."
That is the state of the most viral idea in AI coding this week. A six-word concept at 2.2 million views, with a comment section full of people arguing about what those six words actually mean.
Here is what it actually means, because someone should say it plainly.
Boris Cherny created Claude Code as a side project in September 2024. It now sits behind close to four percent of all public commits on GitHub. On June 2, he gave the clearest definition available anywhere.
"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."
So: a loop is a small program that prompts the coding agent for you, reads what it produced, decides whether the job is done, and if not, prompts it again. You stop being the thing typing prompts. You become the author of the program that types the prompts. The model becomes a subroutine.
Boris describes this as three stages. A year ago he wrote code by hand with autocomplete. Then he ran multiple Claude sessions in parallel and prompted each one himself. Now he doesn't prompt at all. He writes the loops. In the last 30 days of data he shared publicly, 100 percent of his contributions to Claude Code were written by Claude Code. 259 pull requests. He deleted his IDE in November and hasn't opened it since.
That is a real thing. The lineage behind it is real. The 2022 ReAct paper formalized the basic while-loop pattern. Geoffrey Huntley built an entire programming language with a bash one-liner version called ralph in July 2025, for about $297. Claude Code shipped a /loop command in spring 2026 that makes the entry point a single slash command.
The discourse is not inventing something new. It is catching up to something that practitioners have been quietly building for 18 months.
Now here is the part the hype coverage is skipping.
Uber ran into something instructive earlier this year. After deploying AI coding tools including Claude Code and Cursor to their engineering team, they burned through their annual AI budget in four months. The company capped each engineer at $1,500 per person per tool per month.
That cap is the number worth sitting with. Not as a horror story about waste, but as a signal about where the cost in AI coding actually lives now.
A year ago, the expensive part of AI-assisted coding was the tokens. Writing the right prompt, getting a good output, paying per thousand tokens. That cost was visible, metered, and relatively contained.
Once you stop prompting and start running loops, the cost structure changes completely. A loop that runs overnight on thirty open-source repos, checking for issues and opening pull requests, is not doing one prompt. It is doing hundreds. Possibly thousands. On a schedule. Without you watching.
"The costliest thing in AI coding is no longer writing code. It's managing the agent loop."
That quote is from a practitioner in the June discourse, and it is the sentence the Steinberger tweet implies but doesn't say. Designing loops is the future. Running loops at scale is a billing event.
The failure mode everyone in production is quietly scared of is the loop that doesn't stop. A loop with a logic error that runs 800 iterations overnight before anyone notices. A loop that detects progress incorrectly and keeps prompting long after the job is done. Every serious writeup on production loops converges on the same three guardrails: a maximum iteration count, a no-progress detection check, and a hard dollar-budget ceiling.
The romantic version of loops is that you write them once and a thousand agents build your company while you sleep. The production version is that you write them, and most of your actual job is making sure they halt.
There is a deeper issue underneath the cost one, and it is the part of the discourse that deserves more attention than it's getting.
A loop is only as good as the feedback inside it.
A loop that writes code and checks whether the tests pass is useful. A loop that writes code and has no mechanism to verify whether what it produced is correct is a machine for generating confident mistakes at scale. The loop runs, the agent produces output, and because nobody checked the stopping condition carefully enough, the thing keeps going and compounds the error.
The fastest-growing sub-theme in the June research wasn't orchestration. It was verification. Multiple practitioners flagged that continuous review and commit-level feedback are what separate a loop that works from a loop that works until it doesn't, expensively.
One engineer described it: "bad commits compound fast." The fix isn't a better loop. It's a loop with a reviewer built in, something that reads what the agent produced before it decides to keep going.
Boris's own advice for running loops autonomously includes this as tip five, the one the hype coverage glosses over: make sure Claude has a way to self-verify its work end to end.
That is the whole idea compressed to a sentence. The loop isn't the asset. The feedback inside it is.
Here is the contrarian read on all of this.
The phrase "designing loops that prompt your agents" sounds like it's about the loop. It's not. It's about what you put inside the loop that makes it worth running.
A loop calling a well-defined, tested, reusable skill is a system that compounds. A loop that re-derives everything from a vague prompt each time is expensive noise on a schedule. The practitioners who are actually compounding aren't the ones who figured out loop architecture. They're the ones who built sharp, named, trustworthy skills for the loop to call, and feedback mechanisms good enough to know when to stop.
The cron job comparison that floated through the discourse is half right. Yes, the scheduling layer is cron. Boris runs his on cron. Claude Code uses cron under the hood. But cron runs a fixed script. A loop runs a decision-maker that looks at current state and figures out the next step. Stack those, let one loop supervise others, give them shared state that survives a restart, and you have something cron cannot express.
The gap between cron and loops is the agent in the body. The gap between a loop and a compounding system is the quality of what that agent calls and whether it knows when it's done.
One thing to think about
Before you design a loop, decide what it will do when it's wrong.
A loop that can't detect its own failure isn't autonomous. It's just expensive.