It sits at the top of these four layers

These "X engineering" terms aren't replacing each other — they stack, each layer managing something one size bigger than the one below: from a single sentence, to a context window, to a single run, to a self-sustaining loop. Click into each layer to see what it manages and how big the blast radius is when it fails.

Take the same bug — an agent misreading some function's return value — and run it through all four layers: the higher up you go, the later it's caught and the more it costs. At the loop layer, that misreading gets written into a state file, read back as fact the next day, and built on layer after layer — by the time anyone looks, that wrong assumption has become a load-bearing wall.

This is the one intuition worth holding onto from loop engineering: the cost of an error equals how many rounds it survives before someone catches it, and a loop, by construction, is a machine for maximizing the number of rounds. Everything that follows — evaluators, human checkpoints, budget caps — exists for exactly one purpose: to shorten the distance between "the mistake happens" and "the mistake is caught."

One cycle, five steps — skip any one and it breaks in a predictable way

Don't misread "loop" as idling. Every round does something concrete: find work worth doing, hand it off, verify it's correct, save the state, decide what's next. Skip any of the five steps, and the loop either won't turn, or it'll spin in place — and it breaks in a specific, named way.

Let's use Osmani's own example — the "morning triage loop" he built for himself — to walk through what each step does, and which named failure mode you get if you skip it.

These five steps aren't an optional checklist — they're an interdependent whole. Disciplined teams install all five; rushed teams install only the first two (discovery + handoff), because those two produce visible output, while the last three produce "safety" — and safety is the easiest thing to skip.

Building a loop means assembling six parts

The five steps describe "what happens in one round"; the six parts describe "what you need in hand to make it turn." They map one to one: discovery runs on skills, handoff runs on worktrees, verification runs on sub-agents, persistence runs on memory, scheduling runs on automations. Click into each card to see what problem it solves.

Get all six parts in place and the loop has a skeleton: automation makes it move, worktrees keep it from fighting itself, skills keep it from repeating work, connectors let it see outside, sub-agents let it self-correct, memory lets it remember. But building the skeleton is just the start — the same six parts, in two different people's hands, can produce completely opposite outcomes, which is the topic of the last section.

The hardest step: why AI can't grade its own homework

The hardest part of a loop was never getting the agent to run — it's putting something inside the loop that can say "no," and the agent that wrote the code is precisely the one least likely to say it.

② The fix isn't tuning the author, it's swapping the judge. Tuning the generator to be more self-critical is a dead end — you can't ask an author to step outside their own perspective. What works is bringing in an independent agent that looks at the code from zero, carrying a completely different set of instructions, untouched by any of the original self-justification. Tuning an independent skeptic is far easier than turning an author self-critical. The inspiration comes from GANs (Generative Adversarial Networks): one network creates, the other finds fault — translated to code, one writes, the other reviews.

③ Reading code isn't enough — you have to click through it. If the evaluator only reads code, it's judging "does this look right," not "does this actually work." For frontend tasks, Rajasekaran hooked the evaluator up to Playwright MCP so it acts like actual QA: opening the page, clicking buttons, taking screenshots, inspecting the DOM. The basis for judgment shifts from "this JSX looks fine" to "I clicked the button, the page navigated, here's the screenshot." He also swaps the underlying model while he's at it — the same model with a different set of instructions often still carries the same blind spots. A calibration the community often uses: have the evaluator default to assuming the code is broken until proven otherwise — the default posture should be suspicion, not trust.

④ Maker-checker: who swings the final hammer. Claude Code turns this structure into a primitive with /goal: give it a condition, and it runs until that condition is met. The key part is that after every round, whether the condition is met gets judged by a fresh, small, fast model — not the model that's currently doing the work. This is the maker-checker principle banks have used for decades.

Codified as config, the evaluator looks like this — every line here is executing one of the four principles above: swap the role, default to broken, actually verify hands-on, give itemized reasons.

ROLE: Adversarial code reviewer.
ASSUME: this code is BROKEN until proven otherwise.
       # Default to assuming the code is broken until proven otherwise
DO NOT praise. Find what fails.  # No praise allowed — just find what breaks

CHECK, in order:        # Check in this order
  1. Does it run? (execute, don't read)   # Does it run: execute it, don't just read it
  2. Tests: run them, paste real output.  # Run the tests, paste the real output
  3. Edge cases the author skipped.       # Edge cases the author skipped
  4. Does behavior match the ticket?      # Does behavior match the ticket

USE Playwright MCP: open the page, click,
    screenshot, inspect the DOM. Judge behavior, not intent.

VERDICT: PASS only if every check holds.
         Otherwise REJECT + list each reason.
         # PASS only if every check passes, otherwise REJECT with itemized reasons

/goal all tests in test/auth pass and the lint step is clean
# Runs until "test/auth all pass AND lint is clean"
# Note: /goal runs until the condition is met — different from /loop (reruns at a fixed interval)

A loop's floor is set by its evaluator. The generator's caliber determines what the loop can produce; the evaluator's caliber determines what it won't produce. Structurally splitting generation from judgment, tuning the evaluator to be a skeptic, having it actually verify hands-on, and handing the final hammer to a fresh model — these four steps together are the whole recipe for giving a loop the ability to say "no."

One person's morning, and Stripe's 1,300 PRs a week

Two real loops, wildly different in scale, but identical in skeleton: a trigger kicks things off, a set of constraints keeps it on the rails, and a human checkpoint sits at the end. "It runs while you sleep" was never about the model being stronger — it's about how solid this skeleton is.

The most counterintuitive part of Stripe's setup: Minions isn't built on a stronger model — it's a fork of the open-source tool Goose. Its core claim is that reliability comes from the quality of the constraints, not the size of the model. Architecturally, deterministic gates (blue) and creative LLM steps (green) interlock in sequence — anything that can be solved with deterministic logic never gets handed to the probabilistic model. Where that line gets drawn decides whether the loop is reliable. (This case was disclosed by Stripe engineer Steve Kaliski on the How I AI podcast.)

What "runs while you sleep" actually depends on

Both local /loop and desktop scheduled tasks need the machine to stay on — turn it off and they stop. To run while the machine is off, the right answer is Cloud Routines or GitHub Actions' scheduled triggers. The three approaches each cover a different slice:

The point isn't which one's better — it's that these are two different capabilities: local scheduling means "run more rounds while I'm around," cloud scheduling means "keep running while I'm gone." Treating local reruns as the whole of "unattended" is the most common misunderstanding — close the laptop lid and the loop you thought was autonomous quietly stops. Mature loops tend to use both: local handles the tight, up-close checks, cloud handles the overnight sweep.

Step by step: build your first loop

Stripe's pipeline is the destination, not the starting point. Your first loop should be small enough to barely look like a system: something that checks on a few things whenever its time comes around. The five steps below can be copied directly, each with commands and config, adding up to a minimal but complete loop that has all six parts.

① Start a /loop

Available since v2.1.72, it reruns the same task at an interval. Scoped to the session, a repeating task expires after 7 days, and it runs on your local machine — stop when the machine shuts down. Three ways to use it:

/loop 5m check the deploy   # Fixed: rerun every 5 minutes
/loop check the deploy      # Agent sets its own pace
/loop                       # Reads the task from .claude/loop.md

② Use a skill for automatic discovery: triage first

Just rerunning one line doesn't make it a loop. Give it a prompt: check three things every morning, and list what's worth acting on. "Scheduled + auto-discovery" is loop-engineering 101. The discovery logic should live in a skill, not in the schedule — instructions baked into a cron job rot once nobody updates them, while a SKILL.md file can be maintained and reused.

NAME: morning-triage
WHEN: invoked each morning by automation.
      # Invoked each morning by automation
READ:
  - CI runs that failed since yesterday   # CI runs that failed since yesterday
  - issues opened in the last 24h         # Issues opened in the last 24 hours
  - commits merged since the last run      # Commits merged since the last run
JUDGE: for each item, is it worth acting on?
       Skip noise. Keep only actionable findings.
       # For each item, judge: actionable now, or just noise? Keep only actionable findings
OUTPUT: write findings + status to
        ./state/triage.md (one row per finding).
        # Write to ./state/triage.md, one row per finding

③ Add a state file

Don't leave the results sitting in the chat window. Write every finding, and how far along it is, into a markdown file (or a Linear board). The agent forgets; the repo doesn't.

| finding         | source    | status   |
|-----------------|-----------|----------|
| auth test flaky | CI #4821  | fixing   |
| null deref      | issue 92  | PR open  |
| stale dep       | commit a3 | inbox    |

④ Add a /goal evaluator

The most critical step, and the easiest one to skip. /goal (since v2.1.139) runs until a condition is met, with a different model judging whether that condition has been reached. Note it's different from /loop: /loop reruns at a fixed interval, /goal runs until it hits the target, with the stop condition judged by a fresh small model. Pair it with the reviewer.md from the previous section (defaults to assuming the code is broken, verifies hands-on, gives itemized reasons) so it finds fault every round.

/goal all tests in test/auth pass and the lint step is clean
# Runs until "test/auth all pass AND lint is clean," judged by a fresh small model

⑤ Add --worktree for parallel isolation

Use --worktree (or -w) to give each background agent its own worktree — one worktree per task, so multiple agents editing code at once don't collide on files.

claude --worktree fix/auth-test  "draft the fix"
claude --worktree fix/null-deref "draft the fix"

The six-part checklist for your first loop

Check them off and see if you're fully equipped. The first two determine whether it runs at all; the last four determine whether anyone's watching once it's running and something goes wrong. The most common beginner mistake is installing only the first two, ending up with a loop nobody watches, nobody can stop, and that's still nodding at itself.

A minimal loop with all six parts

Turn the checklist into code, and you get something small enough to read in one breath — yet it carries every organ a real loop needs, just scaled down. The six comments map one to one onto the six parts.

# 1. Scheduling — a real trigger
on:
  schedule:
    - cron: '0 6 * * *'   # Every day at 06:00, runs in the cloud

# 2. Discovery — calls a skill, not a blob of instructions
run: claude --skill morning-triage

# 3. Persistence — state written to disk
#    the skill writes ./state/triage.md and commits it back to the repo

# 4. Handoff + Verification — one worktree per finding, runs until target
for finding in $(parse ./state/triage.md); do
  claude --worktree "fix/$finding" \
    --goal "tests pass and lint is clean" \
    "draft a fix for $finding"
done

# 5. Verification — stop judged by a fresh model after every round,
#    plus a reviewer agent whose whole job is finding fault

# 6. Human review — the door left standing open
#    PRs only open, never auto-merge; anything uncertain goes to ./inbox/

Get all six in place and even a tiny loop is a real loop; miss any one and it's one of the five failure modes from the earlier section, just wearing a disguise. Your first loop should stay small — but the "can-say-no" check and the human review checkpoint must be fully installed.

A loop quietly runs up four separate tabs

A loop that can run itself is, at the same time, a loop that can err by itself. The more smoothly it runs, the more quietly it goes wrong. Four kinds of cost accumulate silently while it's running, and none of them ever sound an alarm in the moment.

Trace how one triggers the next through a concrete scenario: a loop opens 20 PRs overnight, all tests green, looks like a big win on the surface. But 3 of them hide small bugs the tests don't cover.

Those 3 buried bugs are now sitting in a codebase you no longer fully understand, "watched over" by someone who's already stopped looking — until one of them surfaces in production. The four costs aren't a list of independent risks; they're four faces of the same failure, feeding each other, all coming due at once.

Guarding against each takes a different move:

All four share one trait: while the loop is running, they're completely silent. What's most fascinating about loop engineering is that it lets one person do the work of a team; what's most dangerous is exactly the same thing — a team would argue with itself, but one person running a pile of loops can easily end up in an echo chamber where nobody argues back. The gatekeeper is, and always must be, human judgment.

You're still the engineer, not just the person who presses go

The same loop, built by two different people, can end up in opposite places — and the difference isn't in the loop itself.

One person uses a loop to move faster on things they already understand deeply: they read the code, they're confident in the direction, and the loop amplifies the judgment they already had. Another person uses the exact same loop so they never have to understand it in the first place. Six months later, the first person has gotten stronger, and the second has become the gatekeeper of a machine they can no longer read.

A loop isn't the kind of tool whose quality is fixed by the tool itself — it's strong enough to faithfully amplify whatever you bring into it: bring understanding, and it amplifies understanding; bring laziness, and it amplifies laziness. It's a faithful multiplication sign, and what it multiplies is the person who built it.

A loop makes generation almost free: code, plans, PRs, fixes, nearly for nothing. What stays scarce is judgment: knowing which plan is right, which line should stop you, which output runs fine but is wrong at the root. A loop can generate a hundred options, but it can't actually choose between them — or rather, it chooses by "looks plausible," not "is actually correct," and that gap is exactly why the engineer still exists. So loop engineering hasn't devalued judgment — it's stripped away everything that doesn't require judgment, leaving judgment as the one thing left. The engineer's value has moved from "types fast, knows a lot of APIs, is willing to write boilerplate" to "knows which path is right, which line to stop at, which output runs fine but is wrong underneath."

build the loop, but build it like someone who intends to stay the engineer, not just the person who presses go.Addy Osmani, "Loop Engineering," June 2026

In the same week of June 2026, Google Chrome's Addy Osmani, Anthropic's Boris Cherny, and OpenClaw author Peter Steinberger each independently landed on the same thing, named by Osmani: you go from "the person operating AI" to "the person designing the system that drives AI." What you write is no longer words for AI — it's something that automatically sends AI words.

The upside: one person can do the work of a whole team, running even while you sleep. But a loop that runs itself is also a loop that errs by itself — the more smoothly it runs, the more quietly it goes wrong, especially at the hardest and most often skipped step: verification.

One turn of a loop is five steps: find what needs doing → hand it off to AI → independently verify it's correct → save the progress → automatically rerun when it's time. Skip any one step and the loop either won't turn, or spins in place.

Skip any one step and it breaks in its own specific way: skip verification → nodding loop (approves itself), skip persistence → amnesiac loop (starts from scratch every day), skip scheduling → manual loop (nobody runs it once the demo's over), skip discovery → blind loop (you still have to assign the work), skip handoff → tangled loop (several AIs run in parallel and make a mess).

The hardest of the five steps, and the most often skipped, is verification — and you can't let the AI that wrote the code grade itself: its head is full of reasons for "why I wrote it this way," so all it does is praise itself. You need an independent AI that defaults to assuming the code is broken, and it has to actually open the page, click the buttons, take screenshots — not just read the code. Just like at a bank, where entering a large transfer and reviewing that transfer must be two different people.

This pattern is already running at real scale. Stripe's Minions pipeline merges over 1,300 PRs (pull requests) every week, none of it hand-written by a human — not because of a stronger model, but because the deterministic parts (like forcing a code check to run) are hard-coded and the AI can't route around them.

The numbers here all come straight from the people involved (the Stripe engineer, Steinberger himself), with no third-party reproduction; widely circulated claims like "Claude Code writes 90% of its own code" are mostly secondhand — treat those as rough reference only. To get hands-on, section 7 of the full article lays out /loop, /goal, --worktree, a SKILL.md config, and a complete minimal loop — all ready to copy directly.