The shift from writing prompts turn-by-turn to designing autonomous loops that discover work, assign it, verify results, persist state, and know when to hand off to you.
The instinct when a coding agent gets good is to prompt it more — bigger tasks, sharper instructions, better examples. That works for a while and then hits a ceiling: the human is still the driver of every turn. Every task means someone opens the terminal, types the prompt, reads the output, types the next prompt. The agent got faster; the pipeline didn't.
Loop Engineering, a framing popularized by Cobus Greyling based on quotes from practitioners at Anthropic, OpenClaw, and elsewhere, names the next move: replace yourself as the prompter. Design a small autonomous system — the loop — that runs on a schedule or until a goal is met, discovers new work, spawns helper agents, verifies their output, persists state so it can pick up where it left off, and hands off to a human only when it hits something it can't decide on its own.
Boris Cherny (head of Claude Code, Anthropic): ‘I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.'
Peter Steinberger (creator of OpenClaw): ‘You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.'
Addy Osmani: ‘Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.'
Where it sits in the stack
Greyling positions Loop Engineering as the third layer of a progression each of which solves a distinct problem:
Each layer up is a wider scope. Context engineering asks what a single prompt should carry. Harness engineering asks what a single session can reach, edit, and enforce. Loop engineering asks what happens when nobody is at the keyboard and the work still needs to move.
The six building blocks
Greyling identifies five capabilities plus one spine that together make a real loop — as opposed to a cron job that fires the same prompt into the void.
1. Scheduling — the heartbeat
Without a schedule, a loop is a script you have to remember to run. With one — a cron entry, a GitHub Action, a Claude Code /loop, a Grok scheduler — the intention becomes durable. ‘I should triage new PRs every morning' turns into a fact, not a hope.
2. Worktrees — safe parallel execution
The moment a loop spawns two or three agents that all want to edit the codebase, isolated git worktrees are what stop them from writing over each other. Frameworks that let you say isolation: "worktree" per agent handle the setup and teardown; without it, one long-running loop with a merge conflict is a bad Tuesday.
3. Skills — persistent project knowledge
A skill file (SKILL.md, or Claude Code's CLAUDE.md) is what stops each loop run from being day-one. Conventions, build commands, standards, the project's ‘we do X here' all live externally so the agent picks them up automatically instead of re-inferring them from scratch every session.
4. Connectors — MCP is the substrate
Loops need to act on real systems: open a PR, update a Linear ticket, post to Slack, query a database, trigger a runbook. MCP has become the shared vocabulary. When your Zendesk MCP works with Claude Code, Grok, and Codex, the loop shape becomes portable across the tool you happen to use this month.
5. Sub-agents — the maker / checker split
The single most important pattern for loops that run unattended. One agent implements. A different agent — often stronger, always with different instructions — verifies against the spec, runs the tests, checks the acceptance criteria. The implementer doesn't get to grade its own homework. The verifier is what lets you walk away.
6. Memory — the durable spine
Good state files answer three questions on every read: what are we working on right now? what did we try last time and what happened? what is waiting for a human? Without state, the loop starts every run from zero, redoes finished work, forgets its own decisions. Files like STATE.md, LOOP-STATE.json, or a shared Linear board are the difference between a loop and a scheduled prompt.
Worked examples
Two loops in the wild — one from engineering, one not — showing how the six blocks combine into an actual working system.
Example 1 — Nightly PR triage loop (engineering)
A team of four wants incoming PRs from open-source contributors triaged overnight: label them, request changes where obvious, run the tests, and either merge trivially-safe ones or leave a clear summary for the human reviewer at 9 a.m. Currently one engineer does this in the first hour of every workday.
Turned into a loop: a GitHub Actions schedule runs a Claude Code session every night at 2 a.m. The session reads its STATE.md to see what was open at the last run, uses the GitHub MCP to fetch new/updated PRs, and spawns one worktree-isolated subagent per PR. Each subagent's SKILL.md tells it the project's conventions; the maker subagent proposes the review; a separate checker subagent verifies the review is factually consistent with the diff. Anything ambiguous gets flagged with a one-paragraph brief in the state file for the human. Everything else — labels, obvious change requests, safe merges — happens autonomously.
What changed: the engineer isn't reading through seven diffs at 9 a.m.; they read one summary. The loop discovered the work (GitHub MCP), assigned it (worktree-isolated subagents), verified (checker), persisted (STATE.md), and handed off exactly where it should. Six of the six blocks, all in play.
Example 2 — Weekly competitor watch loop (non-technical)
A product manager wants a Monday-morning briefing on what competitors shipped last week — new features, pricing changes, blog posts, notable hires visible on LinkedIn. Doing this manually eats three hours every week.
Turned into a loop: a scheduler runs a session every Sunday at 6 p.m. The state file holds the current competitor list, the last-seen version of each competitor's pricing page, and any items waiting for the human to acknowledge. The session pulls the RSS feed of each competitor's blog (a simple MCP), diffs the pricing pages (another MCP that stores a snapshot), and scans LinkedIn for changes at the target companies. A maker subagent writes the draft brief; a checker subagent verifies every claim has a URL and every diff quote is actually present on the linked page. Monday at 9 a.m., the brief is in the PM's inbox with the state file updated.
The pattern is identical to the PR triage — schedule, state, connectors, maker/checker, hand-off — but the domain is completely different. That's the point: the loop shape is portable. Once you've built one, the second one is mostly filling in different connectors and a different skill file.
The realities
Greyling is candid about the traps, and they're worth naming before you build.
Cost economics
A five-minute loop that spawns implementer + verifier on every run will burn through a limited plan before breakfast. Triage should be cheap; subagents should only spawn when the state file indicates something actionable. Log the token spend per run — if you can't see it, you can't control it.
Verification is a claim, not proof
‘Done' is a claim until you confirm it. The checker subagent buys confidence — it doesn't remove the need for a human to periodically audit the loop's decisions. Unattended loops make unattended mistakes; the audit is what catches them.
Comprehension debt
Loops let you ship faster than you understand. The gap between what exists and what you can explain grows silently. A monthly ‘what has the loop actually done?' review, done by a human reading the state file top-to-bottom, is the cheapest fix.
Cognitive surrender
This is Greyling's most pointed warning. The same loop that accelerates a good engineer lets a less-experienced one abdicate judgment. ‘Build the loop like someone who intends to stay the engineer — not just the person who presses go.'
Tool convergence
The reason loop engineering is worth learning as a shape and not as a specific product feature: Claude Code, Grok CLI, and OpenAI Codex have all landed on similar primitives. Scheduling, worktrees, skills, MCP, subagents, memory files — the vocabulary is now roughly shared. A loop you design against Claude Code today ports to whichever tool you use next quarter with mostly a change of syntax, not shape.