Loop Engineering: How One Loop Ships 259 PRs a Month

Last December, one engineer shipped 259 finished code changes in a single month (in the jargon they are called PRs, pull requests). His AI wrote every one. He says he never opened a code editor. Peter Steinberger put it in two lines that more than eight million people have seen:

The flip side showed up the same month. Someone else's loop ran unwatched for 11 days and burned $47,000 before anyone noticed. So there are two skills, and only the first gets taught: build a loop that does the work, and build the brakes that keep it from driving you off a cliff.

A loop is a small program wrapped around an agent. The agent takes a step. Something checks the result. Not done? It takes the next step. Round and round, until your condition comes true or you stop it.

One question separates a real loop from a money pit: is there an honest way to know the work was done right? A test that passes or fails. A build that compiles or does not. No check, and the agent just agrees with itself in circles and sends you the bill.

A loop pays off under four conditions. Miss one, and it costs more than it returns.

1. The task repeats at least weekly. Otherwise it is a one-time script, not a loop.
2. Verification is automated. A test, a linter (a code-style checker), a build. No check, and you are back to reading every change by hand.
3. Your budget can absorb waste. A loop re-reads context and explores, so it burns money even on empty runs.
4. The agent has an engineer's tools. Logs, an environment to reproduce a failure, the ability to run its own code.

Strip the noise and a working loop is six parts. You no longer build them by hand: they ship inside the tools and map the same way onto Claude Code and the OpenAI Codex app.

A model forgets everything when a run ends. The chat's memory dies with it, so the memory has to live on disk. In practice that is one file.

# STATUS.md  (the loop reads it first, writes it last)
## Done
- [x] auth: migrated to tokens v2, tests green
## In progress
- [ ] billing: webhook refactor (PR #214, tests red)
## Next
- [ ] dashboard: flaky test in test/charts
## Never
- do not touch infra/ without a human

Treat the loop like a night shift. You are judged not by what it did at three in the morning, but by the note on your desk at nine. Design the note, and half the loop designs itself.

A loop becomes a loop when it starts on its own. In Codex that is the Automations tab: project, prompt, schedule. In Claude Code it is three separate commands, and this is where popular retellings get it wrong, so to be exact:

# /loop is a skill (not a built-in command). It repeats your prompt
# while the session is open:
/loop every 30 min: check src/auth for new failures

# /schedule is a cloud job (1-hour minimum, runs with the laptop closed):
/schedule daily PR triage at 9am

# /goal runs until a condition becomes TRUE.
# After each step a separate small model checks if it is done:
/goal all tests in test/auth pass and the lint step is clean

The key one is /goal. The agent that wrote the code does not get to grade itself. Write the stop condition like a contract: "all tests in test/auth pass" is a contract, "make it better" is how you keep a loop spinning until payday.

Two agents writing to one file are two engineers editing the same lines in silence. A git worktree is the wall between them: a separate folder on its own branch, sharing the history.

# Claude Code: a copy of the project per agent
claude --worktree feature-auth

# or on a sub-agent in .claude/agents/<name>.md:  isolation: worktree

# Codex: choose "Worktree" when you open a thread

The caveat the tool will not mention: worktrees remove the collision, not the bottleneck. The bottleneck is you. However many agents you start, your review speed decides how many you can trust.

The agent starts from scratch and fills any gap with a confident guess. A skill is your intent, written where the model reads it every time. The format is the same everywhere: a folder with a SKILL.md file.

# .claude/skills/triage/SKILL.md  (Codex: ~/.agents/skills/triage/SKILL.md)
---
name: triage
描述: Read yesterday's failing tests, open issues, 和 recent
  commits; write each finding to STATUS.md as a task.
---
1. Collect failing tests, group by root cause.
2. Match each one to the issue or commit that caused it.
3. Write one task in STATUS.md per real finding. Skip the noise.

Without skills, the loop relearns your project from a blank page. With them, it gets smarter every morning.

A loop that only sees files is a toy. Connectors (the MCP standard) let the agent read your issue tracker, hit a staging server, post to chat.

# Claude Code
claude mcp add --transport http linear https://mcp.linear.app/mcp
# Codex
codex mcp add linear --url https://mcp.linear.app/mcp

This is the line between "here is how to fix it" and a loop that opens the pull request itself, links the ticket, and reports the tests green. Both tools speak MCP, so a connector for one usually drops into the other. Fastest payback: a code tracker, an issue tracker (Linear, Jira), chat (Slack), an error tracker.

The most valuable move: split the one who writes from the one who checks. A model reviewing itself always gives a pass. A second agent, with different instructions and on a different model, catches what the first talked itself into.

# Codex: .codex/agents/reviewer.toml
name = "reviewer"
description = "Adversarial reviewer: correctness, security, tests."
developer_instructions = "Review like an owner of the project. Assume the
  author is wrong until the change proves otherwise."
model_reasoning_effort = "high"

# Claude Code: .claude/agents/reviewer.md
#   name: reviewer
#   description: Adversarial reviewer. After any code change.
#   model: opus

One explores, one writes, one checks against the spec. That is what /goal runs under the hood. A second opinion costs money, since each agent runs its own model. Spend it where being wrong is expensive.

Put the six parts together and a single thread becomes a machine.

1. An automation runs each morning on the project.
2. The triage skill reads the overnight failures, issues, and commits and writes findings to STATUS.md.
3. For each finding, a separate worktree opens.
4. One sub-agent writes the fix, a second checks it against your tests.
5. Connectors open the pull request and update the ticket.
6. Whatever failed waits in the triage inbox. STATUS.md remembers the rest.

You wake up not to a wall of logs, but to a short note:

That $47,000 bill was not an evil AI. It was two agents politely asking each other for more work: no step limit, no money ceiling, no stop condition. One cap would have killed it on day one.

# loop.config: bolt these on BEFORE you walk away
max_turns: 50            # hard stop, no exceptions
max_budget_usd: 10       # money ceiling per run
scope: [src/]            # read-only outside the folder
write_branches: [auto/*] # blast radius: where it may write
circuit_breaker: 3       # same call 3x in a row = halt
heartbeat: STATUS.md     # silence instead of a mark = alarm

The core rule: scope the loop by what it can break, not by what you want it to do. Blast radius first, task second. And price it honestly:

The technology is the same in all three cases. The only difference is whether the brakes are on.

1. Runaway recursion. Two agents feed each other work forever. Cure: a step cap and a money ceiling.
2. Silent death. The context filled up, the loop stalled, but it looks alive and reports "progress." Cure: a heartbeat and a fresh context per phase.
3. Walking in circles. With no verifiable condition, the loop drifts from the goal. Green tests are a point it can reach. "Looks done" is not.
4. Comprehension debt. The faster the loop writes code you never read, the further you drift from your own project. Cure: a mandatory "a human read this" step you never skip.

A bonus with a name: the "Ralph loop." The agent signals "done" too early and exits halfway. It happens where there is no real checker and no hard stop. A useful self-check metric: count not tokens, but the cost per accepted change. Below half accepted, and the loop runs at a loss.

The loop is built for people who do not pay for tokens. Here is how to get most of the value for less.

1. Spend the thinking before the tokens. "Build me auth" spins for 30 steps of guessing. A finished spec (login method, token lifetime, error states, definition of done) hits the target in one pass.
2. Plan cheap, execute expensive. Your top model should not read files. Give reading and planning to a small model, leave the hard part to the strong agent.
3. Turn on caching. The loop sends the same context every step, and caching is exactly what makes the repeat cheaper. A 15-minute change cuts repeated input by about 90%.
4. Engineer the context. The rule from the Devin team: delegate the reading, centralize the writing. Send the bulky search to a cheap sub-agent, the main one reads a short summary, not forty files.
5. Be the loop yourself. Three passes you steer beat thirty run alone. If you automate, cap it by step count.

When a loop is worth it: the finish line is green tests, the run is bounded, and an hour of your time beats the tokens. Overnight refactors and large backlogs you cannot clear by hand are exactly that shape. But that is a narrow slice of the work.

Two people build the same loop and get opposite results. One speeds up on work they understand to the bone. The other stops understanding the work at all. The loop cannot tell them apart. You can.

The leverage moved: from the prompt to the loop, from the code to the judgment. That is a harder job, not a softer one.

So the move is small, on purpose. Tomorrow morning, take the most boring job you still do by hand: triaging failures, closing stale issues, chasing a flaky test. Wrap one capped loop around it. Brakes first. Small enough that you read every change.

Nobody who ships two hundred changes a month started with a hundred agents. They started with one loop they trusted. Build that one.