Loop engineering means replacing yourself as the direct prompter of an agent and instead designing a system that iterates toward a goal until it is complete. A loop can be understood as a recursive objective: you define the intention, and an AI repeatedly works on it until a stopping condition is met. Addy Osmani argues this could be the future of working with coding agents, though it is early and token costs require careful attention.
This idea mirrors comments from industry practitioners. Peter Steinberger said, "You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny, head of Claude Code at Anthropic, similarly said he no longer prompts Claude directly but writes loops that prompt Claude; his job is to write loops.
How this differs from prior workflows
Historically, you obtained results from a coding agent by writing a single good prompt, providing context, reading the reply, then prompting again. The agent was a tool you drove turn-by-turn. Loop engineering substitutes a small system that finds tasks, assigns them, verifies results, records what happened, and decides the next step — and that system prompts the agents on your behalf.
This is no longer necessarily a homemade pile of bash scripts you maintain forever. Many building blocks now ship inside products. The patterns Osmani observes in Codex and Claude Code are almost identical, so once you recognize the common shape you design a loop that will work regardless of which product you happen to be using.
Five components of a loop (plus memory)
A working loop needs five capabilities and one place to store state:
- Automations that run on a schedule and perform discovery and triage.
- Worktrees so parallel agents do not collide on the same files.
- Skills to record project knowledge so the agent need not guess it every run.
- Plugins and connectors to integrate the agent with your existing tools.
- Subagents so one agent proposes a change and another verifies it.
And the sixth piece: memory — a Markdown file, Linear board, or any persistent state outside a single conversation that records what was tried, what passed, and what remains open. Because models forget between runs, the memory must reside on disk, not solely in context.
Why each piece matters
Automations — the loop’s heartbeat
Automations make a loop recurring rather than a single run. In the Codex app you configure automations by choosing the project, the prompt, frequency, and whether it runs against your local checkout or a background worktree. Runs that find something go to a triage inbox; runs that find nothing archive themselves. OpenAI uses automations for daily issue triage, summarizing CI failures, commit briefings, and hunting recent bugs. An automation can invoke a skill, keeping recurring behavior maintainable.
Claude Code reaches the same end via scheduling and hooks: you can run a prompt or command on an interval with /loop, schedule cron tasks, run shell commands at lifecycle hook points, or push the workflow to GitHub Actions. Both approaches let you define autonomous tasks with cadence and surface findings to you instead of requiring you to poll manually.
Both tools include in-session primitives: /loop re-runs on a cadence; /goal continues until a user-defined condition is true. After each turn a separate small model checks whether the goal is met, so the agent that wrote the code is not the one grading it. Codex also exposes /goal with pause, resume, and clear semantics.
Worktrees — prevent parallel chaos
When multiple agents run concurrently, file collisions become a failure mode. Git worktrees provide separate working directories with their own branch sharing repository history, so one agent’s edits cannot touch another’s checkout. Codex has built-in worktree support; Claude Code offers a --worktree flag and an isolation: worktree setting for subagents. Worktrees remove mechanical collisions, but human review bandwidth still limits how many threads you should run.
Skills — stop re-explaining your project each run
A skill is the way to persist and reuse project intent: a folder with a SKILL.md containing instructions and metadata, plus optional scripts, references, and assets. Invoke a skill ($ or /skills) or let the system select it when a task matches the description. Written intent prevents the agent from re-deriving your project conventions each cycle and mitigates "intent debt."
Note: a skill is the authoring format, while a plugin is how you distribute it. Package skills and connectors as plugins when you want to share across repos.
Plugins and connectors — let the loop interact with your real tools
A loop that only sees the filesystem is limited. Connectors, typically using MCP, let the agent read issue trackers, query databases, call staging APIs, or post in Slack. Codex and Claude Code both speak MCP, so connectors often port between them. Plugins bundle skills and connectors so teammates can install a setup instead of rebuilding it from memory.
With connectors a loop can open a PR, link a Linear ticket, and ping a channel when CI is green — it can act in your environment rather than merely describe what it would do.
Subagents — separate maker from checker
The most useful structural choice is splitting the agent that writes code from the one that verifies it. The model that authored code tends to grade its own homework too kindly; a second agent with different instructions or a different model catches issues the first missed. Codex spawns subagents on demand and aggregates results; you define agents as TOML files in .codex/agents/ with name, description, instructions, and optional model and reasoning effort. Claude Code provides similar subagent support in .claude/agents/ and agent teams that pass work between them. Typical splits are: one agent explores, one implements, one verifies.
Subagents increase token usage because each performs model and tool work, so deploy them where a second opinion is worth the cost. Claude Code’s /goal mechanism also embodies this maker/checker split: a fresh model decides if the loop is done instead of the one that produced the work.
Example loop in practice
Put the pieces together and a single thread becomes a small control panel. One common shape: an automation runs daily against the repo, its prompt calls a triage skill that reads yesterday’s CI failures, open issues and recent commits, and writes findings to a Markdown file or Linear board. For each actionable finding the system creates an isolated worktree and sends a subagent to draft a fix and another to review that draft against the project skills and tests. Connectors open the PR and update the ticket; anything the loop cannot resolve goes to the triage inbox for human attention. The state file is the spine: it remembers what was tried and what remains, so the next run resumes where the prior stopped.
The result: you designed the system once rather than prompting each step repeatedly. That is Steinberger’s claim made concrete, and it works similarly in Codex or Claude Code because the pieces are the same.
What loops do not remove
Loops change how work is done but do not excuse human responsibility. Three problems intensify rather than vanish:
- Verification remains your responsibility. An unattended loop can make mistakes unattended. Splitting maker and checker helps, but "done" remains a claim.
- Your understanding can atrophy. The faster a loop ships code you did not author, the larger the gap between the system state and your comprehension — comprehension debt grows unless you read what the loop produces.
- Comfort is dangerous. When loops run themselves it’s tempting to stop forming opinions and just accept outputs — what Osmani called "cognitive surrender." Designing the loop conscientiously cures this; designing it to avoid thinking accelerates the problem.
Conclusion: build loops, stay the engineer
Osmani sees loop engineering as a preview of where our workflows will evolve. Yet if you abdicate review to automated loops, product quality will likely suffer and you may end up in a downward spiral. Set up loops and use them, but retain direct prompting where appropriate and keep human judgment in the loop.
Two people can build an identical loop and get opposite outcomes: one to speed up tasks they deeply understand, the other to avoid understanding the work altogether. The loop cannot tell the difference — you can. That shift in leverage is what makes loop design harder than prompt engineering. Build the loop, but do so as someone who intends to remain the engineer, not merely the person who presses go.
