In June 2026, two people with unusually good vantage points posted what amounts to the same sentence. Peter Steinberger: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Boris Cherny, who created Claude Code: “My job is to write loops.” Both lines are quoted in Addy Osmani’s essay that gave the shift its name, loop engineering, and it would be easy to file them under aphorism if there were not a small, concrete feature sitting underneath: you hand the agent a definition of done, and it keeps working, turn after turn, until that definition actually holds. This is a short guide to that feature, what it does, why it works, and how to fold it into an ordinary day of work.
The feature under the slogan
Every prompt you send already runs a loop. The agent gathers context, takes an action, checks the result, and repeats until it judges the work finished, a cycle the Claude Code team calls the agentic loop and defines as “agents repeating cycles of work until a stop condition is met”. The weakness hides in the word judges: the model doing the work also decides when to stop, and left to itself it stops at “looks done”, which is not the same as done.
A goal feature changes who decides. In Claude Code, typing /goal all tests in test/auth pass and the lint step is clean sets a completion condition. After every turn, a separate small model reads the conversation and rules on whether the condition holds. If not, the agent starts another turn, with the judge’s short reason as its steer; if yes, the goal clears and the session hands control back to you. The work and the grading are done by different models, which matters more than it sounds. As Osmani puts it, “the model that wrote the code is way too nice grading its own homework.”
The idea is older than the buttons. Geoffrey Huntley’s 2025 “Ralph Wiggum” technique was literally a bash while loop feeding the same prompt to an agent over and over, and it worked embarrassingly well. What Claude Code’s /goal and its equivalent in OpenAI’s Codex add is the missing half: a stop condition, checked by fresh eyes, so the loop knows when it is allowed to end. Alongside goals, most tools also ship a time-based sibling (/loop 5m check the deploy re-runs a prompt on an interval, or picks its own interval if you omit one), which trades “until this is true” for “every so often”.
Write the check, not the wish
Using goals well collapses into one skill: compressing “done” into something checkable. The Claude Code docs are specific about what survives contact with many turns of work. A durable condition has one measurable end state (a test result, a build exit code, a file count, an empty queue), a stated check that tells the agent how to prove it, and any constraints that must hold along the way. Add a bound too, such as “or stop after 25 turns”, so a stuck loop costs you turns rather than an evening.
/goal every call site of the old client compiles against v2,
`npm test` exits 0, no file outside src/api and test/api changes,
or stop after 25 turns
The reason for all this precision is mechanical, not stylistic. The evaluator never runs commands itself; it can only judge evidence the agent has surfaced in the conversation. “The code is clean” gives it nothing to rule on, while “npm run lint prints zero warnings” lands in the transcript as actual command output. Anthropic’s guidance says it plainly: the more quantitative the checks, the easier it is for the agent to self-verify. A goal you cannot phrase as a check is not a goal yet; it is a wish, and the loop will happily burn tokens orbiting it.
Rule of thumb: if the evaluator can’t see it, it didn’t happen. Write conditions that force the proof into the transcript.
Does it actually work?
Nobody has run a controlled study of goal features against plain prompting yet; the buttons are too new. The mechanism they package, though, has real experimental backing, and it rhymes with everything above. Reflexion showed agents that retry against evaluation feedback solving 91% of HumanEval problems where single-pass GPT-4 managed 80%. Self-Debugging made the conditionality explicit: letting a model iterate on unit-test output lifted code-generation accuracy by up to 12%, but only 2 to 3% on a benchmark with no tests to run. Stanford’s Large Language Monkeys found the same cliff at scale, with repeated attempts lifting SWE-bench Lite solve rates from 15.9% to 56% when tests judged the answers, and plateauing in domains without a verifier. And Huang et al. found that models asked to self-correct without external feedback often make correct answers worse, which is the experimental case for /goal’s separate grader.
Practitioner evidence points the same way while stopping short of proof. Kun Chen’s self-measured validation pipeline caught bugs in roughly 68% of 267 agent changes before they shipped, field data for the same lesson, and every loop Boris Cherny discloses terminates on an external check, never on the model’s own say-so. So the claim with evidence behind it is narrow: loops pay exactly when the check is real. The grander one, that goals make you ship more, is still folklore awaiting its experiment; the nearest high-quality RCT, METR’s 2025 developer study, found AI-assisted developers 19% slower while believing themselves 20% faster, a standing argument for measuring instead of trusting the vibe.
Fitting it into a working day
Anthropic’s guide sorts loops by a single question, and it is the right one to ask before reaching for any of them: what should trigger the next unit of work?
- A plain prompt when you can describe the diff in a sentence. Setting a goal for a one-line fix is ceremony.
- A goal when the work is substantial and the end state is verifiable: migrating a module until every call site compiles and tests pass, working a labeled issue backlog until the queue is empty, splitting an oversized file until each piece fits a size budget, or pushing a Lighthouse score over a threshold (Anthropic’s own example).
- A loop when the work recurs or the world changes on its own schedule: keeping a PR green while you do something else, watching a deploy, morning triage.
- A scheduled routine (cloud or CI) when the work should not depend on your laptop being open at all.
Start smaller than feels ambitious. Pilot a goal on one module before pointing it at the repo, keep the turn bound in the condition, and glance at the token spend afterwards; an unbounded loop wrapped around a vague condition is the expensive way to find out the condition was vague. Once a goal earns your trust interactively, it also runs headless (claude -p "/goal ..."), which is the bridge from “feature I invoke” to “system that runs without me”.
Staying the engineer
The previous post on working with coding agents argued that the single highest-leverage habit is giving the agent a check it can run. Goal features are that habit turned into machinery, and they inherit its limits. A goal can only lean on the checks your codebase actually has, so a thin test suite means a condition with nothing to grip. And clearing the evaluator is not the same as being right, because the evaluator only sees what the agent chose to surface. Review still happens, just at the end of the loop instead of inside it.
Osmani’s essay carries the warning worth keeping: identical loops produce opposite results depending on whether they were built by someone mastering the domain or someone avoiding it, and the fastest way to rot your understanding of your own system is to stop reading what the loop produces. Keep reading the output, keep owning what merges. The agent runs the loop; you still draw the finish line.
Sources & further reading
- Anthropic, “Getting started with loops” — the Claude Code team’s taxonomy of turn-based, goal-based, time-based, and scheduled loops, with stop-condition and token-spend guidance (also published as an X article).
- Addy Osmani, “Loop Engineering” — the essay that named the shift, sources the Steinberger and Cherny quotes, and warns about comprehension decay.
- Claude Code docs: keep Claude working toward a goal — evaluator mechanics and the anatomy of a durable condition.
- Claude Code docs: run prompts on a schedule —
/loopintervals, self-paced loops, andloop.md. - Geoffrey Huntley, “Ralph Wiggum as a ‘software engineer’” — the bash while-loop ancestor of every goal button.
- Shinn et al., “Reflexion” (NeurIPS 2023) — agents retrying against evaluation feedback reach 91% pass@1 on HumanEval versus 80% for single-pass GPT-4.
- Chen et al., “Teaching Large Language Models to Self-Debug” (ICLR 2024) — iterating on unit-test output gains up to 12%, shrinking to 2-3% where no tests exist.
- Brown et al., “Large Language Monkeys” (2024) — repeated attempts lift SWE-bench Lite from 15.9% to 56% with a test-based verifier, and plateau without one.
- Huang et al., “Large Language Models Cannot Self-Correct Reasoning Yet” (ICLR 2024) — intrinsic self-correction fails and can degrade correct answers; external feedback is what helps.
- METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” — the RCT in which developers using AI took 19% longer while believing they were 20% faster.
- Kun Chen’s agentic engineering workflow — self-measured field data behind the 68%-of-changes-had-bugs figure, summarised by ByteByteGo; Boris Cherny’s disclosed loops are compiled at howborisusesclaudecode.com.