I found the thesis for this post in my own X bookmarks, which is embarrassing, because I had already saved every piece of it and never noticed.
Three bookmarks. Saved weeks apart. Different authors, different months, filed and forgotten the way bookmarks always are. One was Boris Cherny, the creator of Claude Code, saying he does not prompt Claude anymore. One was a thread arguing that most people reach for multi-agent systems way too early. One was a quieter note about execution sandboxes and something called code mode. I had tagged each of them, closed the tab, and moved on, three separate times.
It was only when I lined them up next to each other that I saw they were not three ideas. They were one idea arriving from three directions, and the idea is this: the unit of AI engineering work is no longer the prompt, and it was never the org chart. It is the loop.
Let me explain, because I think most of us are building the wrong thing right now, and building it enthusiastically.
The line that broke the internet
Here is what Cherny actually said, and it is worth quoting exactly, because everyone clipped it and almost nobody built what it describes: "I don't prompt Claude anymore. I write loops and the loops do the work. My job is to write loops."
Sit with that for a second. The person who built the most widely used agentic coding tool on the planet describes his own job not as prompting, not as reviewing, not as conducting a symphony of specialist agents. He describes it as writing loops. Singular verb, singular unit. A loop.
The clip went everywhere. Peter Steinberger amplified it. Addy Osmani, over at Google, wrote the pattern up properly and gave it a name, loop engineering. The New Stack ran a whole piece on the Anthropic leader who ditched prompting. And Anthropic, for its part, quietly shipped the plumbing to match. /loop, /goal, /schedule, and /workflows are now first-party commands in Claude Code. The stuff you used to hand-roll in bash scripts is now sitting in the product, which tells you the company building the tool believes this is where the work is going. I walked through the mechanics of two of these in the routines guide and the scheduled tasks guide, so I will not re-explain the commands here.
So the industry heard the line. What it mostly did with the line was misread it.
What a loop actually is
A loop is not a fancier prompt. It is a small autonomous control system with three moving parts, and if any one of them is missing, you do not have a loop. You have a script that happens to call an LLM.
It discovers work on some trigger. A schedule, a webhook, a new commit, a file landing in a folder. Something happens in the world, and the loop wakes up on its own. You are not there to press go.
It verifies the work, usually with a second pass, often a second agent whose only job is to check the first one. This is the part people skip, and skipping it is exactly why their loops produce confident garbage. More on this in a minute, because it is the single highest-leverage habit in the whole practice.
And it writes its own state down somewhere durable, so the next run picks up where the last one left off. The loop has memory. Tomorrow's run is not starting from a blank slate. It is standing on today's output.
I wrote in my agentic engineering guide about the morning a pull request opened on a side project I had not touched in nine days, patched a flaky test, and waited politely for me to wake up. That was a loop. I set up the conditions once, and then the work happened without me in the room. The magic was not in any single clever prompt. It was in the fact that the thing ran on a trigger, checked itself before opening the PR, and remembered enough context to know which test had been flaking.
Trigger, verify, persist. That is the shape. Everything else is decoration.
Verification is the whole game
Let me dwell on the middle part, because it is where amateurs and professionals separate.
An agent left alone will finish a task and tell you it succeeded. That is not lying. It genuinely believes it. The model has no independent sense of whether its output is correct, only whether the output looks like the kind of thing that would be correct. On a good day those are the same. On a bad day they are catastrophically different, and the agent's confidence is identical either way.
The fix is not a better prompt telling it to be careful. Telling a model to be careful is like telling yourself to remember your dreams. The fix is structural. You run the work, and then you run a separate pass whose entire job is to try to prove the work wrong. A second agent that reads the diff and asks whether the tests actually cover the change. A test suite that runs unattended and fails loudly. A reviewer routine that treats the first agent as an adversary rather than a colleague. I built a version of this for pull requests and wrote it up in multi-agent PR review, and the thing I learned is that the reviewer does not need to be smart. It needs to be skeptical and independent. Skepticism plus independence catches a startling fraction of errors that no amount of prompt-tuning on the first agent ever would.
This is why "my job is to write loops" is a claim about verification as much as automation. A loop without a verification pass is just a faster way to be wrong at scale. A loop with one is a system that gets more trustworthy the longer it runs, because every cycle is a cycle that had to survive a check.
The mistake everyone makes instead
Now here is the second bookmark, and it is the corrective to all this enthusiasm.
Akshay Pachaar wrote a clean thread on subagents versus agent teams, and the line that stuck with me was the deflating one: most people reach for multi-agent systems too early. Start with a single agent. Only add complexity when you can actually measure that you need it.
I have watched this play out over and over, and I have done it myself, so I am not throwing stones from inside a clean house. You read about a slick multi-agent architecture. A planner agent that delegates to a researcher agent that hands off to a coder agent that reports to a reviewer agent. It looks like an org chart, and org charts feel like progress, because they resemble the serious enterprise diagrams we were all trained to respect. So you build one.
And then you spend three days debugging why the researcher keeps passing malformed context to the coder, and why the reviewer approves things the planner never asked for, and you slowly realize you have built a very expensive game of telephone. Five agents, each one a little bit lossy, chained together so the errors compound instead of cancel. You did not build a team. You built a bureaucracy, and a bureaucracy is where good context goes to die.
Run the napkin math on it. Say each handoff between agents preserves 90 percent of the original intent, which is generous. A five-agent chain preserves 0.9 to the fifth power. That is about 59 percent. You have thrown away 40 percent of your own instructions before a single line of useful work got done, and you did it on purpose, because the diagram looked impressive on a slide.
A single good loop, running the same task ten times with verification and memory, beats a five-agent org chart on almost every real problem I have handed to both. Not because multi-agent is wrong in principle. There are genuine cases for it, and I covered the legitimate ones in parallel agents and worktrees. It is because multi-agent is a cost you should pay only when a single agent has provably hit a wall, and almost nobody actually checks whether it has. They reach for the org chart first, on instinct, because complexity feels like seriousness.
Cherny did not say "my job is to write agent teams." He said loops. The people at the very top of this practice are reaching for the simplest structure that works, not the most elaborate one they can justify. That inversion is the entire lesson, and it runs against every instinct a career in software has trained into you.
Where the memory lives
The third part of the loop, state, deserves its own moment, because it is the least glamorous and the most quietly decisive.
A loop that forgets is a loop that repeats itself. It re-does yesterday's work, re-discovers yesterday's dead ends, re-asks questions it already answered. Persistent state is what turns a loop from a hamster wheel into a ratchet, something that only moves forward. In practice this is a file. A structured log the loop reads at the start of every run and appends to at the end. It records what was tried, what worked, what was explicitly ruled out, and where the next run should begin.
This sounds trivial and is not. The discipline of writing state that a future agent can actually use is a real skill, closely related to the discipline of writing a good CLAUDE.md or maintaining persistent context across sessions. The trap is writing state for yourself instead of for the agent. You jot a cryptic note that makes sense to you at 11pm, and tomorrow's run, which has none of your context, reads it as noise. Good loop state is written the way you would brief a competent stranger who is starting cold. Because that is exactly what every run is.
The part nobody wants to talk about
Which brings me to the third bookmark, the quiet one, and the reason the other two are not just naive optimism.
If your job is now to write loops that run on a schedule and do work while you sleep, then you have handed a lot of autonomy to something that does not have judgment. A loop that wakes up every hour and runs code is also a loop that can, on any given hour, be handed a poisoned input and do something you very much did not intend. Dexter Horthy's note on code mode and one-off execution sandboxes is about exactly this, and it is the load-bearing wall the other two ideas quietly rest on.
Here is the tension, stated plainly. Loops get their leverage from acting without you in the room. But acting without you in the room is precisely what makes them dangerous. The same property is both the value and the risk, and you cannot prompt your way out of that. You resolve it with a wall.
That wall is the sandbox. Claude Code now ships a sandboxed execution environment that restricts filesystem access and outbound network calls at the operating system level, using Seatbelt on macOS and bubblewrap on Linux. The agent inside the loop can do its work, but it can only reach what you explicitly let it reach. If a web page it fetches contains an injected instruction, and this happens, the blast radius is bounded by the sandbox rather than by the agent's good intentions. I have written before about why this matters more than people think, in the context of real breaches and security rules for vibe coding, and the short version is that autonomy without a boundary is not a feature, it is an incident waiting for a trigger.
Code mode is the other half of Horthy's point. Instead of making a slow round trip through the model for every single tool call, you let the model generate code that calls the tools directly. The reported latency on a naive tool call is around four seconds of model reasoning and API overhead per call, and a verify-heavy loop makes a lot of calls. Code mode collapses that, which is what makes a loop cheap enough and fast enough to actually run on a schedule rather than burning a fortune in tokens and wall-clock time. Safety and speed, from the same idea.
This is the unglamorous half of loop engineering, and it is the half that separates a demo from a system you would let near a real codebase. Anyone can write a loop that works on a good day. Writing a loop that fails safely on a bad day, when the input is malicious or the model is confused, is the actual engineering. Simon Willison's growing collection of agentic engineering patterns keeps circling this same point from different angles. The discipline is not in getting the agent to act. It is in getting it to act within bounds, verifiably, repeatably, and recoverably.
Why these three are actually one
So line them up.
Cherny gives you the unit: the loop, not the prompt. That is what you build.
Pachaar gives you the constraint: one loop, not an org chart, until you can measure that you need more. That is how much you build.
Horthy gives you the precondition: the sandbox, without which none of the autonomy is safe to run. That is what has to be true before you build any of it.
What. How much. What must be true. Read together, they are not three hot takes from three different weeks. They are a nearly complete design brief for how to do this well in 2026. The unit is small, the structure is minimal, and the boundary is hard. Everything I have seen work in production has looked like that. Everything I have seen collapse has violated at least one of the three, usually by building an elaborate multi-agent cathedral with no sandbox around it and no verification inside it, and then acting surprised when it went sideways at 3am.
I think the reason so few people have assembled this picture is structural, not intellectual. The pieces arrive separately, on different days, in different threads, from different people you follow for different reasons. You bookmark them one at a time and you never put them in the same room. I certainly did not, until something made me line up my own saved tweets side by side and the pattern just fell out of them, fully formed, as if it had been waiting.
What I would actually do on Monday
If you are somewhere between vibe coding and full agentic engineering, and most of us are, here is the smallest honest next step.
Pick one recurring task you already do by hand. Dependency bumps. Triaging a bug queue. Drafting release notes. Something small and real and a little bit boring. Write a single loop for it. One agent, with a verification pass and a state file, and put a sandbox around it before you let it touch anything you care about. Do not add a second agent until the first one has visibly hit a ceiling you can point at and name. Resist the org chart. The org chart is a trap that feels like ambition and behaves like debt.
Then let it run for a week and watch what it does. My guess, from having done this a dozen times now, is that the single sandboxed loop will quietly outperform the elaborate system you were tempted to build instead, and it will do it with a tenth of the moving parts and a hundredth of the debugging. If you want the deeper mechanics, hooks and subagents and the rest of the kit, they are all in the complete agentic engineering guide, the hooks cookbook, and the custom agents guide, which covers the specific question of when a second agent finally earns its seat. The 50 Claude Code tips are where the small compounding refinements live once your loop is running.
I am still not sure where all of this lands. I wrote a little about that in the future of vibe coding, and I am less certain now than I was then, which I have decided to treat as the correct direction to be moving. What I am fairly sure of is that the people who win the next year are not the ones with the most agents. They are the ones with the fewest, wrapped in the best walls, running the tightest loops, checked by the most stubborn reviewers.
If you are building loops right now, I would genuinely like to know two things. What is your one recurring task, and have you caught yourself reaching for the org chart when a single loop would have done? I catch myself constantly. The conversation is more useful than the conclusion here, so tell me where I have this wrong.
