Is Prompting Dead? The Rise of Loop Engineering

Is Prompting Dead? What Actually Changed

"I don't prompt Claude anymore. My job is to write loops."

That line came from Boris Cherny — the head of Claude Code at Anthropic, the person who builds the tool millions of developers prompt every day. When the guy who ships the prompting interface says he's stopped prompting, it lands differently than another hot take on X. The quote went viral in June 2026, spawned a wave of "loop engineering" posts, and reopened a question the industry thought it had settled: was prompt engineering ever a durable skill, or just the visible layer of something bigger?

Prompting is not dead. But the unit of work is changing. Instead of a human crafting one instruction and reading one response, engineers now design systems where the AI generates its own next instruction — repeatedly, in parallel, against a verifiable goal — while the human checks in at the boundaries. That practice has picked up a name: loop engineering. Peter Steinberger put it bluntly: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." And Addy Osmani gave it the cleanest definition I've seen: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

Before deciding whether that's a revolution or a rebrand — and I'll argue it's mostly the latter — it helps to see where this sits in a much older story.

The Evolution of Programming: Seventy Years of Deleting Ourselves From the Loop

Every era of programming has the same plot: humans find the most repetitive thing they do, build a layer that automates it, and move up one level of abstraction. The layer below doesn't die — it gets absorbed.

Look at the pattern in the captions. At every stage, the thing that was "the job" becomes the thing the next layer generates automatically. Nobody writes assembly by hand anymore, but assembly didn't die — every binary you run is full of it. Compilers just made it a compilation target instead of a human artifact.

Andrej Karpathy saw the next rung coming in early 2023 when he wrote that "the hottest new programming language is English." That was the prompting era: natural language as source code, the model as compiler. What Cherny's quote signals is the rung after that — prompts themselves becoming a compilation target. You don't write the ten thousand prompts; you write the system that emits them.

The historical framing matters because it deflates the panic. "Is prompting dead?" is the same question as "is assembly dead?" in 1962. The answer then and now: no — it's being demoted from something humans write to something machines generate. The skill that dies is the artisanal version. The skill that survives is understanding the layer well enough to debug it when the abstraction leaks.

Prompting vs Looping: The Anatomy of Each

The two workflows look similar from a distance — text goes in, work comes out. The difference is in who closes the loop, and that one structural change cascades into everything else.

Here is prompting. Notice where the human sits: inside the cycle, load-bearing, on every single iteration.

And here is looping. The human writes two things — a goal and a loop — then steps outside the cycle entirely. The orchestrator spawns agents, a verifier checks their output against the goal, and the loop condition decides whether to go around again. The human's touchpoints shrink to the start and the end.

Strip away the boxes and the structural difference is small enough to fit in one sentence: prompting has a human as the loop condition; looping has a program as the loop condition. Everything else — the parallel agents, the verifier, the persistent state — is engineering built to make that swap safe.

That's also why the throughput math changes so violently. A human-closed loop runs at the speed of human attention: you can drive maybe one or two agent conversations seriously at once. A program-closed loop runs at the speed of the verifier: Cherny describes having loops running that prompt Claude and figure out what to do next while he's doing something else entirely. Same model, same prompts under the hood — the bottleneck just moved.

In practice, the loop-engineering stack that has emerged around Claude Code and Codex has five recurring parts, and it's worth knowing them by name because they map directly onto concepts I covered in What Is an AI Harness?: scheduled automations for discovery and triage, git worktrees for parallel agent isolation, skills files for codified project knowledge, MCP connectors for tool access, and subagents that separate ideation from verification. None of these are model capabilities. All of them are harness capabilities. The model didn't get a new superpower in 2026 — the scaffolding around it did.

Failure Modes: What Loops Break That Prompts Didn't

Loops don't just amplify output; they amplify everything, including the failure modes. Three deserve specific attention because they're qualitatively new — a solo prompter never hits them.

Divergence compounds silently. In a prompting session, a wrong turn gets caught in the next human read — your error bar is one response long. In a loop, a subtly wrong plan at iteration 2 becomes the verified-against assumption of iterations 3 through 40. If your verifier checks "do the tests pass" but the agent wrote the tests, the loop will happily converge on green checkmarks around broken behavior. The verifier is the whole ballgame: a loop is exactly as trustworthy as its stopping condition, and writing honest stopping conditions is much harder than writing prompts ever was.

Comprehension debt accrues at loop speed. Osmani's warning is the one I'd underline: loop engineering "doesn't eliminate human responsibility — it relocates it." When a loop lands 4,000 lines across six PRs overnight, someone still has to own that code in the 2 a.m. incident. Prompting kept you accidentally honest because you read everything on the way through. Loops remove that forced reading, and nothing automatic replaces it. The teams handling this well treat review capacity as the scarce resource and size their loops to it — not to the model's throughput.

Cost and runaway behavior. A human-closed loop has a natural budget: your patience. A program-closed loop will cheerfully burn tokens re-attempting an impossible goal forever if you let it. Real loop deployments need the boring stuff — iteration caps, spend ceilings, kill switches, and state that persists across runs so a restarted loop doesn't redo (or worse, redo differently) work it already finished.

Note: If you're building your first loop, make the verifier something the agent cannot influence — a test suite it can't edit, a lint config it can't touch, a human gate. An agent that grades its own homework converges on flattery, not correctness.

None of these are reasons to avoid loops. They're the reason "loop engineering" is a real discipline rather than a lifehack — the same way the shift from LLM calls to agents forced everyone to learn about tool schemas and context management whether they wanted to or not.

My Take: A Loop Is Just a Prompt With a Scheduler

Now the part where I disagree with the framing, if not the practice.

Everything above is real — the throughput gains, the new failure modes, the five-part stack. What I don't buy is the idea that looping is a different thing from prompting. Look at what a loop actually is when you flatten it:

A loop is a prompt with three properties bolted on: a persistence condition (keep going until the goal is met, not until the response ends), a delegation grant (you may spawn and manage other agents), and a verification obligation (check your own work against the goal before coming back). That's it. It's still an instruction, written in natural language or thin scaffolding around natural language, expressing intent to a model. When I write a loop, I am prompting — I'm just prompting the orchestrator once instead of prompting the worker forty times, and I'm allowing the AI to deploy multiple agents and monitor them until the final goal is achieved rather than reporting back to me after every step.

The reason "my job is to write loops" resonates isn't that prompting died. It's that the interesting prompt moved up a level, exactly like the interesting code moved from assembly to C to Python. Nobody announced that "programming is dead" when compilers arrived; we just stopped calling instruction selection "programming" and reserved the word for the new top layer. The same renaming is happening now in real time. In two years, "prompting" will probably mean what "writing loops" means today, and someone will coin a new term for whatever sits above it — fleet engineering, goal engineering, pick your future buzzword.

So: is prompting dead? The one-shot, artisanal, comma-tweaking version — yes, that's a compilation target now, and good riddance. But the underlying skill — compressing intent into language precise enough that a machine can act on it unsupervised — has never mattered more. A loop that runs unattended for six hours is the highest-stakes prompt you will ever write, because nobody is there to catch the ambiguity on turn two. The prompt didn't die. It just stopped forgiving sloppiness.

The question worth carrying forward isn't whether to prompt or to loop. It's this: as the trust horizon stretches from one response to one overnight run, what's your verifier — and would you bet a production incident on it?

References

I use AI tools to help research and draft posts. The ideas, opinions, and takes are mine. Verify anything technical or time-sensitive before acting on it.