Last December, Boris Cherny shipped 259 pull requests in a single month. Every one written by Claude. He says he did not open an editor the whole time.
His job was not to write code. It was to write the thing that writes the code. Peter Steinberger put it in two lines that have been seen over 8 million times: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
That is loop engineering. You build a small system that finds the work, hands it to an agent, checks the result, and decides the next move, then you let it run while you sleep.
The catch arrived the same month. Someone else’s loop ran for eleven days unwatched and burned $47,000 before anyone noticed. So this is really two skills, and almost everyone teaches only the first: building a loop that ships work, and building the brakes that keep it from running you off a cliff.
One question decides which loop you built: does it converge on something true, or is it just an expensive random walk?
1. A loop is six pieces and one question
Underneath the noise, a working loop is six parts. The list looks too plain the first time you see it. The detail inside each part is where a loop either holds together or leaks money overnight.
You no longer build any of this by hand. A year ago a loop meant a pile of shell scripts you owned and babysat forever. Now the pieces ship inside the products, and the same six map onto both the OpenAI Codex app and Claude Code. Once you see that, the tool stops being the argument and the loop becomes the design.
PIECE JOB IN THE LOOP CODEX CLAUDE CODE
------------- ------------------------ ------------------------- --------------------------
State remember across runs markdown / Linear (MCP) markdown / Routines + MCP
Automations run on a schedule Automations tab + Triage /loop (skill), Routines, /goal
Worktrees isolate parallel agents Worktree per thread --worktree, isolation: worktree
Skills codify your intent ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md
Connectors touch your real tools MCP servers (config.toml) MCP servers (.mcp.json)
Sub-agents split maker from checker TOML in .codex/agents/ .claude/agents/ + agent teams2. State is the only thing the next run inherits
Start at the bottom, because everything else leans on it.
A model forgets when a run ends. The conversation dies, the context clears, the next run wakes up knowing nothing. Memory in the chat dies with the run. It has to live on disk.
In practice that is one file. A STATUS.md in the repo, or a Linear board reached through a connector, holding what is done, what is in progress, what is next, and the handful of things the loop must never touch.
# STATUS.md (the loop reads this first, writes it last)
## Done
- [x] auth: migrated to tokens v2, tests green
## In progress
- [ ] billing: webhook refactor (PR #214, CI red)
## Next
- [ ] dashboard: flaky test in test/charts
## Never
- do not modify infra/ without a humanTreat the loop like a night shift you never watch. You are not judged by what it did at 3am. You are judged by the note waiting on your desk at nine. Design that note first and most of the loop designs itself.
3. Automations are the difference between a loop and a thing you ran once
A loop earns the name only when it fires on its own.
In the Codex app you build one in the Automations tab: the repo, the prompt, the cadence. Runs that find something land in a Triage inbox; runs that find nothing archive themselves. OpenAI uses this for the unglamorous backbone of a codebase: daily issue triage, CI-failure summaries, catching the bug someone slipped in last week.
Claude Code gets there through a few primitives, and the popular write-ups get the details wrong, so it is worth being exact. /loop is a skill, not a built-in command, and it re-runs a prompt on a cadence while your session is open. Recurring cloud jobs are Routines, set with /schedule, with a one-hour minimum, and they keep running with your laptop closed. There is no local crontab.
The one worth learning is /goal. It runs until a condition you wrote is true, and after each turn a separate, smaller model checks whether you are actually done. The agent that wrote the code does not get to grade it.
# Claude Code: run until it is genuinely finished, not until it feels finished
/goal all tests in test/auth pass and the lint step is clean
# Claude Code: a recurring cloud job (1-hour minimum)
/schedule daily PR triage at 9am
# Codex: an automation prompt (set the cadence in the form)
"Weekdays 9am: scan open PRs, flag failing CI or no reviewer, post to Triage."Write the stop condition like a contract. “All tests in test/auth pass” is a contract. “Make it better” is how a loop runs until payday.
4. Worktrees keep parallel agents out of each other’s way
The moment you run more than one agent, the failure mode changes. It is no longer the model. It is two agents writing the same file, the same mess as two engineers committing to the same lines with nobody talking.
A git worktree is the wall between them: a separate working directory on its own branch, sharing the repo history, so one agent’s edits cannot reach another’s checkout.
# Claude Code: an isolated checkout per agent
claude --worktree feature-auth
# or on a sub-agent, in .claude/agents/<name>.md frontmatter:
# isolation: worktree
# Codex: choose "Worktree" when you open a thread (one detached HEAD each)One caveat the tool will not mention. Worktrees remove the collision, not the bottleneck. You are still the ceiling. However many agents you start, your own review bandwidth decides how many you can trust.
5. Skills are your intent, written once, on the outside
An agent starts every run cold and fills any gap in your intent with a confident guess. A skill is that intent written down where the model reads it each time, so it stops guessing.
The format is the same on both tools: a folder with a SKILL.md holding instructions and a description, plus any scripts it needs. It fires when you call it by name or when your task matches its description, which is exactly why a flat, literal description beats a clever one.
# .claude/skills/triage/SKILL.md (Codex: ~/.agents/skills/triage/SKILL.md)
---
name: triage
description: Read yesterday's CI failures, open issues, and recent
commits; write each finding to STATUS.md as a task.
---
1. Pull failing CI and cluster by root cause.
2. Match each to the open issue or commit that caused it.
3. Write one STATUS.md task per real finding. Skip the noise.Without skills, every cycle relearns your project from scratch. With them, the loop gets a little sharper each morning.
6. Connectors let the loop act, not just talk
A loop that can only see the filesystem is a toy. Connectors, built on the shared MCP standard, let the agent read your issue tracker, hit a staging API, query a database, post to a channel.
# Claude Code
claude mcp add --transport http linear https://mcp.linear.app/mcp
# Codex
codex mcp add linear --url https://mcp.linear.app/mcpThis is the line between an agent that says “here is the fix” and a loop that opens the pull request, links the ticket, and reports green on its own. Because both tools speak MCP, a connector you wire for one usually drops into the other.
7. Sub-agents keep the maker away from the checker
The highest-value move in any loop is splitting the agent that writes from the agent that checks.
A model reviewing its own work passes itself every time. A second agent, with different instructions and ideally a different model, catches what the first one talked itself into.
# Codex: .codex/agents/reviewer.toml
name = "reviewer"
description = "Adversarial PR reviewer: correctness, security, missing tests."
developer_instructions = "Review like an owner. Assume the author is wrong
until the diff proves otherwise."
model_reasoning_effort = "high"
# Claude Code: .claude/agents/reviewer.md frontmatter
# name: reviewer
# description: Adversarial reviewer. Use after any code change.
# model: opusOne explores, one implements, one verifies against the spec. This is what /goal already does underneath: a fresh model rules on whether the work is done. Second opinions cost tokens, because each agent runs its own model and tools, so spend them where being wrong is expensive.
8. What one loop looks like
Put the six together and a single thread becomes a small machine.
A scheduled automation runs each morning on the repo. It calls your triage skill, which reads the overnight CI failures, the open issues, and the recent commits, and writes each real finding into STATUS.md. For every finding worth doing, the loop opens an isolated worktree, sends one sub-agent to draft the fix and a second to review it against your skills and your tests. Connectors open the PR and update the ticket. Whatever it cannot handle waits in your triage inbox. STATUS.md remembers what passed and what is still open, so tomorrow starts where today stopped.
What you actually wake up to is a short handoff, not a wall of logs:
# 9:00am — the loop's overnight handoff (your Triage inbox)
READY TO MERGE
PR #218 fix flaky test in test/charts CI green
PR #219 retry webhook on 429, add backoff test CI green
NEEDS YOU
auth/session.ts two safe ways to fix this; I picked neither, your call
QUIET
7 scheduled runs found nothing and archived themselvesYou designed it once. You prompted none of it.
9. Build the brakes before you walk away
This is the half nobody teaches, and it decides whether your loop is an asset or a liability.
That $47,000 bill was not a clever model gone rogue. It was two agents, an analyzer and a verifier, each politely asking the other for more work, with no step limit, no budget ceiling, and no stop condition. It ran eleven days. One cap would have killed it on the first.
Install the brakes before the horsepower. Do not ship the engine until you have shipped the brake pedal.
# Bolt these on BEFORE you walk away:
- step cap: --max-turns 50 (hard stop, no exceptions)
- budget ceiling: claude -p --max-budget-usd 10 (print mode; per phase)
- blast radius: one worktree, one branch, read-only outside src/
- circuit breaker: same tool + same args 3x in a row = halt
- dead-man check: write a heartbeat to STATUS.md each run; silence pages youScope a loop by what it can destroy, not by what you want it to do: which repos, which branches, how many dollars, how many steps before it force-quits. Choose the blast radius first, the task second.
And price it honestly. Steinberger’s hundred-agent fleet is real, and it runs about 20 to $200 plan, the loop that pays off is small, capped, and pointed at one dull job, not a swarm.
THE COST SPREAD (all real, all from the last six months)
-----------------------------------------------------------------
259 PRs in 30 days one engineer, 100% written by Claude
$47,000 in 11 days a runaway loop with no cap, nobody watching
~$1.3M per month a 100-agent fleet (the bill is sponsored)
-----------------------------------------------------------------
Same technology. The difference is the brakes.10. How loops die
Every loop that fails dies one of four deaths. Learn the names now so you spot them at 3am.
Runaway recursion. Two agents feed each other forever. The cure is the step cap and the budget ceiling above, nothing cleverer.
Silent death. One developer’s overnight run hit a full context window, stopped, then kept trying to resume into the same wall while still looking alive. Your loop can be dead for hours and still report progress. The cure is a heartbeat and a fresh context per phase, not one endless run.
The random walk. With no verifiable stop condition, the loop drifts away from the goal instead of toward it. A passing test suite is a fixpoint it can reach. “Looks done” is not one.
Comprehension debt. The faster a loop ships code you did not write, the wider the gap between what your repo does and what you understand. Let it run long enough unread and you stop being the engineer and become a rubber stamp. The cure is a human-read gate the loop is never allowed to skip.
11. Build the loop. Stay the engineer.
Two people can build the identical loop and get opposite results. One uses it to move faster on work they understand to the bone. The other uses it to stop understanding the work at all. The loop cannot tell them apart. You can.
Cherny’s point was never that the work got easier. It is that the leverage moved: from the prompt to the loop, and from typing to judgment. That is a harder job than prompting, not a softer one.
So here is the move, and it is small on purpose, because this is early and the costs swing wildly. Tomorrow morning, take the most boring job you still do by hand, triaging CI, closing stale issues, chasing a flaky test, and wrap one capped loop around it. Brakes first. Small enough that you still read every diff it ships.
Nobody shipping 200 pull requests a month started with a hundred agents. They started with one loop they trusted, and they stayed the engineer the whole way. Build that one.