Insight · July 3, 2026
Stop being
the loop.
The engineer who created Claude Code does not prompt Claude anymore. Loops prompt Claude for him.
01 · The shift
The person who built the tool stopped using it by hand.
Boris Cherny built Claude Code at Anthropic. In June 2026 he said it out loud: he does not prompt Claude anymore. Loops prompt Claude for him. His actual job now is writing loops.
That sounds like a flex. It is not. It is the biggest shift in how the best operators use these tools right now, and almost nobody does it yet. Most people are still typing one prompt at a time into a machine that was built to run without them.
02 · The problem
Right now, you are the loop.
Here is how most people work today. You type a prompt. The model edits a file. You run the test. It breaks. You paste the error back. It tries again. Twenty minutes later you realize you have been babysitting the exact thing you wanted to hand off.
You are the one checking the work and deciding the next step, every single time. That is the job a loop takes over. Not the thinking. The checking, the retrying, the deciding what comes next.
The one line to keep
“Prompting is doing the work. Loop engineering is managing the worker.”
03 · What a loop actually is
Five beats, no matter how fancy the system.
01
Find the work
Open tasks, failing tests, unread email, files in a folder. The loop starts by looking, not by being told.
02
Do it
One item at a time, finished fully before the next, the way you would by hand.
03
Check itself
A second pass confirms the work is done and correct, not just produced. Evidence, not confidence.
04
Remember
It writes down what is finished, so it never repeats work or loses its place between runs.
05
Go again
It repeats until nothing is left, then stops on its own or pings you.
04 · Not a scheduled task
A cron job runs a script. A loop runs a decision maker.
Your computer has been able to run the same thing every morning at 8am for fifty years. That is a cron job. Fixed script, same steps, no thinking. A loop is different because of one thing: there is judgment inside it.
The model looks at the current situation, picks the next action, does it, checks the result, and then decides what to do next. Keep going. Try again. Undo. Stop. A script cannot look at a broken test and reason its way to a different fix. A model can. That decision in the middle is the entire point, and it only became possible once the models got good enough to make real judgment calls mid job.
05 · One example that shows the whole difference
The brief with sources that actually exist.
Ask a model for a one page brief on any topic. It writes something clean and confident, with sources at the bottom. Now open the sources. Some of them are fake. They look real, the links go nowhere, and the model stays confident until something actually opens them. A single prompt can never catch this.
Run it as a loop instead. Same brief, but with a bar the loop can measure: every claim needs sources, and every link has to open to a real page that backs the claim. The loop writes the brief, then goes link by link. It opens each one, throws out the dead and the fake, finds real replacements, and keeps checking until every source on the page holds. Then it stops. It never gets bored. It never skips the boring ones.
/goal write a one page brief on [your topic] where every claim is backed by sources and every link opens to a real page that supports the claim. Open each link to confirm it before you call it done. Replace any source that is dead or does not back the claim. Stop only when every source on the page checks out.
A goal loop · works until the finish line is true
06 · The charter
Bigger jobs get a charter, not a prompt.
A one line goal is plenty for a small job. For a job with many pieces, you hand the loop a full charter: what done looks like in measurable terms, where the work lives, how to verify each item before marking it finished, and when to stop.
The quiet hero is the state file. After every item the loop writes down what got done, what is blocked, and what needs a human call. It reads that file first on every run, so it never redoes finished work and never loses its place. Without state, every run starts from zero. With it, the loop picks up exactly where it left off, even overnight, even on a schedule.
Anything requiring a decision only you can make, like spending money or emailing a person, goes on a needs you list instead of being guessed at. The loop keeps moving. You review the list.
07 · When not to build one
Loops are not free, and not for everything.
One off tasks do not need a loop. If the job is a single answer, a plain prompt is faster. Loops earn their setup cost on work that repeats or has many pieces.
Loops cost more. A system that checks itself and retries is running the model several times per item. That is the price of work you do not have to check yourself, and it is usually worth it, but it is a real price.
And vague work does not belong in a loop. Think of a better strategy is not a loop. If you cannot describe the finish line in measurable terms, the loop cannot check itself, and a loop that cannot check itself is just a prompt running unattended.
Closing
You were never supposed to be the loop.
Pick one task you keep doing by hand, the kind with many small pieces. Give it a finish line it can measure. Run it once while you watch every step. The first time you wake up to work that finished overnight, you will stop typing prompts one at a time.
Boris Cherny's remarks · Code with Claude Tokyo, June 2026 · loop patterns adapted from the practice around Claude Code's goal and loop commands
Share this perspective
More insights
Adjacent perspectives.
Bttr. Field Brief
The brief Bttr. writes for senior buyers.
Monthly. One signal worth your time on Brand Operating Systems, AI search visibility, and the infrastructure buildout. No filler.