Loop Engineering
Definition
A practice that became popular in early 2026: rather than prompting a coding agent by hand, you build the system that does it for you. A loop is a recursive goal — you define a purpose, and the loop iterates until a verifiable condition holds.
Five building blocks carry it. Automations set the cadence, kicking off runs on a schedule. Git worktrees isolate parallel agents so their edits cannot collide. Skills capture project knowledge that would otherwise be re-explained every session. Plugins and connectors via MCP wire the loop into the real tools — issue tracker, database, Slack, pull request. Sub-agents separate writing from checking: the agent that wrote the code is not the one that signs it off.
A sixth element decides whether any of it works: a memory outside the conversation — a markdown file, a Linear board — because the model forgets everything between runs. Claude Code and Codex now ship all of these out of the box; commands such as `/loop` (re-runs on a cadence) and `/goal` (runs until an externally verified condition holds) move control one floor higher. The phrase traces to Peter Steinberger and to Boris Cherny, head of Claude Code at Anthropic ("my job is to write loops").
Noise — Signal
Loop engineering is being sold as the next phase after prompt engineering — the proof that a team has moved from holding the tool to designing the factory. The capability is real and probably a preview of how this work evolves. Three things, however, get sharper, not easier, as the loop improves.
First, the token bill. A loop runs unattended — and bills unattended. Sub-agents multiply the cost because each one does its own model and tool work. The vendor incentive is not neutral here: more loops mean more tokens, and tokens are what foundation-model vendors monetise directly.
Second, verification. A loop running unattended is a loop making mistakes unattended. "Done" is a claim the loop makes about itself — not a proof. Splitting the writing sub-agent from the checking one is the reason you can step away at all, not a hygiene option.
Third, the human side. The same loop accelerates someone who understands the work deeply — and lets someone else avoid understanding it altogether. Identical setup, opposite outcomes. Loop design is therefore harder than prompt engineering, not easier: the leverage point moved, the work did not disappear.
The right question
Not: "Can our teams build loops that run the agents for us?" But: Who verifies what the loop ships while it runs unattended? Is the stopping condition externally checkable? What does an unattended mistake cost — and how do we keep the token bill governable as sub-agents multiply? And is the loop being used to move faster on work people understand — or to avoid understanding it?