Loop Engineering: Why You Should Stop Prompting

TL;DR

• Prompting turn-by-turn is now the bottleneck. The point of control moved from writing prompts to designing the system that prompts the agent.
• A loop is a recursive goal: a purpose plus a verifiable stop condition. Plain version: “cron plus a decision-maker in the body.” It stops when a verifiable condition holds; time is only the cap.
• The harness was the floor. A loop is that floor feeding itself. The closing checklist tells you whether yours is ready for one.

On June 7, Peter Steinberger told roughly 2.2 million viewers to stop prompting coding agents, and the timeline split in half. The fight that followed is the best evidence I’ve seen that loop engineering is arriving as a discipline faster than its definition.

“Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

The replies were a brawl. Matthew Berman summarized the state of shared knowledge in one line: “nobody knows but him and boris.” A skeptic needed even fewer characters: “Cronjobs have funny re-branding rn.” Both camps were reacting to the same gap, a claim with enormous reach and no agreed definition behind it.

Prompting turn-by-turn is now the bottleneck, not the model, and the point of leverage has moved from writing prompts to designing the loop that prompts the agent.

If you spent the past year building a harness, the stakes are concrete. Either this is the next era of the arc you’re already on, or it’s a rebrand you can ignore for six more months. By the end of this essay you can tell which it is for your own setup, with a six-item check you can run in an afternoon.

The Four Eras: Prompt, Context, Harness, Loops

Each era of working with coding agents raised the level where skill pays: from the words in a single prompt, to the context the agent reads, to the environment the agent runs in, to the system that runs the agent. The era you operate in decides what your best hour is worth.

This post is an explicit continuation of our harness engineering pillars. Era 1 hunted for magic phrases. Era 2 curated context: CLAUDE.md and docs, the right facts in front of the model. Era 3 built the harness: skills, hooks, and verification around one agent. Era 4 is loops: the system that runs that agent against a goal, on a schedule, without you in the prompt seat.

Put differently, the harness was the floor, and a loop is that floor running on a timer, feeding itself. Era 4 doesn’t replace Era 3; it wraps it. That’s why the readiness question at the end of this essay is about your harness rather than loop tooling.

The Post That Started the Brawl

One post on June 7 told 2.2 million people to stop prompting coding agents, and the replies proved that almost nobody could say what should replace it, except the person who built Claude Code. That asymmetry, reach without shared definition, is the real story of the wave.

Matt Van Horn collected the fight in “WTF Is a Loop? Peter Steinberger vs. Boris Cherny”, an X article that pulled 3.4 million views of its own. The anatomy is worth a minute. Matthew Berman, who interviews AI builders for a living, conceded the definition gap outright. Skeptics piled on with cron jokes. Buried in the noise, @trashpandaemoji offered “it’s continuous orchestration loops that oversee other threads/agents,” which turned out to be the correct answer.

Then came the receipt. Boris Cherny, the creator of Claude Code, via the same article:

“I don’t prompt Claude anymore… my job is to write loops.”

He attached numbers: “Last 30 days, 100% of my contributions to Claude Code were written by Claude Code. 259 PRs.” He deleted his IDE in November 2025. For a skeptic, this is the load-bearing fact in the whole episode. It’s the tool’s own creator, on his own repo, with a count you could audit.

Key insight: Boris Cherny shipped 259 PRs to Claude Code in 30 days, 100% written by Claude Code itself, per Matt Van Horn’s June 8 article.

What Loop Engineering Actually Means

A loop is a recursive goal: you define a purpose and a verifiable stop condition, and the system iterates agents against it until the condition holds — without you prompting each turn.

That’s the canonical definition this series uses for all nine parts: a purpose, a verifiable stop condition, and iteration you don’t supervise turn by turn. Van Horn’s plain version is shorter and survives scrutiny just as well: “cron plus a decision-maker in the body.”

Two parts of the definition carry the weight. Purpose is what the system exists to make true, stated precisely enough that progress toward it is observable. The verifiable stop condition is stricter: it must be checkable by a machine or by a different model. The worker’s own claim of done never qualifies, for reasons the next two sections make concrete.

Loop engineering also didn’t appear in one viral week; the lineage runs five stages across four years. ReAct formalized reason-plus-act in academia in 2022, the loop as a paper. AutoGPT shipped the loop without verification in 2023 and famously flailed. Ralph arrived in July 2025, the dumbest loop that works, with fresh context on every lap. /goal productized stop conditions in spring 2026, Codex in April and Claude Code v2.1.139 in May, with a separate model grading the condition. Orchestration loops closed the arc in June 2026: loops that oversee other loops, the natural extension of multi-agent setups.

Credit where due: Simon Willison named the skill in September 2025, months ahead of the wave, and Addy Osmani’s “Loop Engineering” essay is the synthesis this section openly leans on. Every system in that lineage decomposes into the same five building blocks plus a memory spine, which is exactly what Part 2 of this series takes apart.

Key insight: The lineage runs ReAct (2022) to AutoGPT (2023) to Ralph (July 2025) to /goal (spring 2026) to orchestration loops (June 2026). Four years of convergence preceded one loud week.

Aren’t Loops Just Cronjobs Rebranded?

Mostly, yes, and the honest version of this essay concedes it up front: the dumbest working loop is one line of shell, and it’s nearly a cron job. The difference is what sits in the body, and the rest of this section is about that one organ.

Steelman the skeptics properly, because they own most of the parts. Scheduled execution: cron has had it since the 1970s. Retries: cron. State on disk between runs: cron plus a file. Geoffrey Huntley’s Ralph, published July 14, 2025, shows how thin the line really is:

while :; do cat PROMPT.md | claude-code; done

Point that at a PROMPT.md describing a goal and it grinds out real work, lap after lap, with fresh context each time. Squint and it’s a cron job with a strange payload.

Where the two diverge is what happens inside the body. Cron runs a fixed script and stops when the script exits; it can’t tell a finished project from a broken one. A loop evaluates a goal: something in the body reads the current state of the repo, decides the next action, and judges whether done has happened. A cron job cannot notice it is finished. A loop’s entire identity is noticing. Van Horn’s plain definition earns its keep here, because “cron plus a decision-maker in the body” concedes the skeleton and names the one organ cron never had.

Key insight: The minimal viable loop is one line of shell. Geoffrey Huntley published it as Ralph on July 14, 2025, with fresh context per iteration as the only trick.

A Loop Stops on a Condition, Not on a Clock

“Run it day and night until the feature is done” is the anti-pattern. A loop stops when a verifiable condition holds; time is only ever the cap. Anthropic’s engineering guidance from November 2025 documents what happens when teams get this backward.

People hear “loops” and picture an agent grinding unattended through the night. Anthropic’s failure-mode list for long-running agents exists precisely because that picture fails: premature victory declarations and fake-done features, agents reporting success on work that does not hold. Unverifiable done doesn’t degrade gracefully. It produces confident wreckage.

A contrast pair makes it concrete.

Bad: “run until the feature is done.” Whose judgment? The worker’s own claim.

Good: “iterate until this failing test passes, capped at N runs.” Machine-checkable and bounded.

Every serious system caps iterations anyway. The cap is a safety rail; the condition is the goal; confusing the two is how you wake up to a branch full of confident garbage. Part 3 of this series is entirely about designing stop conditions, because they are the hardest part to get right.

Key insight: Anthropic’s November 2025 guide to long-running agents lists premature victory and fake-done features as documented failure modes; the fix is a stop condition someone other than the worker can check.

What Changes About Your Job, and What Doesn’t

The prompting moves into the system; the judgment doesn’t. You design the loop, define what done means, decide what it may touch, and review what comes out. Verification stays yours, and Boris Cherny’s own setup, loops on a five-minute cadence paired with explicit self-verification, makes that split visible.

What changes is the repetitive half. You stop typing “now fix the tests” for the fortieth time. Your decisions move up a level: what the loop is for, what counts as done, what it is allowed to touch. Cherny runs a recurring /loop 5m /babysit command so the checking happens on a cadence instead of on his attention span.

What doesn’t change is verification. A loop that grades its own homework is the failure mode every source in this essay converges on, from AutoGPT’s flailing to Anthropic’s fake-done list. We’ve hit it in our own harness: a maker agent in the content pipeline behind this site once fabricated a plausible CEO quote, passed its own self-check, and only an independent fact-checker pass caught it before publish. Small blast radius, same organ failure. Cherny is blunt about the countermeasure: “give Claude a way to verify its work”, a practice he credits with a 2-3x quality difference. Our self-verification loop post is the direct prequel to this series; the discipline it describes is what a loop runs without you watching.

One sentence on Part 9, stated plainly because it matters: the same loop that multiplies a careful engineer’s output multiplies a careless engineer’s slop, and the loop can’t tell the difference.

Key insight: Boris Cherny attributes a 2-3x quality difference to one rule: “give Claude a way to verify its work”.

Is Your Harness Ready for a Loop?

A loop amplifies whatever harness it wraps, and if the harness isn’t ready, the loop automates the gaps at machine speed. Six checks, each answerable in about 10 minutes against your own repo, tell you which of the two you have, and the scoring at the end is deliberately blunt.

• Conventions are written down. Do project conventions live where an agent reads them, in CLAUDE.md or skills, or do they live in your head?
• Non-negotiables are mechanical. Are hooks enforcing the rules that must never break, or do you catch violations in review?
• Done is machine-checkable. For the work you would loop, is there a failing test, a lint gate, or a schema check that defines done?
• State survives a dead session. Does progress live in a file the next run reads, or does it die with the context window?
• Two agents can share the repo. Can two agents work in your repo without colliding, via worktrees or equivalent?
• You know your caps. Iterations, cost, wall-clock time: can you name the number for each?

Scoring is blunt. If items 1 through 3 fail, build the harness first; the senior developer’s guide to harness engineering is where to start, and no loop will save you in the meantime. If 1 through 3 pass and 4 through 6 fail, you are exactly where this series picks up: Parts 4 through 6 cover state, parallel agents, and caps.

FAQ

What is loop engineering?

Loop engineering is designing a recursive goal for a coding agent: a purpose plus a verifiable stop condition, which the system iterates against until the condition holds, without a human prompting each turn. The plain version, credited to Matt Van Horn: cron plus a decision-maker in the body.

Is a loop just a cron job?

No. Cron runs a fixed script on a schedule and stops when the script exits. A loop adds a decision-maker in the body and a verifiable stop condition: it reads current state, picks the next action, and stops only when done is provable.

Should I stop prompting and build loops now?

Only if three gates pass: the task repeats, done is machine-checkable, and your harness clears the six checks above. In that case, start with one loop around one verifiable goal. Otherwise build the harness first, because a loop around a weak harness automates its weaknesses.

The Floor, Running

The thesis is earned now: prompting turn-by-turn is the bottleneck because the levels above it exist and work. The harness you built was the floor; a loop is that floor running on a schedule, feeding itself toward a condition you defined. The lineage is four years long, and the skeptics are right about everything except the one organ that matters.

On Monday, run the six checks against your repo. Pick one recurring task with a machine-checkable definition of done. Then stop. Don’t build anything yet, because Part 2 covers the anatomy before the assembly.

Honest limit: we’re at the start of this arc ourselves. The harness experience behind this site is real; the loop experience is being earned in public, and Part 7 of this series will document whatever breaks along the way. If this essay only stops you from wrapping a loop around a harness that was not ready, it did its job.

What to Read Next

• Anatomy of a Loop: Five Building Blocks and One Spine (Part 2, upcoming): the decomposition this post previews, one building block at a time.
• Harness Engineering with Claude Code: the floor this series builds on.
• The Claude Code Self-Verification Loop: the verification discipline loops depend on.