AddyOsmani.com - Loop Engineering
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of a recursive goal where you define a purpose and the AI iterates until complete. I believe this may be the future of how we work with coding agents. However, its still early, I’m skeptical and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or poor), so I want to unpack what it is and what it means.
Peter Steinberger recently said: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Similarly, Boris Cherny, head of Claude Code at Anthropic, said “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”.
Okay, so what does any of that mean?
For like two years the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over, or at least some think it’s going to be.
Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside and the factory model - the system that builds the software. Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself.
The thing that surprised me is this is not really a tool thing anymore. A year ago if you wanted a loop you wrote a pile of bash and you maintained that pile forever and it was yours and only yours. Now the pieces just ship inside the products. Steinberger’s list maps almost exactly onto the Codex app, and then almost the same onto Claude Code. And once you notice the shape is the same you stop arguing about which tool, you just design a loop that still works no matter which one you happen to be sitting in.
The five pieces, and then notes
A loop needs five things and then one place to remember stuff. Let me list it first and then map it.
Automations that go off on a schedule and do discovery and triage by themselves.
Worktrees so two agents working in paralell dont step on each other.
Skills to write down the project knowledge the agent would otherwise just guess.
Plugins and connectors to plug the agent into the tools you already use.
Sub-agents so one of them has the idea and a different one checks it.
Then the sixth thing, the memory. A markdown file, or a Linear board, anything that lives outside the single conversation and holds what’s done and what is next. Sounds too dumb to matter. But it’s the same trick every long running agent depends on and I went into it in long-running agents, the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt.
Both products have all five now.
Primitive<br>Job in the loop<br>Codex app<br>Claude Code
Automations<br>discovery + triage on a schedule<br>Automations tab: pick project, prompt, cadence, environment; results land in a Triage inbox; /goal for run-until-done<br>Scheduled tasks and cron, /loop, /goal, hooks, GitHub Actions
Worktrees<br>isolate parallel features<br>Built-in worktree per thread<br>git worktree, --worktree, isolation: worktree on a subagent
Skills<br>codify project knowledge<br>Agent Skills (SKILL.md), invoked with $name or implicitly<br>Agent Skills (SKILL.md)
Plugins / connectors<br>connect your tools<br>Connectors (MCP) plus plugins for distribution<br>MCP servers plus plugins
Sub-agents<br>ideate and verify<br>Subagents defined as TOML in .codex/agents/<br>Task subagents in .claude/agents/, agent teams
State<br>track what’s done<br>Markdown or Linear via a connector<br>Markdown (AGENTS.md, progress files) or Linear via MCP
The names are a bit different here and there but the capability is the same thing. Let me go one by one because honestly the details are where a loop either holds together or quietly leaks everywhere.
Automations, this is the heartbeat
Automations are what make a loop an actual loop and not just one run you did once. In the Codex app you make one in the Automations tab and you pick the project, the prompt it will run, how often, and if it runs on your local checkout or on a background worktree. The runs that find something go to a Triage inbox, and the runs that find nothing just archive themselves wich is nice. OpenAI uses them internally for boring stuff like daily issue triage, summarising CI failures, writing commit briefings, hunting bugs somebody added last week. And an automation can call a skill, so you keep the recurring thing maintainable, you...