Loop Engineering

Addy Osmani · article · 2026-06-07 Reader 🖥️

Agent Harness Agent Skills Cognitive Surrender Loop Engineering MCP (Model Context Protocol)Multi-Agent Orchestration Orchestration Tax / Human Review Bottleneck

Loop engineering means replacing yourself as the person who prompts the coding agent turn-by-turn with a designed system — automations, worktrees, skills, plugins/connectors, and sub-agents, plus externally-persisted state — that prompts the agent for you; but because that system can't distinguish between someone using it to move faster on work they understand and someone using it to avoid understanding the work at all, the engineer's judgement doesn't disappear, it relocates one level up, from prompting to system design, which Osmani argues is harder, not easier.

practical · expository essay with an embedded framework (taxonomy of five building blocks + one worked example), closing in a hedged counter-argument — Reads as the latest installment in Osmani's serial diagnosis (harness engineering -> orchestration tax -> intent debt -> loop engineering); it names and packages a practice rather than reporting an experiment, and structurally reverses itself at the end, undercutting its own contrarian headline.

Structure

Part	Role
Opening definition + quoted authorities (Steinberger, Cherny)	thesis
"The five pieces, and then notes"	framework
Codex-app / Claude-Code comparison table	evidence
Per-primitive deep-dive sections	elaboration
"What one loop looks like"	worked example
"What the loop still does not do for you"	counterweight
Closing ("Build the loop. Stay the engineer.")	reframing conclusion

Key terms

Loop engineering Loop Engineering
designing the outer, autonomous system — automations, worktrees, skills, connectors, sub-agents, persisted state — that repeatedly invokes an agent harness without a human prompting each turn
Loop (as recursive goal)
"a recursive goal where you define a purpose and the AI iterates until complete"
Automations ("the heartbeat")
scheduled, cadence-driven runs that do discovery and triage on their own and route findings to a triage inbox, distinguishing a loop from a one-off run
/goal vs. /loop
/loop re-runs on a cadence; /goal keeps going until a separately-graded, verifiable stopping condition holds — a fresh model grades whether the work is done rather than the model that did the work
Maker and checker
splitting the sub-agent that drafts/implements from the sub-agent that reviews/verifies, because the model that wrote the code is "too nice grading its own homework"
"Sits one floor above the harness"
loop engineering as a layer above his own previously-coined agent-harness engineering: the harness is what a single agent runs inside, the loop is what runs the harness on a timer and feeds itself

Propositions

explicitcorroboratedLoop engineering is replacing yourself as the person who prompts the agent — you design the system that does the prompting instead.conf: high
supports ←How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p13 — Both define loop engineering the same way: building a system that prompts the agent instead of prompting it yourself turn by turn.
explicitcorroboratedA loop is "a recursive goal where you define a purpose and the AI iterates until complete" rather than something a human steers turn-by-turn.conf: high
supports ←Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch · p2 — Restates the same core loop-engineering move -- swap step-by-step prompts for one end-state the agent checks itself against -- using a concrete coding example (a package resolver) rather than Osmani's general definition.
explicitTwo well-placed practitioners — Peter Steinberger and Boris Cherny (head of Claude Code at Anthropic) — independently report they no longer prompt coding agents directly; they design loops that prompt the agents for them, and this convergent testimony is offered as the article's central evidence that prompting skill is being superseded as a differentiator.conf: medium
refinesSoftware Teaming in the Age of AI with James Herr and Woody Zuill · p15 — Zuill/Herr locate the valuable skill in communicating 'high-level intent' rather than coding-out-loud/turn-by-turn dictation; Osmani's claim refines this by relocating that same high-level-intent skill from live chat prompting into system design (automations, skills, sub-agent specs) that runs unattended.
explicitdevelopedA loop requires five building blocks — Automations (scheduled discovery/triage), Worktrees (parallel isolation), Skills (externalized project knowledge), Plugins/connectors (tool access via MCP), and Sub-agents (idea/verify split) — plus a sixth non-negotiable: state/memory persisted outside the conversation, because the model forgets everything between runs but the repo doesn't.conf: high
extends ←agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p2 — Loop-engineering's five building blocks name 'Skills' as one primitive in the abstract; this document supplies three concrete, competing implementations of that primitive with different organizing principles.
explicitdevelopedLoop engineering sits "one floor above" agent-harness engineering: the harness is the environment a single agent runs inside, the loop is the outer system that runs the harness on a timer, spawns little helpers, and feeds itself.conf: high
extendsAgent Harness Engineering · p2 — Names a layer above the harness gap: if the harness gap explains why models underperform in a single session, loop engineering names the next-order gap — most people still operate the harness by hand, turn by turn, instead of building a system that runs it for them.
refines ←What the Hell Is a Loop, Anyway? · p1 — Osmani frames loop engineering as one floor above agent-harness engineering (a two-level model); Voss decomposes that single outer floor into four architecturally distinct tiers (execution/task/product/system) plus an oversight ring, showing the two-floor model undercounts the stack.
explicitAll five loop primitives now ship as native features inside both the Codex app and Claude Code, whereas a year ago building a loop meant writing and personally maintaining a pile of bespoke bash scripts — the capability moved from custom tooling into the products themselves.conf: high
extendsAgent Harness Engineering · p10 — One-year-later empirical update to the harness-convergence claim: convergence has moved up a layer, from harness features (tools, context) to loop features (automations, worktrees, sub-agents) now native in both major products.
explicitestablishedThe single most useful structural element in a loop is separating the sub-agent that drafts from the sub-agent that checks, because the model that wrote the code is "too nice grading its own homework."conf: high
supportsAgent Harness Engineering · p7 — Restates, at the loop layer, the same maker/checker separation-of-duties claim already established at the harness layer: self-evaluation is unreliable, a distinct evaluator agent is needed.
supports ←agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub · p5 — Superpowers' two-stage subagent review (spec compliance, then code quality) is a concrete instantiation of the loop-engineering principle that the drafting sub-agent and the checking sub-agent should be separated because a model is 'too nice grading its own homework.'
supports ←Inside a Software Factory · p8 — Identical claim (agents are biased toward grading their own work favorably, so implementer and QA/reviewer must be separate agents), attributed to the same source (Addy Osmani) in both pieces; also echoed in extract-agent-harness-engineering#p7.
supports ←Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch · p3 — A concrete two-agent (Jam) instantiation of the structural element Osmani names as the single most useful loop primitive: separating the sub-agent that drafts from the sub-agent that checks.
explicitSkills are where a loop stops re-deriving project context from zero every cycle: a skill externalizes intent (conventions, the "why," past incidents) once, so every iteration of the loop reads it instead of guessing at intent each session.conf: high
extendsThe Intent Debt · p2 — Applies Osmani's own intent-debt framing (externalized rationale an agent can read) specifically to skills-as-a-loop-primitive: a skill is intent written down once so the loop doesn't re-derive project context from zero every cycle.
explicitcorroboratedPersisting state outside the conversation (a markdown file, a Linear board) is the trick every long-running agent depends on, because the model forgets between runs but the repo does not.conf: high
supports11 Tips For AI Coding With Ralph Wiggum · p5 — Independently arrives at the same claim as the Ralph-Wiggum piece: because agent context starts fresh every run, state must be externalized to a committed file/board outside the conversation.
supports ←Paweł Huryn's Post · p9 — Both identify persisting state outside the conversation, in files the repo keeps, as the mechanism that lets an agent 'remember' and improve across runs the model itself cannot.
explicitcorroboratedWorktrees remove the mechanical failure mode of two agents colliding on the same files, but they do not remove the human review-bandwidth ceiling — "the worktrees take away the mechanical collision but YOU are still the ceiling."conf: high
extendsThe Orchestration Tax is You · p2 — Explicitly credits his own orchestration-tax essay: worktrees remove the mechanical file-collision failure mode of parallel agents but leave the human's judgement throughput as the binding constraint untouched.
supports ←What the Hell Is a Loop, Anyway? · p11 — Osmani claims worktrees remove mechanical file-collision but not the human review-bandwidth ceiling ('YOU are still the ceiling'). Voss supplies a concrete, named confirmation: Anthropic's own internal Claude Tag team, despite aggressive dogfooding, reports being bottlenecked on exactly that human review/conceptualization ceiling.
explicitdevelopedVerification remains entirely on the human even inside a well-designed loop; "done" is a claim the loop makes about itself, not a proof, and a genuinely trusted verifier sub-agent is what makes that claim meaningful enough to let a human walk away.conf: high
supportsThe Orchestration Tax is You · p6 — Restates that the orchestration tax — the gap between what agents produce and what a human can actually verify/merge — persists inside a fully designed loop; a verifier sub-agent doesn't eliminate the tax, it's the mechanism by which the human decides whether to trust the loop's 'done' claim at all.
extends ←Software Factories, Light and Dark · p10 — Turns the prior post's observation that verification stays entirely on the human into a named systems-thinking rule ('back pressure') plus concrete, checkable criteria for how much autonomy verification capacity can support.
extends ←Loop Engineering: Building Blocks, Adoption, and Impact · p8 — Confirms empirically, across 36,645 repositories, Osmani's claim that verification 'remains entirely on the human' even in a well-designed loop — not one committed verifier subagent referenced by a loop artifact was detected.
extends ←Own the Outer Loop · p12 — Specifies where human verification lives inside a well-designed loop by naming four distinct outer loops (constraints, sampling, audit, ownership) rather than a single undifferentiated 'human in the loop.'
explicitdevelopedComprehension debt (the growing gap between what exists and what the human actually understands) grows faster, not slower, as a smooth loop ships more code the human didn't write, unless the human keeps reading what the loop produced.conf: high
supportsCognitive Surrender · p3 — Restates, in loop-engineering terms, that comprehension debt accumulates via exactly the mechanism Osmani's cognitive-surrender essay already names — each unreviewed act of loop output is a small loan against future understanding.
extends ←Software Factories, Light and Dark · p7 — Same author's earlier claim that comprehension debt grows with unread loop output is generalized here into the full dark/lit factory taxonomy and explicit criteria for when a loop is allowed to stay unread.
explicitThe comfortable posture — letting the loop run and no longer forming an independent opinion about its output — is cognitive surrender; designing the loop is either the cure or the accelerant for it, "same action, opposite result," depending on whether it's built with judgement or to avoid thinking.conf: high
supportsCognitive Surrender · p1 — Applies the offloading/surrender distinction directly to loop design: building a loop 'with judgement' is offloading the how while retaining the what; building it 'to avoid thinking' is surrender — the same action producing opposite results.
implicitdevelopedTwo engineers can build the structurally identical loop and get opposite outcomes depending on whether they use it to move faster on work they understand deeply or to avoid understanding the work at all — the loop itself cannot tell the difference.conf: high
extends ←What the Hell Is a Loop, Anyway? · p10 — Osmani argues a loop can't distinguish a practitioner using it to move faster on understood work from one avoiding understanding entirely — a claim about individual psychology. Voss relocates the same tension into an explicit architectural mechanism: autonomy is a dial independently settable per loop tier, giving Osmani's binary framing something concrete to be tuned against.
implicitThe article's opening contrarian claim ("you shouldn't be prompting coding agents anymore") is in real tension with its own closing counsel ("don't forget that prompting your agents directly is also effective... it's all about finding the right balance") — the piece asserts a strong headline position and then substantially walks it back without ever giving a rule for when a task needs direct prompting versus a designed loop.conf: medium

Arguments

The individual engineer no longer needs to be skilled at turn-by-turn prompting; the skill that now matters is designing the loop that prompts the agent. strength: medium

Explicit premises:

Steinberger and Cherny, both credible insiders, independently report they no longer prompt agents directly — they design loops instead.
The five loop primitives are now native, shipped features in both major coding-agent products, so building a loop no longer requires bespoke tooling.
A worked example ("What one loop looks like") shows the human designing the system once, never prompting any individual step.

Implicit premises:

Whatever made someone good at prompting (crafting the right instruction, iterating conversationally) transfers into system-design skill, and market/attention will reward the latter going forward.
A maker/checker sub-agent split substitutes adequately for the human's own turn-by-turn judgement of quality.

Inferences:

from 'credible insiders no longer prompt directly' plus 'the capability is now productized' to 'prompting skill is being superseded as the thing to get good at'

Loop engineering does not reduce the engineer's responsibility — it relocates and intensifies it, into verification, comprehension, and resisting cognitive surrender. strength: high