Loop Engineering: An Engineering Paradigm for AI That Writes Code and Merges PRs Autonomously

When generation becomes nearly free, judgment becomes the scarcest resource. Loop Engineering isn't about letting AI write code for you—it's about designing a system that can write its own prompts, verify itself, and stop when it should.

Stripe has an internal system called Minions that merges over 1,300 PRs every week—not written by humans, but written by machines that run tests and open PRs on their own, with humans only doing a final glance. The trigger is as light as adding a bot in Slack or clicking an emoji, and the system handles the rest. This practice recently got a name: Loop Engineering.

Its core isn't some new tool, but a role shift: humans move from operators inside the loop to system designers outside the loop. What you write is no longer the next sentence for an Agent, but a system that can discover tasks, distribute them, verify, persist state, and kick off the next round on its own.

From Prompt to Loop: The Evolution of the Four-Layer Engineering Stack

The "X Engineering" terms of the past two years can be understood as a building stacked layer by layer. Prompt Engineering governs how to write a single sentence; Context Engineering governs what goes into this round's window; Harness Engineering governs which tools come with a single run and what counts as done. All three layers share a common premise: a human is still sitting at the keyboard, pressing Enter round after round.

Loop Engineering kills that premise. In one week of June 2026, three people almost simultaneously lit the fuse: Peter Steinberg said stop writing prompts directly to Coding Agents and instead design Loops that write prompts for you; Boris Cherney had long been letting Loops issue continuous instructions; and Eddie Asmani consolidated these into an article on June 7, formally naming it. The same direction within a week is usually not a coincidence, but a sign that the underlying tools just crossed a threshold—Coding Agents are now reliable enough to do non-trivial work unattended, mainstream tools support scheduled runs, parallel isolation, sub-Agents, and external connections, and per-run costs are low enough that repeated runs don't hurt.

Five Actions and Six Components of a Loop Cycle

A Loop cycle has five actions: discover, hand off, verify, persist, schedule. Supporting them are six components: automation, workflows, skills, connectors, sub-Agents, and external memory.

Eddie Asmani's "Morning Triage Loop" is a good example: a scheduled task wakes up every morning, a triage Skill reads yesterday's failed CI, open Issues, and recent Commits, and writes what's worth handling into a Markdown state file; each issue gets an isolated Git WorkTree, one sub-Agent drafts a fix while another specifically hunts for flaws; connectors open PRs and update tickets; anything unsolvable goes into a pending box for humans. The state file stays, and work continues the next day. No step needs a human pushing it along, but it stops where it should wait for a human.

This sentence is the soul of the whole thing—a good Loop isn't fully automatic; it knows where to hand back control.

Git WorkTree is a feature Git has offered since version 2.5, allowing multiple working directories to be checked out simultaneously from the same repository. Each WorkTree has its own branch and file state but shares the same object database. For Loops, this means multiple sub-Agents can each modify code in an isolated directory without overwriting each other's edits or interrupting running tasks when switching branches. This is precisely the underlying mechanism by which the "hand off" step avoids "tangled Loops": isolation instead of queuing, making parallelism possible. Note that WorkTree only isolates the filesystem and branch state, not network ports, databases, or external services. So when multiple Agents run in parallel, resource-level isolation (such as separate containers or separate test databases) is still needed at a higher layer—otherwise conflicts migrate from the filesystem to the runtime.

The Hardest Part: Putting an Agent That Can Say "No" Inside the Loop

The hardest part of a Loop isn't getting it to run, but putting something inside it that can say no. And the Agent writing the code is precisely the least likely to say no. Anthropic engineer Prithvi Rajasekaran has a sharp observation: when you ask an Agent to grade code it just wrote, it tends to confidently praise itself. This isn't because the model is unintelligent—it's a structural problem with grading your own homework. When it looks back at its own output, it doesn't see the result; it sees the chain of reasoning it just used to convince itself.

Inside a Loop, this problem is amplified exponentially. If whether each round is good enough is judged by the Agent that just finished writing the code, the Loop will nod along round after round, drifting away from real quality at machine speed. The solution isn't to remind it to "please self-check strictly," but to structurally swap in a different judge: one Agent writes, another Agent reviews with completely different instructions—perhaps even a different underlying model. The idea is somewhat like GANs: one generates, one finds faults.

Here's a counterintuitive conclusion: configuring an independent evaluator to be sufficiently critical is far easier than making the generator be harsh on itself, because large models are inherently overconfident. Even more important, the evaluator can't just read code—reading code alone means it judges "does it look right," not "does it run right." So give it tools, like Playwright MCP, to actually open pages, click buttons, take screenshots, and inspect the DOM. The basis for judgment shifts from "this JSX looks fine" to "I clicked the button, the page actually navigated, and here's the screenshot." Claude Code's Goal productizes this structure: give the Agent an explicit stopping condition, and after each round a new small model judges whether the condition is met. If not, it proceeds to the next round instead of kicking the ball back to a human.

A Loop's floor is determined by the evaluator. The generator determines what it can produce; the evaluator determines what it won't let slip through.

GAN (Generative Adversarial Network) is a deep learning framework proposed by Ian Goodfellow in 2014, consisting of two networks: a Generator and a Discriminator. The Generator produces fake samples, the Discriminator distinguishes real from fake, and the two improve together through adversarial training until the Generator can produce samples the Discriminator struggles to tell apart. Here we borrow its core idea—having "generation" and "judgment" carried out by two independent roles with opposing objectives. In the context of Loop Engineering, the Agent writing code acts as the Generator and the reviewing Agent acts as the Discriminator. What matters isn't how smart the two Agents are, but that the judge's objectives are structurally separated from the generator's, preventing a single chain of reasoning from convincing itself. Unlike GANs, the Discriminator here must also connect to a real execution environment (such as Playwright MCP) to verify behavior, rather than judging from static observation alone.

Five Ways Loops Go Wrong: Skip a Step, Fall into a Pit

Failure is more common than success, and more instructive. Every runaway Loop corresponds to one of the five actions being skipped:

• Skipping verification → Nodding Loop: runs hundreds of rounds, never says no to itself, errors accumulate at machine speed.
• Skipping persistence → Amnesiac Loop: forgets everything when the window refreshes, starts from the same place every morning.
• Skipping scheduling → Manual Loop: impressive on demo day, dies quietly the day someone forgets to run it.
• Skipping discovery → Blind Loop: still needs a human task list every day; only "doing" is automated, not "finding."
• Skipping handoff → Tangled Loop: five Agents modify the same directory simultaneously, edits overwrite each other, merge scene is a mess.

Hastily built Loops most easily install the two components that produce visible output—"discovery" and "handoff"—then skip verification, persistence, and scheduling, the things that actually keep it alive. It looks automated, but it's really a high-speed garbage generator that no one watches, no one can stop, and only nods along.

Loops also have several invisible bills that don't clear themselves: verification debt—a merged PR doesn't mean it's correct; problems hide where tests don't cover; comprehension rot—the faster the Loop delivers code you didn't write, the further your mental system map falls behind; cognitive surrender—the more reliable the Loop, the easier it is for people to abandon their own opinions; token explosion—a single bug can spin all night, leaving behind not fixed code but an unfamiliar bill. These four reinforce each other: the more unverified output, the less people understand; the less they understand, the more easily they give up judgment; the more they give up judgment, the more the Loop runs unwatched; the longer it runs, the more it costs, producing even more unverified output.

Playwright MCP is a server implementation combining Microsoft's Playwright browser automation framework with the Model Context Protocol (MCP). MCP is an open protocol proposed by Anthropic in late 2024 for letting models call external tools and data sources in a standardized way; Playwright MCP wraps browser operations—opening pages, clicking, filling forms, taking screenshots, reading the DOM and accessibility tree—into tools the model can call. For the evaluator in a Loop, its value lies in upgrading the basis for judgment from static code review to real behavior verification—the evaluator can personally press buttons and take screenshots to confirm whether the page navigates as expected, rather than guessing "this code looks like it should run." This is one of the technical prerequisites that lets the "verification" step be structurally enforced rather than relying on the generator's self-discipline.

Three Disciplines: Installing Brakes into the System

First, set aside a little time each day to sample-read what the Loop produced. Force yourself to explain why each change was made the way it was. If you can't explain it, your understanding has fallen behind the codebase. It's best to catch this signal on a quiet morning, not in a production incident.

Second, set budgets before talking about automation. Per-run budget, daily budget, maximum retries—these caps aren't about saving money; they're circuit breakers. A Loop without caps is equivalent to handing its spending authority over to its own bugs.

Third, always keep a human intervention entry point. It's not that a human will intervene every time, but that they preserve the ability to intervene. Those who weld every door shut will find themselves without a key on the day they truly need to get in.

Why Stripe's 1,300 PRs Are Reliable

Back to the Stripe case—the reason it's reliable is remarkably plain: the model is sandwiched between a bunch of deterministic steps, and anything rules can solve is never handed to a probabilistic model. Linters are hardcoded gates the Agent can't skip. The 1,300 PRs still get human review at the end—humans haven't left; they've just moved from the position of writing code to the position of reviewing it.

If you want to get started, don't try to copy Stripe right away. Your first Loop should be so small it barely feels like a system: start with scheduled triage, write discoveries into a state file, add an independent evaluator, set budgets, and keep human review points. Run it end-to-end, confirm the checks actually caught an error at least once, and then talk about scaling up. A Loop must first prove it can stop a bad Agent before it earns the right to run more Agents.

Loops make generation nearly free—code, plans, PRs, and fixes can all be produced in bulk. But judgment remains scarce: which approach is right, which line should stop, which output runs but is headed in the wrong direction. Loops can't give you that. It can generate a hundred options, but it can only judge "looks reasonable." And the gap between looking reasonable and actually being correct is where engineers will be most valuable going forward.

A Loop is an amplifier. Bring understanding, and it amplifies understanding; bring laziness, and it amplifies laziness. The same system: one person uses it to accelerate work they've already mastered, another uses it to avoid understanding. Six months later, the latter is just the gatekeeper of a machine they themselves can't read.

So that sentence is worth carving into your workstation: stop writing prompts for Agents yourself; go design systems that write prompts for you. But design it like someone who intends to remain an engineer, not like someone who just wants to press the start button. The evaluator, the state file, the budget caps, the human review point—these are four implementations of the same thing: preserving a human's ability to say no to a machine that says yes at high speed.

One-line Summary

Loop Engineering moves humans outside the loop as system designers, using independent evaluators to guard the quality floor.

Paragraph Summary

The article introduces Loop Engineering, an emerging engineering paradigm: humans shift from operators inside the loop to system designers outside it, no longer writing prompts sentence by sentence for Agents, but building a system that can discover tasks, distribute them, verify, persist state, and schedule the next round. Using Stripe's weekly merge of over 1,300 machine-generated PRs as an example, it shows reliability comes from deterministic gates and final human review. The article breaks down the five actions of a Loop cycle (discover, hand off, verify, persist, schedule) and six components, emphasizing that the hardest part is inserting an independent evaluator that can say "no," because generators can't reliably grade themselves. Five runaway modes each correspond to skipping a step, accompanied by four invisible bills: verification debt, comprehension rot, cognitive surrender, and token explosion. Finally, three disciplines: daily sample reading, setting budget caps first, and always keeping a human intervention entry point.