01Why “AI can write” is no longer the point

For two years the headline was that AI could generate. Code, copy, captions — it could produce. That stopped being the interesting part. The shift in 2026 is that AI can now run itself against a goal, on a schedule, without you in the chair — and your leverage stops being how well you prompt and starts being how well you design the loop.

Think about where time actually drains away. It is rarely the high-judgment work. It is the repeatable work — the inbox, the recurring report, the first-pass screen on every task, the queue you dread. That is exactly the work a well-designed loop can absorb.

And here is the uncomfortable truth that names the whole discipline: with single-prompt chat, you are the loop — you check the work and decide the next step every single time. Loop engineering is stepping out of that seat and building the small system that does the prompting for you.

02What loop engineering actually means

The term went mainstream through one tiny post. On June 8, 2026, Peter Steinberger — creator of OpenClaw, now at OpenAI — posted two sentences that reached millions of views: you shouldn’t be prompting coding agents anymore; you should be designing loops that prompt your agents. No diagram, no repo. The AI-coding timeline argued about it for a week.

Boris Cherny of Anthropic, who leads Claude Code, was widely quoted alongside it, and Addy Osmani’s essay structured the idea and gave it the name “loop engineering” in June 2026. A clean definition that survives the hype:

What’s genuinely new isn’t just “repeat a prompt.” In spring 2026 both Codex and Claude Code shipped a /goal command that runs until a validator confirms the task is done, and Anthropic engineers describe running iterative loops where Claude observes, plans, acts, and reflects over hours or days. The primitives that were improvised in scripts last year are now shipping features.

03/loop vs /goal: engine vs compass

These two commands are often confused. The cleanest mental model: /loop is the engine, /goal is the compass. /loop drives recurring cycles of assess-act-verify, while /goal gives the agent a finish line it can check and stop on; put together, Claude has both a compass and an engine — it knows where it’s going and it knows to keep moving.

The /goal command was added to Claude Code in version 2.1.139 during the week of May 11, 2026, and does not exist in earlier versions — type /goal clear to stop early. Check your version first.

04The completion condition: how to define “done”

This is where most loops fail. You describe a verifiable end state, not a list of instructions — Claude figures out how to get there, and an independent checker confirms when it has. A vague goal (“tidy it up”) produces a confident-sounding mess. A sharp goal produces finished work.

Three things turned the Downloads example into a good finish line, and they generalize to every goal you’ll ever write:

The pattern beneath all three: a measurable end state, an explicit proof method, and constraints you must not violate. If you can’t state those, you don’t have a loop — you have a wish.

05Self-verification: why the checker is the whole game

Here is the single most important idea in this article. A model that wrote the code and is also asked whether the code is correct consistently over-reports success — so /goal uses a separate, faster model specifically tasked with checking the completion condition after each turn. The builder and the judge are different model instances. No grading its own homework.

That is why practitioners obsess over Boris Cherny’s fifth tip. Among his tips for running Claude autonomously for hours or days, the one that matters most is “self-verify end to end” — a loop is only as trustworthy as its ability to check its own work. In /goal the evaluator is automatic; in custom workflows you must design it in explicitly.

One more piece of hygiene for parallel work: when multiple sub-agents touch the same repository, Claude Code’s isolation:worktree setting spawns a fresh git checkout for each sub-agent that cleans itself up, preventing agents from overwriting each other’s changes mid-execution.

06The five-part loop anatomy

Strip away the hype and every production loop is the same six labels. Practitioners name the pieces that turn an agent from a clever assistant into a useful background process — a trigger, a scope, an action, a budget, a stop, and a report. Write your loop as this spec before you touch a terminal:

If any row is blank, the loop is unsafe to deploy. The blank row is exactly where the runaway cost or the silent error will appear.

07Goal-oriented design, step by step

Here is the discipline that keeps long autonomous runs from going off the rails.

08Worked example: a content automation loop

The same anatomy transfers cleanly to digital marketing automation — SNS, X, and YouTube workflows. The trick is the same as in code: don’t just generate, verify. A doer drafts; a separate checker scores; only what passes moves forward.

Two design choices make this safe. First, the checker is a different model from the writer — no self-grading. Second, the loop queues for human review and never auto-publishes. Boris Cherny’s framing that everyone becomes a builder — designers, finance, chief-of-staff all shipping work through loops — applies here too: the content owner stops being the person who writes each post and becomes the person who designs the loop that produces them.

09Budget guards & the 10x token problem

The biggest risk in autonomous loops is not bad output — it’s the invoice. Every tool call in an agentic loop adds context that gets re-sent to the model on every subsequent call, so by the 20th iteration the cumulative input per call can exceed 50,000 tokens. Cost compounds silently.

The numbers are sobering. At Opus 4.8’s input pricing, a single late-loop step can cost roughly $0.25, and a 200-iteration autonomous session on an open-ended task can cost $80 or more — which is why the June 15, 2026 Agent SDK billing change separated automated workloads onto their own credit pool. Flat-rate subscriptions were never designed for agent-level compute.

Addy Osmani’s closing line is the right north star: build the loop, but build it like someone who intends to stay the engineer — not just the person who presses go.

10Pros, cons & honest limits

11Voices from the field

12Your first loop in under an hour

Don’t architect an empire. Pick one task you repeat every week and write three lines: when it starts, what “done” looks like, and how the AI proves it’s done. That sentence is your entire spec.

Then try it on something small and harmless first — sorting a folder, drafting one recurring report — and watch the first iteration. That feeling, the agent driving itself to a finish line and stopping on its own, is the whole point. Once you trust the check, you add the budget guard, then the schedule. Small loop first. Empire later.