The Quiet Shift From ‘Prompt Engineering’ to ‘Loop Engineering’

The model writes the prompts now. The scarce skill is deciding when the work is actually done — and that changes what you should be practicing.

In June 2026, Boris Cherny — the engineer who leads Claude Code at Anthropic — told an interviewer something that should have been bigger news than it was. He said he no longer writes prompts. “I don’t prompt Claude anymore,” he put it. “I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

Read that again, because the person who builds one of the most-used coding agents in the world is describing his own day job as not the thing every tutorial has spent two years teaching you to do. He doesn’t craft the perfect prompt. He builds the small system that decides what to ask, checks the answer, and decides what to ask next.

That is the whole shift, and it has a name now: loop engineering. The leverage has moved off the prompt and onto the loop around it. If you are still measuring your skill by how clever your instructions are, you are optimizing the wrong layer — and this piece is about why, and what to practice instead.

Where this came from, and why suddenly

The term didn’t crawl up slowly. It detonated. On June 8, 2026, a two-sentence post from developer Peter Steinberger argued that you shouldn’t be prompting coding agents anymore — you should be designing the loops that prompt them. That post reportedly crossed 6.5 million views in days (per ExplainX’s writeup), which is an absurd number for a take about software workflow.

The day after, Addy Osmani — an engineering lead at Google Chrome — published an essay titled simply “Loop Engineering” that gave the pattern a name and a structure. Within a week it was a genuine community vocabulary, covered by The New Stack, O’Reilly’s Radar, and a wave of practitioner posts.

Honesty flag on the “6.5M views” figure: this number traces to ExplainX’s reporting on Steinberger’s post, not to a platform-verified analytics export. I’m passing along an attributed secondhand figure — treat it as “went very viral,” not as an audited metric.

Here is the part that matters more than the virality: the term landed because it named something experienced builders were already doing and hadn’t named. By mid-2026, coding agents had gotten capable enough to run multi-step work autonomously for minutes or hours. The bottleneck stopped being “what magic sentence do I type?” and became “what system keeps this agent pointed at the right work — and tells me when it’s actually finished?”

“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” — Addy Osmani, “Loop Engineering,” June 2026 (Google Chrome)

I want to be careful here, because the hype is loud and I’m learning this in the open like a lot of you. Osmani himself, in the same essay that named the thing, said he’s skeptical and that you have to watch token costs obsessively. The honest version of this story is not “prompting is dead.” It’s “prompting became table stakes, and a new layer opened above it.” Let me draw the layers, because they stack in a way that’s worth seeing clearly.

Figure 1. The progression: prompt (the words) → context (what the model sees) → harness (the environment one agent runs in) → loop (the iterating itself). Loop engineering is the newest floor, and it sits on top — it doesn’t delete the floors beneath it.

What a loop actually is, stripped of jargon

Forget the diagrams for a second. A loop is four moves on repeat: discover → act → verify → decide, running until a stopping condition is met. You used to be that loop. You were the thing standing between the agent’s steps — reading the output, catching the mistake, deciding what came next, telling it to try again.

Loop engineering puts a small system in that seat instead. You define a recursive goal — “make the test suite pass,” “triage every open issue and draft fixes,” “refactor this module and keep all behavior identical” — and the system iterates toward it. It inspects, makes a change, runs the checks, reads the result, and decides what to do next, without you pressing enter between steps.

The contrast with the old way is sharper than it sounds. A one-shot prompt treats the model as a code generator: ask once, get an answer, copy it out. A loop treats the work as a system that can run for minutes or hours, correcting itself against real signals instead of against your patience. By real signals I mean the automatic checks code already has: tests, type checkers (which catch when you hand a function the wrong kind of value), linters (which flag sloppy or broken code), and plain runtime errors.

The part every explainer skips: the verifier is the bottleneck

Here’s the line I wish someone had hit me with on day one. In any loop, the constraint is not the model. It’s the verifier. If the worker agent grades its own homework, you don’t have a loop — you have an expensive way to generate confident nonsense at 3 a.m.

Think about what autonomy actually requires. The moment you stop pressing enter between steps, something else has to decide whether the last step was good enough to build on. That something is the whole game. A well-known pattern is to put a separate model in the verifier seat — Anthropic’s “Building Effective Agents” writeup calls this evaluator-optimizer, which just means one model does the work and a second one checks it — so the agent that writes the code is not the one that decides the code is correct.

Figure 2. The four moves of a loop. The coral node — Verify — is the one that decides whether the whole thing works. Note it’s outlined and separate on purpose: the agent that acts should not be the agent that verifies, or the loop quietly drifts. Everything essential here is in this caption, not just the tap-popups.

This reframes what “getting better at AI” even means. The scarce skill is no longer phrasing. It’s defining what “good” and “done” mean in measurable terms — and then pinning those checks before the agent runs, not after it’s already burned your budget.

You’ve seen the dumbest version of this already

Before anyone said “loop engineering,” there was Ralph. In early 2026, Geoffrey Huntley described running a coding agent inside a plain while loop: feed the agent the same prompt against a written spec, let it pick one task and implement it, spin up a fresh instance, feed the identical prompt again. Repeat until done. He named it after Ralph Wiggum because it's, in his words, deterministically simple in an unpredictable world.

# The "Ralph" pattern — simplified, check current docs.
# The whole idea fits in a shell loop.
while ! checks_pass; do
  agent run --spec spec.md --pick-one-task   # act
  run_tests                                  # verify (separate from the agent)
done
notify "spec satisfied"                       # stopping condition met

In plain English, that snippet says: while the checks haven’t passed, let the agent do one task and run the tests; once they pass, tell me. You don’t need to read code to get the shape — that’s the whole point.

It looks too dumb to matter. But it contains every essential piece: a goal, an act step, a separate verify step, and a stopping condition. The fancy versions — sub-agents (smaller helper agents the main one spins up for side tasks), worktrees (separate copies of the codebase so two agents don’t trip over each other’s edits), and persistent memory — are elaborations on this skeleton, not departures from it.

The memory trick that makes loops actually run

There’s one piece that turns a one-off run into a loop, and it’s easy to miss. The model forgets everything between runs. Whatever it knew lived only in its context window — the limited scratchpad of text it can see at once — and that scratchpad is wiped each time. So the memory can’t live in the model. It has to live on disk.

The loop reads a file each cycle that holds what’s done and what’s next: a Markdown file, a task board, or a project file like CLAUDE.md or AGENTS.md (plain text files that sit in your project and tell the agent what it should always know). Anything outside the single conversation works. Osmani put it cleanly: the agent forgets, but the repo doesn't. This is also why those project files have quietly become team operating agreements — the loop reads them every run, so whatever you write there is what the agent always believes.

# progress.md — simplified; the loop reads this every cycle
## Done
- migrated auth module to new SDK
- fixed 3 failing integration tests

## Next
- [ ] add rate-limit handling to the client
- [ ] backfill tests for the retry path

## Never do   # guardrails the loop must respect
- don't touch the billing tables
- escalate to a human before any schema change

That little file is the spine. Without it you have a clever agent session. With it, you have something that can pick up where it left off — which is the difference between a demo and a system.

The honest counter argument: most of you don’t need this yet

I’d be doing exactly the hype-cycle thing this publication exists to avoid if I didn’t stop and steelman the other side. So here it is, made as strong as I can make it.

One: the people evangelizing loops have near-unlimited budgets, and you may not. Osmani flagged this himself — usage patterns “vary wildly if you are token rich or poor.” (Tokens are the units AI usage is billed in; being token-poor just means you’re paying close attention to the bill.) A loop that runs for an hour, retries, and spawns helpers can burn vastly more compute than a single good prompt. AlphaSignal ran a piece bluntly titled “Most Developers Do Not Need Agent Loops Yet,” and they’re not wrong. If your task is a 20-minute change you fully understand, a loop is a worse tool with a bigger bill.

Two: a badly designed loop multiplies a bad decision faster than a good one multiplies a good decision. When you’re in the loop pressing enter, you catch the wrong turn on step two. When you’re not, the agent confidently builds five steps on top of a mistake before anything checks it. Autonomy raises the stakes on verification precisely when you’ve removed the human who used to provide it.

Three: the term is days old. It might fragment — “loopcraft,” “harness engineering,” “agent orchestration” are all competing for the same idea. Building your identity around a label that may not survive the year is its own risk. The practice (designing verification and stopping conditions) is durable. The word might not be.

Where does that leave the steelman? Roughly here: loop engineering is real and probably where serious agent work is heading, but it is a tool for when a single agent is already the bottleneck — not a starter move. If you’re still learning what a good prompt and a clean context look like, building loops is sharpening a knife you don’t yet need. The honest recommendation is earn your way up the stack, don’t skip to the top floor because it’s trending.

What to actually practice this week

If you want to start moving toward this without setting money on fire, here’s the smallest useful version.

• Write “done” before you write anything else. Pick one repetitive task and define its stopping condition in measurable terms — a passing test, a rubric score, a specific output shape — before you give a single instruction.
• Separate the worker from the verifier. Never let the agent that makes the change be the one that decides the change is correct. Even a cheap second pass with a different model beats self-grading.
• Put the memory on disk. Keep a plain progress.md with Done / Next / Never-do sections. The loop reads it every run; that's what makes it a loop and not a one-off.
• Start read-only. Run your first loops where they can observe and propose but not commit. Grant write access only after your checks can reliably say “no.”
• Set a budget guard and a step cap. Decide the maximum spend and the maximum iterations up front. A loop without a ceiling isn’t autonomous — it’s unsupervised.
• Use the least autonomy that works. If a chain — a fixed sequence of steps that always runs in the same order (A → B → C) — solves it, don’t reach for a loop. Loops earn their cost only when the right path isn’t known upfront, like debugging, triage, or exploration.

The skill underneath the skill

For two years, “getting good at AI” meant getting good at asking. We collected prompt templates like trading cards. And that was never wrong — it was just the ground floor of a building we couldn’t see the rest of yet.

What loop engineering exposes is that the durable skill was never the phrasing. It was judgment about correctness — knowing what “done” looks like, knowing how to check it, knowing when to stop. The agents got good enough to write the prompts, and the moment they did, they handed that judgment straight back to us. The model can generate. It still can’t decide, on your behalf and against your standards, that the work is actually finished.

That’s the part that doesn’t get automated away. So whether the word “loop engineering” survives the year or not, the thing it points at is worth getting good at: not the perfect sentence, but the system that knows when the work is real.

If you’ve ever come back to a loop that ran overnight and found it built five confident steps on top of one wrong turn — tell me that war story in the comments. I’m collecting failure modes, and the ugly ones teach the most. And if this clarified where the leverage is actually moving, follow Think in AI Agents so the next one finds you.

Level up your skills with my Amazon eBooks

Get the The AI Agent Builder’s Playbook : Why AI Agent Projects Die in Production on Amazon.

Get the Copilot Studio for Architects: When to Use It, What It Really Costs, and How to Combine It with Pro-Code AI Agents on Amazon.