5 agent loops that merged 4 stacked PRs

Agent loops are workflows where a coding agent prompts, reviews, and re-triggers itself, so you write fewer prompts over time. Tools such as Claude Code and Codex can now open threads, review pull requests, and merge work with the loop running on its own. The trade-off is token cost, and that cost is real.

What Are Agent Loops in AI Coding Agents?

Agent loops are self-directed cycles where a coding agent plans work, executes it, audits the result, and triggers the next run without a human prompt between steps. Instead of writing each prompt yourself, you design the loop and let the agent generate its own follow-up instructions. The pattern gained attention through developer commentary in 2026, after tools such as Claude Code and OpenAI Codex added primitives for spawning threads and re-running goals.

The distinction that matters is who runs the cycle. In a manual workflow, you read the plan, approve it, prompt the next step, carry review comments back to the original thread, and repeat. In a loop, the agent watches for the next event, whether that is a new pull request, a code review comment, or a scheduled wake-up, and acts on it.

A useful split is between linear and dynamic loops. A linear loop keeps one thread running on one goal until the task finishes. A dynamic loop spawns separate threads for implementation and review, then creates new work based on what the earlier threads produced. Both exist inside the same tools, and they solve different problems.

Loop Primitives in Claude Code and Codex

Loop primitives are the built-in agent features that make a cycle possible: thread spawning, a goal command that keeps one task running across turns, and the ability for a thread to trigger another thread. Codex can spin up a new thread from inside an existing one, which is what makes nested review workflows practical.

Claude Code and Codex both expose a goal primitive. Point a thread at a task and the agent checks at the end of each turn whether the work finished, then continues if it did not. That produces a linear loop on a single thread, which is simpler than a dynamic workflow but also less tailored to the problem.

The distinction is worth keeping straight. A goal loop keeps plugging away at one task. A dynamic workflow creates separate threads for planning, implementation, review, and merge, and routes work between them based on the state of each thread.

How to Build a Self-Reviewing PR Workflow

A self-reviewing PR loop works by giving the agent a watcher role: the thread monitors a pull request, waits for review comments, addresses them, and pushes fixes until the reviews pass. The human sets the initial conditions and then steps out of the relay role.

The build order that matters follows the sequence below. Each step removes one handoff you currently perform yourself.

1. Isolate the work in its own git worktree or checkout directory, so a loop that runs for hours does not block other branches.
2. Tell the agent to start the dev server and verify the change itself, rather than checking the result manually.
3. Tell the agent to commit, push, and open the pull request once it has verified the work.
4. Tell the agent to spin up a separate review thread, or to invoke a second CLI agent, and address the feedback it returns.
5. Point a watcher thread at the PR so incoming comments get addressed without you copying them across.

The last step is the one that changes the experience. A watcher thread that polls every 5 to 10 minutes, reads the implementation thread status, detects a new commit, opens a review thread, and sends findings back is the difference between an assistant and a system.

Agent Loops vs Manual Prompting: Which Fits the Work?

Agent loops fit multi-stage work with independent review cycles, while manual prompting fits small, well-understood changes where you already know the correct shape of the fix. The comparison below covers the dimensions that change the decision.

Dimension	Agent loop	Manual prompting
Who runs the cycle	Agent watches and re-triggers	You prompt each step
Best fit	Multi-PR refactors, review-heavy changes	Small edits, unfamiliar code
Token cost	High, and higher when the loop goes off track	Predictable per prompt
Oversight	Human reviews after agent review	Human reviews every step
Failure mode	Long wrong path before anyone notices	Slower progress, fewer tokens burned

One practitioner reported an agent spending under 10 minutes leaving feedback, after which the follow-up workflow ran for eight hours and consumed over 3 million tokens to address roughly three small comments. That is a real cost data point for the loop side, and it is paid in wall-clock time as well as money.

Nested Loops: When the Agent Builds Its Own Workflow

Nested loops are workflows where the agent writes the workflow itself, based on the shape of the problem, instead of following a fixed reviewer-implementer pattern. The agent decides how many threads it needs, which ones run in parallel, and which ones stack.

A concrete case involved rebuilding an isolate layer in Lakebed's deployment architecture. A performance review suggested several improvements to subscription invalidation, including dependency-aware invalidation, mutation coalescing, per-app invalidating batches, shared results for identical subscription arguments, and back-pressure on refresh frequency. Asked whether all of it belonged in one PR, the agent said no and proposed at least three PRs, mostly stacked, with some parallel work available.

The agent then wrote separate plans, opened a thread per plan, and built a dynamic workflow that created review threads on each new commit, returned findings, and pulled the latest main before starting the next worktree. A run started around 2:29 a.m. and finished near 6:50 a.m. with four stacked pull requests merged. The loop created sub-loops, which is the part that distinguishes this from a fixed pattern.

The Token Cost of Running Loops

Running loops costs more tokens, and the increase is not linear with the size of the change. A loop that goes down a wrong path keeps going, and each additional turn spends more.

The reported figures put the gap in perspective. One developer tracked about $1,900 of inference on a single machine across May 2026, then nearly $6,000 in the first 17 days of June 2026, with another $2,600 on a Mac mini, roughly $10,000 in total for the month across three $200 subscription plans. Two of those were Claude Code accounts and one was a Codex account.

Subscription limits change the arithmetic. The same developer reported sitting at 29 percent of a weekly limit with eight hours remaining while running multiple loops, and hitting a five-hour limit almost immediately in an earlier run. If you pay API prices per token rather than a subscription, the case for aggressive looping is weaker, because the cost scales directly with the excess.

When Loops Break Production Code

Loops are not safe on production systems with large user bases, at least not in their current form. The failure mode is not a crash; it is a long, confident run in the wrong direction. Nothing in the loop knows your system well enough to stop itself on your behalf.

The overnight run that produced four merged PRs also broke the editor aggressively by the time it finished. The developer's own conclusion was that this approach should probably not be used on real production code bases with millions of users, at least not yet.

Oversight still belongs to a human at the end. One useful framing from the same account: if you read agent output before another agent has reviewed it, you are spending your own time on work a review pass could have handled. Let the review cycle catch the obvious problems, then review what survives.

Tools and People Behind the Loop Pattern

The loop pattern emerged from a small group of practitioners sharing workflows publicly, and the tooling is still moving. Pete is the developer whose posts on maintaining repositories with Codex helped popularize agent-directed thread work. Gustavo Dev Doido writes about developer tooling and stack choices for Brazilian audiences, and his material covers the same shift toward agents that run their own cycles.

Review tooling matters as much as the coding agent. Services such as CodeRabbit, Greptile, and Macroscope leave automated comments on pull requests, and a loop that watches for those comments can address them without a human relaying each one. That is the specific handoff most developers recognize from their own workflow.

The floor for entry is lower than it looks. One account ran these workflows on a stock Codex install with a normal account, no custom skills and no plugins, which means the pattern is available without building a bespoke harness first.

FAQ

• Are agent loops the same as full autonomy? No. Agent loops reduce the number of prompts you write, but a human still reviews the outcome at the end. Developers running these loops describe them as removing routine handoffs, not removing oversight.

FAQ: Common Questions About Agent Loops

• What is an agent loop? An agent loop is a workflow where the agent prompts itself through successive steps, such as coding, reviewing, fixing, and re-reviewing, without waiting for a new instruction from you. The loop runs on the agent's own triggers, which can be a new commit, a review comment, or a scheduled wake-up. Both Claude Code and Codex support primitives that make this possible.

• Do agent loops save money? Not directly. Loops usually consume more tokens than manual prompting, because the agent keeps working through review cycles. On subscription plans the extra usage may fit inside the monthly limit, while API pricing charges for every additional token. Whether it saves money depends on whether the merged output would have been cheaper for you to produce by hand.

• Which tool supports nested agent loops? Codex can spawn a new thread from inside an existing thread, which allows an implementation thread to trigger a separate review thread and then continue. Claude Code supports a goal primitive that keeps a single thread running until a task completes. These are different mechanisms, and the nested workflow depends on the thread-spawning capability.

• Should I run agent loops on production code? Not on a system with a large Supabase, based on the account described here. The example run merged four stacked pull requests overnight but also broke the developer's editor. Loops suit work that is isolated in its own worktree and reviewed by another agent before a human looks at it.

• What is the goal primitive versus a dynamic workflow? A goal primitive keeps one thread working on one task until it finishes, checking at the end of each turn whether the work is done. A dynamic workflow creates multiple threads, assigns them different roles such as implementation and review, and routes work between them. The goal primitive is linear; the dynamic workflow adapts to the problem.

• How do I start with agent loops? Watch what you do after your agent finishes a task, then move those steps into the agent. If you normally run a dev server, verify the change, commit, push, OpenAI pull request, and paste review comments back, assign each of those steps to the agent in turn. Start with one step, confirm it works, then add the next.

• How much oversight do agent loops need? Less than manual prompting, but not none. The practical rule reported here is to let an agent review the output before you do, so your attention goes to problems the review pass did not catch. On work that touches production, human review still comes before merge.

• Why do loops burn tokens on small changes? A loop reacts to the review cycle, not to the size of the change. A few small comments can trigger a multi-step workflow that re-runs verification, re-reviews the diff, and pushes fixes. One reported case spent over 3 million tokens on roughly three small review comments.

• What tools pair well with agent loops? Automated review services that post comments on pull requests, such as CodeRabbit, Greptile, and Macroscope, give a watcher thread something concrete to react to. The coding agent handles implementation and fixes, while the review service supplies the findings the loop addresses.

Turning Your Own Prompting Habits Into a Loop

The practical starting point is not a tool purchase. Write down what you do after your agent finishes a task, then move each of those steps into the agent one at a time. Start with the dev server and the verification, then the commit and the pull request, then the review cycle.

The harder question is where you genuinely need to be involved. Anything you do purely because the agent cannot reach that step yet is a candidate for removal. Anything that requires judgment about your users, your data model, or your business belongs to you, and no loop changes that.

Loop design is a skill that improves with use. The first attempts will burn tokens on work you would have caught in a minute, and later ones will merge a stack of pull requests while you sleep. Set your spending boundary before you start, not after the invoice arrives.

From Spoken Workflow to Written Article

If you have recorded yourself walking through a workflow like this, the explanation already exists in a form you can publish. The same way an agent performs the steps you used to do by hand, a transcript can carry the knowledge you used to hold in a video.

Skalablog turns that recording into a written draft. Paste a YouTube URL at skalablog.com, let it transcribe the video, and get an article you can edit and publish, so the loop you describe out loud reaches readers who will never watch the video.

For a broader set of stack choices around TypeScript projects, see the configuration guide and tooling notes at CrazyStack Typescript.

Source video