You're Not Writing Prompts Anymore. You're Writing Loops.

How to go from giving an AI one-off instructions to building agents that run on their own. You can do it in plain English, no code required. Boris Cherny, the engineer behind Claude Code, says he doesn't write prompts anymore. He writes loops. Here is what that shift actually asks of you, and how to do it without writing a line of code.

The shift in one sentence

Boris Cherny, the engineer behind Claude Code, said the thing out loud. He doesn't write prompts anymore, he writes loops. That sounds like a throwaway line until you see what it actually describes, which is a real change in what the human's job is.

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

— Boris Cherny, Head of Claude Code, Anthropic

Here's the move. In the old workflow you were the one deciding what to ask. You type a prompt, read the reply, decide the next prompt, type that. You're inside the conversation, and your reaction time is the bottleneck. In the new workflow you stop being the one who decides what to ask and become the one who designs the system that decides what to ask. The loop holds the conversation. You sit above it, reviewing outcomes instead of steps.

That's the whole shift in one line: you stop issuing the instruction and start building the thing that issues its own instructions. This lesson is short on theory and long on the part that bites you, because the loop is now the program and the hard problems live in how it starts, repeats, and stops.

Why a single instruction was never going to be enough

A normal request to an AI is a straight line. You hand it text, it hands you text back. One shot.

The reason that feels limited for real work is not that the model is dumb. It's that the model can't see the consequences of its own answer before giving it to you. It can't run the code it wrote. It can't read the file it asked for. It can't check whether the answer was right.

The loop is what closes that gap. You let the model produce something, you carry out the consequence in the real world, and you feed the result back so the next pass can react to it. That feedback path is the entire difference between "a model" and "an agent."

The skeleton

Every agentic loop, under all the frameworks and vocabulary, is a version of this:

Four moving parts. The model thinks. It either says it's done or asks to take an action. You carry out the action. You add the result to its memory so the next pass can use it. Then around again.

Read that loop carefully, because almost every mistake people make here is a mistake about one of those four lines, not about the model.

You don't need to write code to write a loop

Here's the part that trips people up. The skeleton looks like code, so writing loops feels like a programming job. It isn't, not anymore. In tools like Claude Code or Cursor, you write the loop in plain English and the tool runs it for you. The four parts are the same. You just say them in words instead of in code.

Start with what you already do. You give it one instruction:

Fix the failing tests in this project.

That's one shot. The agent takes one swing and hands it back. If it's wrong, you read it, think, and tell it again. You are the loop. Every turn waits on you.

Now write a loop instead:

Fix the failing tests. After each change, run the test suite. If it still fails, read the new error and try again. Keep going until the tests pass, or until you've tried ten times. Don't change anything in the database folder without asking me first.

You didn't write code. But you wrote a loop, and it has every part the skeleton had.

That's the whole shift, in one paragraph you could type today. A single instruction gets you one attempt. A loop in plain words gets you a process that runs itself, checks itself, and knows when to stop and when to ask. The skill isn't coding. It's remembering to say those four things every time, instead of hoping the agent fills them in for you.

The rest of this piece is those four things, one at a time: when the loop stops, what it remembers, how it checks its own work, and when it has to pause for you.

The four things you are now responsible for

When you stop writing prompts and start writing loops, four responsibilities land on you that a one-off instruction never did.

1. The stopping condition is your job, not the model's

A loop with no exit is a bug. An agent with no real stopping condition is the same bug wearing a costume, and it's much easier to ship by accident.

There are two ways an agentic loop ends, and you need both:

• The model decides it's done. It stops asking to take actions and returns an answer. This is the intended exit. It's also unreliable on its own, because a confused agent can believe it's finished when it isn't, or never believe it.
• A hard ceiling fires. A maximum number of tries, a spending limit, a time limit. This is the guaranteed exit. It's not a nicety, it's the circuit breaker that stands between you and an agent that repeats the same step a few thousand times while your bill climbs.

Build both, always. The model deciding it's done is your normal path. The ceiling is what saves you when that judgment is wrong, which it will sometimes be.

In plain English, you'd say: "Stop when the tests pass. But if you've tried ten times and they still don't, stop anyway and tell me." In code, the same idea looks like this:

Here's a worked example of why the ceiling matters more than it looks. There's a popular technique in agentic coding called the "Ralph Wiggum" loop, named after the Simpsons character who is cheerfully persistent and never stops. It re-runs a coding agent against the same plan over and over, letting it chip away at a task for hours. People run it deliberately and it works. The reason it's safe to let something that open-ended run unattended is precisely the hard ceiling: a fixed cap on tries and a clear definition of done. Remove the ceiling and the same technique becomes a machine for burning money on repeat. The cap is not what limits the loop. It's what makes trusting the loop possible.

2. What the agent remembers is your job too

The agent's memory is just the running record of everything it has done so far. There is no other place it "remembers." This is something you have to plan for from the start, not discover forty steps in.

That memory has a ceiling. A loop that runs long enough will overflow it, and it doesn't crash cleanly, it degrades. The agent gets vaguer, forgets earlier results, repeats work it already did. So part of writing the loop is deciding what stays in memory and what gets summarized, dropped, or filed away and pulled back only when needed. You are doing memory management. The fact that it's in plain English doesn't make it not memory management.

A simple habit helps: keep two piles, not one. The first pile is the goal and the decisions that matter, the things that should stay true the whole way through. The second is the noise from the current step, which you can throw out once you've moved on. Dump both into one giant pile that only grows, and long runs fall apart. This is the same problem I wrote about in Why Your Agent Forgets the Rules: the agent doesn't hold onto your instructions the way you'd expect, and the fix is in how you build the loop, not in writing a longer prompt.

In plain English, you'd say: "Keep a short running summary of what we've decided and what's left to do, and don't lose the goal just because the conversation got long."

3. The check is the hard part, not the doing

This is the most important idea here and the one most people get backwards.

It is tempting to think an agent improves by getting better at producing. More tries, better output. But an agent can only get as good as its ability to tell whether the last step actually worked. The loop is a do-it-then-check-it cycle, and the check is the part that's hard.

Think about an agent that drafts something, critiques its own draft, and revises:

The revising is rarely the problem. The checking is where everything lives or dies. If the check is weak, every extra loop just produces more confidently-wrong output, polished and revised and still wrong. You will have built a machine that works hard toward a bad answer.

So when a loop underperforms, resist the urge to make it produce better first. Look at how it checks itself. Ask how the loop knows a step worked. The checks that hold up are the cheap, boring ones: did the code compile, did the test pass, did the page load, does the output match the format you asked for. A loop that checks "are the tests green" is worth ten loops that check "does this look good to the model."

In plain English, you'd say: "After each attempt, check it against something real, run the tests, load the page, compare it to the format I gave you. Don't just decide for yourself that it looks fine."

This is also, not coincidentally, the bottleneck the whole industry is now hitting with AI-written code. Producing it got cheap. Checking it didn't. Anthropic's own numbers make the scale of that gap concrete:

8x more code shipped per engineer per quarter, and 80%+ of merged code authored by the model (as of Q2 2026).

— Anthropic, When AI builds itself, June 2026

When that much output is machine-made, the human job stops being "write the code" and becomes "check the code," and checking was always the expensive half. The same truth shows up at the scale of a single loop and at the scale of an entire engineering org. I made the cost-side version of this argument in Tokenomics: Beyond the Cap.

4. When the agent has to ask you is something you decide on purpose

Once the loop runs on its own, you are no longer automatically in the conversation. That's the point of building it. But it means the moments where you should weigh in no longer happen by default. They happen only if you put them there.

So treat the human checkpoint as something you place on purpose, not an afterthought. Decide which actions are risky enough that the loop has to stop and wait for a person first: deleting data, sending an email to a customer, spending money, merging code, anything that touches production. For those, the loop shouldn't decide alone, and "the model was pretty sure" is not an approval.

In plain English, you'd say: "You can change code and run tests on your own. But before you delete anything, email anyone, or touch production, stop and ask me first."

The instinct to resist is letting the agent drift across that line because it's smoother without the pause. The smoothness is exactly the risk. A loop that can do something irreversible without a checkpoint will eventually do something irreversible you didn't want. Deciding where you stay in, and building that in, is one of the realest pieces of engineering in the whole design.

The loop shapes you'll actually build

The skeleton specializes into a handful of recurring shapes. You don't need a framework for any of them. You just need to recognize which one the task wants.

The task loop. The default. Run until the work is done or the ceiling fires. Most "do this thing for me" agents are this.

The reflection loop. Produce, then critique, then revise. One cycle makes the thing, another judges it. Worth the cost only if your check is genuinely good, for the reason in number three.

The watch loop. The agent waits on something that changes over time: a build finishing, a job completing, a file landing. It mostly checks and waits.

The one rule here: pause between checks. A loop that checks every millisecond is how you get rate-limited, or how you turn a free wait into an expensive one.

The orchestration loop. One agent acts as the manager. It hands out pieces of work to other agents, collects what comes back, and each of those can run its own loop inside. This is where planning and doing should split: one agent plans the steps once, and the others carry out each step without re-arguing the whole plan every time. It's also where managing memory stops being optional, because now you have several agents' worth of state to keep straight.

Designing a loop: the checklist

Before you start a loop, in code or in plain English, answer these. Your answers are the loop. The exact words you give the model matter far less than getting these six right.

1. What does one round get done? What does a single pass through the loop actually accomplish? If you can't say it, the loop will just spin.
2. How does it check its own work? What tells the loop the last step worked? Prefer a real signal (tests, a page that loads, a matching format) over the model's opinion of itself.
3. When does it stop? Both ways: the model deciding it's done, and your hard limit. Say both.
4. What does it remember, and what does it drop? Decide before the run gets long, not halfway through.
5. What happens when something breaks? A tool errors, a step returns garbage. Does it retry, work around it, or stop? If you don't say, the agent will improvise, and it improvises badly.
6. When does it have to ask you? Which actions are risky enough that the loop must stop and wait for a person? Name them. They won't appear on their own.

The mental model to walk away with

One instruction gets you one attempt. Writing a loop gets you a process: where it starts, what each round changes, how it checks itself, what it remembers, and when it stops. The model is just one part of that process, the part that picks the next move. Everything around it is the part you design.

And you design it in whatever words you're comfortable with. You don't need to write code. You need to say, every time, the four things a single instruction leaves out: when to stop, what to remember, how to check the work, and when to ask you first. Say those out loud and you've written a loop.

That's the whole shift. The leverage moved out of the wording of the instruction and into the shape of the cycle. Once you see the loop as the program, "I don't write prompts anymore, I write loops" stops sounding like a brag and starts sounding like a job description.

Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss building reliable agentic systems for your organization.

References

1. Boris Cherny on writing loops instead of prompts. The Neuron, "Claude Code's Creators Explain Agent Loops & How They Code." theneuron.ai
2. Anthropic, "When AI builds itself: Our progress toward recursive self-improvement and its implications." June 2026. anthropic.com
3. Geoffrey Huntley, the "Ralph Wiggum" agentic coding loop. ralph-wiggum.ai