Stop Prompting Your Agent. Write the Loop That Prompts It
Sometime in the second week of June 2026, Boris Cherny, who runs Claude Code at Anthropic, said something that got passed around enough times to lodge in my head:
"I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops, and this is the transition we're going to see for the rest of the year."
My first reaction was the cynical one. Great, another "prompt engineering is dead, here's the new thing" take, right on schedule. We get one of those every few months.
But I'd already been doing a sloppy version of this for weeks without a name for it, so the take landed differently. I had a little bash script babysitting a LangGraph agent that kept dying on a flaky upstream API, restarting it, re-reading a TODO file, and committing whatever it managed to finish. It was ugly. It worked better than me sitting there re-typing "ok now continue" forty times. Turns out that ugly script has a name now, and a surprisingly coherent theory behind it.
What loop engineering actually is
Addy Osmani at Google wrote the essay that named the thing on June 7, 2026, pulling together what Cherny and others had been saying. His definition is the one worth memorizing because it's blunt:
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
That's it. The unit of work stops being the prompt and becomes the loop: define a goal, let the agent inspect the world, make a change, run a check, read the result, decide the next move, and repeat until some condition says stop.
If you've built agentic systems, this isn't new mechanically. It's the same act → observe → decide cycle that ReAct described back in 2022, the thing AutoGPT cargo-culted in 2023. What's new is the posture. You're no longer in the conversation. You're not the one feeding it the next instruction. You're standing outside, building the machine that does the feeding.
Here's the difference stated plainly, because it's easy to nod along and miss it:
Prompt engineering is tactical. You optimize one turn. You're inside the loop, and the loop's quality is bounded by how fast you can read and type.
Loop engineering is structural. You optimize the cycle. The loop runs while you sleep, and its quality is bounded by how well you designed the exits and the verification.
The whole shift is just where you stand relative to the cycle:
Steinberger put the same idea more aggressively: you shouldn't be prompting coding agents anymore, you should be designing loops that prompt them. I think the aggression is half marketing and half correct, which I'll get to.
The dumbest version works, and that's the point
Before the polished framing showed up, there was Ralph.
Geoffrey Huntley named and documented a technique that is, at its core, this one line:
# The entire "framework"
while :; do cat PROMPT.md | claude-code ; done
That's the Ralph Wiggum loop. Named after the Simpsons kid because it's, in Huntley's words, "deterministically bad in an undeterministic world." It just keeps going. No memory of the last run, no clever orchestration, no state machine. It reads the same prompt file every iteration and bumbles forward.
The trick that makes it not-insane is where the state lives. Each iteration gets a fresh context window. The agent remembers nothing. So the file system becomes the memory:
# State doesn't live in the conversation. It lives on disk.
# - @fix_plan.md -> what's left to do
# - @specs/* -> what "done" means
# - git history -> what already happened, and a way to undo
git add -A && git commit -m "loop iteration: implemented auth middleware"
The plan file shrinks as work gets done. Git is both the audit trail and the safety net. The context window resets every loop, which sounds like a bug and is actually the feature, because it means context rot never accumulates. Each iteration is clean.
The numbers people quote for this are genuinely funny. Huntley says he delivered an MVP for a \(50,000 contract for \)297 in API spend. A team at a Y Combinator hackathon ran six Ralph loops in parallel git worktrees and shipped six framework ports overnight, around 1,000+ commits and ~$600 of API. For anyone building from Kathmandu, where "just throw more engineers at it" was never the cheap option, that cost structure is the part that actually changes the math.
By mid-June 2026, Claude Code shipped /loop and /goal as native commands. The bash hack became a feature. /loop re-runs a prompt on a cadence, /goal keeps iterating until a verifiable condition is met. The hand-rolled thing I was embarrassed about became supported.
The anatomy, if you want to build a real one
Ralph is the toy that teaches the idea. A loop you'd actually trust with a production repo needs more scaffolding. Osmani's essay lays out the building blocks, and after running a few of these myself, I'd say they're the right list:
Automations — something that triggers the loop and finds work (a schedule, a webhook, a queue), so you're not the trigger.
Worktrees — isolated environments (
git worktree) so parallel agents don't stomp each other. This is the unlock for running many loops at once.Skills — codified project knowledge in
SKILL.mdfiles so the agent doesn't relearn your conventions every run.Plugins / connectors — MCP and friends, so the loop can touch your actual tools instead of hallucinating about them.
Sub-agents — split the work: one agent ideates, one implements, one verifies. They don't share a brain, which is good, because the verifier shouldn't be the implementer marking its own homework.
And the one Osmani flags as non-negotiable, sitting underneath all of it:
- State / memory — external storage (markdown, a Linear board, a DB) where progress survives between runs. Models forget. The loop only works if something remembers for them.
Notice that exactly one of these six is about the prompt. The rest is plumbing, isolation, verification, and memory. That ratio is the job now. The prompt is a config file. The loop is the program.
Where it falls apart (the part the hype skips)
Here's where I get off the marketing train.
The same essays that sell you loops are unusually honest about how they rot, and there's a great word for the failure: loopmaxxing. It's the loop-era version of tokenmaxxing, the status game of bragging about how many tokens you burn. Loopmaxxing is believing that if the loop just runs long enough, any problem gets solved. It doesn't.
A few ways I've watched (or read about) loops eat money and produce nothing:
No real exit condition. "Improve the UX" is not a stopping condition. A compiler passing is. Unit tests going green is. If you can't write the check as code, the loop has no idea when to quit, and it'll happily run until your bill says stop. The good loops replace human approval with deterministic exits: linters, type checkers, test suites. The bad ones replace it with vibes.
Local minima. This one surprised me. Even on deterministic tasks, loops get cagy. Karpathy described agents nudging a learning rate by a fraction of a percent across dozens of iterations to claim a nominal win, instead of trying a bold redesign. He blames RLHF rewarding safe, conservative moves. The loop optimizes what's measurable and fast to confirm, and quietly avoids the risky rewrite that would actually help. You get motion, not progress.
Comprehension debt. This is the scary one and the reason I won't fully hand over the wheel. Code ships faster than your understanding of it grows. After a long unattended run you can have a green test suite and a thousand commits and zero map of why any of it is shaped the way it is. Huntley himself says he wouldn't run Ralph on an existing codebase, and that you should expect roughly 90% completion before a human has to step in. That last 10% is where the judgment lives, and it doesn't automate.
Osmani's framing of this is the line I keep coming back to: designing loops with judgment accelerates progress, designing them to avoid thinking accelerates decline. Same structure, opposite outcomes. The loop is an amplifier. It makes a good engineer faster and a lazy one dangerous, quicker.
So is this real or is it a rebrand
Bit of both, honestly.
The mechanics are old. Anyone who's wired up a LangGraph state machine or run an agent against a tool registry has built a loop. Calling it "loop engineering" is partly just giving a name to something practitioners already did.
But names matter, because they move where you put your attention. When I think "prompt engineering," I fuss over wording. When I think "loop engineering," I fuss over the things that actually break in production: the exit condition, the verifier, the memory store, the worktree isolation, the cost ceiling. The second list is a much better use of my time. The rename is doing real work even if the code underneath rhymes with 2022.
My actual take, after living with it: the people saying "stop prompting entirely" are overshooting. You still prompt. You prompt less often and at a higher altitude, and you spend the freed-up time building the harness around it. The win isn't that humans leave the loop. It's that humans move to the edge of the loop, where the leverage is, and let the boring middle run itself.
The script I was embarrassed about was the right instinct. It just needed an exit condition and someone reading the diffs.
What's the dumbest loop you've left running overnight, and did it work?
Sources: Addy Osmani — Loop Engineering · Geoffrey Huntley — Ralph Wiggum as a software engineer · Boris Cherny quote · bdtechtalks — Demystifying loop engineering, avoid loopmaxxing · ReAct paper (2022)
