“Stop writing prompts” — the phrase is spreading through AI circles.
From Boris Cherny, creator of Claude Code, to Peter Steinberger — creator of OpenClaw, now building personal agents at OpenAI — to Addy Osmani, the Google engineer who named the movement, the people at the front all say the same thing.
Cherny says he barely writes prompts by hand anymore: an agent writes prompts for Claude, and he talks only to the “meta Claude” coordinating everything. He even predicted that ten years from now, loops will be among the work he’s proudest of. Steinberger went further: stop writing prompts for coding agents — design the loops that feed them. He demonstrated live: Codex waking every 5 minutes, maintaining a repository and dispatching tasks, part of the work landing fully autonomously.
The popular consensus says AI coding equals writing good prompts. This group’s consensus: prompts are not dead — they are degenerating from a profession into a component. The system beyond the prompt — the loop — is where the real differentiation lives. And recently, the Claude Code team codified the trend in an official blog post, defining four loop types and setting engineering conventions for “agents that work on their own.”
The Core of a Loop Is Not Running — It Is Stopping
In Claude’s official definition, a loop is “an agent repeating work until a stop condition triggers.” Simple — until you notice that a year of debates about “AI autonomy” was really about this: making AI run is easy; making it run in the right direction and then stop is hard.
An ungated loop falls into two familiar traps. One is burning through tokens — Steinberger calls himself “the man with unlimited tokens” because free tokens are an OpenAI employee perk; the rest of us lack the benefit. The other is subtler: the agent that “seems to progress while spinning in place” — editing the same file repeatedly without ever producing a newly passing test, confidently perfecting a wrong solution.
The engineering community’s consensus is direct: loops are powerful and dangerous without gates. A well-designed loop installs three defenses first: a done condition (machine-checkable, like all tests green), a hard ceiling (max iterations and max spend), and no-progress detection (repeatedly touching the same files without new passing tests forces a stop). With “brakes matter more than throttle” understood, Claude’s four loop types read naturally — four different answers to “who steps on the brake.”
Four Loops, Four Stopping Logics
Turn-based loops: the human brakes
The most basic form. You write one instruction, the agent runs one turn, you check, you write the next. You hold the wheel throughout. Best for scattered short tasks that never enter a pipeline. Claude Code’s team suggests an optimization: move the steps you normally check manually into a SKILL.md file and let the agent accept its own work. The more quantifiable your checks, the more the agent can judge correctness itself — and the less you watch. This is the endpoint of prompt enhancement: not longer prompts, but relocating acceptance logic from your head into a file.
Goal loops: the evaluator brakes
Fix the goal first — “get the homepage Lighthouse score above 90; stop after 5 attempts.” Each time Claude wants to stop, a separate evaluator model judges against your standard: below bar, it goes back to work until the goal is met or attempts run out. The elegance is the separation: the executor never debates whether something is good enough — the evaluator decides. That prevents premature self-satisfaction and gives the loop a clean termination signal. Quantifiable standards — passing test counts, score thresholds — are the goal loop’s natural habitat.
Timed loops: the clock brakes
Triggered on an interval, like an alarm. Some work is repetitive — the task constant, only the input changing (summarize Slack every morning). Some work watches external systems — simplest done by checking on a schedule. Use /loop to rerun a prompt at intervals; use /schedule to move the loop to the cloud so it runs while your machine sleeps. The logic mirrors cron almost exactly, with one difference: cron fires a fixed script, while a timed loop fires an AI workflow that can adjust its own behavior each wake-up based on external state.
Proactive loops: the event brakes
Event- or time-triggered, fully unattended. Combined with auto mode and dynamic workflows, long chains run themselves: sweep the feedback channel hourly; when a bug report arrives, triage, fix, and reply end to end. Each subtask exits on reaching its goal; the standing routine runs until you switch it off. The most autonomous of the four — and the best fit for work that arrives continuously but has crisp boundaries: bug intake, issue classification, dependency upgrades.
What the Four-Way Split Actually Changes
Turn-based, goal, timed, proactive — four answers to “when should it stop”: the human judges, the evaluator judges, the clock judges, the event judges. The significance is not inventing new concepts — scheduled tasks, orchestration, and feedback loops have existed for years. Claude performed an engineering taxonomy: the way software engineering once classified design patterns, it named the basic units of AI automation so teams can discuss “are you using a goal loop or a timed loop” instead of describing the same thing in different vocabularies.
And when loops become designable units, the real shift is where the programming center of gravity sits: from content design to behavior-system design. You used to design the content of one instruction — “write Python that processes this CSV.” Now you design a behavior system — how it triggers, how it verifies, how it recovers from failure, how it stops. The engineer stops being “someone who writes code” and becomes “someone who designs AI behavior systems.” The transition resembles the monolith-to-microservices era, when developers stopped tuning single servers and started caring about orchestration, circuit breaking, and tracing. AI coding’s core competency is moving from “write more precise prompts” to “design more reliable agent behavior loops.”
The Frame Travels Beyond Coding
Watch Jensen Huang’s recent 26-minute interview: no GPUs, no compute — one word, Harness. Prompts, tool descriptions, memory, context management, task decomposition, retries, evaluation, permission control — the model reasons; the harness organizes reasoning into acceptable work. A harness is the engineering system that places a model inside a bigger loop. LangChain paired Nemotron 3 Ultra with a harness to reach 0.86 on the Deep Agents evaluation (top score 0.87) while cutting per-run cost from $43 to $4 — same model, different loop around it.
The prompt-to-loop migration is happening across roles: product managers moving from writing PRDs for engineers to designing research → requirements → validation loops; data teams moving from writing SQL to designing scheduled crawl → clean → analyze → alert loops; ops teams moving from configuring alert rules to designing AI diagnose → localize → repair → verify loops. Same frame, different shapes — one logic: whoever decomposes their workflow into loopable units first exits manual labor and enters system design.
Where to Start: Three Questions to Find Your First Loop
Claude Code’s official advice is refreshingly modest: don’t over-engineer the start. Pick one bottleneck in what you already do daily and ask three questions. One — verification: can I write the check? Fuzzy acceptance (“does it look good”) disqualifies a task for now; quantifiable acceptance (“tests green,” “API under 200ms,” “coverage up 5%”) marks a loop candidate. Two — goal: is the goal statement clear enough? “Optimize system performance” is not; “get homepage load under 2 seconds” is. Vague goals leave both the model and you unable to tell when to stop. Three — cadence: does the work arrive on a fixed rhythm? Daily, weekly, hourly tasks loop more easily than random ones — start there and accumulate experience before tackling the unscheduled.
One yes, and you have found your first delegable loop. You need not jump straight to proactive loops — starting turn-based, with acceptance criteria written into a file, is already a large efficiency win. The prompt era will not vanish overnight. But its center of gravity is moving — from “who writes better” to “who designs the more reliable loop.”
The real loop designers are only now taking the stage.
Sources: Claude Code Team, “Getting Started with Loops” (claude.com/blog, 2026) · Claude Code Agent SDK documentation, Agent Loop (code.claude.com) · Boris Cherny / Peter Steinberger on X, 2026 · Addy Osmani, “Loop Engineering,” 2026 · Jensen Huang × Harrison Chase interview on “Harness,” 2026
