Loop Engineering
Systems That Prompt Your Agents

Chapter 1: The Four-Layer Stack

The "XX engineering" terms are not replacements for one another. They stack, each minding something one size larger than the layer below. The trap is to hear "loop engineering" and assume it makes the earlier three obsolete — it does the opposite. A loop sits on top of a working harness, which sits on top of curated context, which sits on top of a good prompt. Kick out any lower layer and the whole tower wobbles.

Prompt engineering is the bottom layer and the best known. It minds what to tell the model: wording, examples, role, tone. Its unit is one sentence — the words you write for the model. Its boundary is one exchange. Its core question: what should I tell the model? The trouble it cannot escape is that it assumes you are present every single time to hand the prompt in.

Context engineering raises the question from "what do I say" to "what should go into this window so the model can crack the problem." Its unit is one window — the model's entire field of view. Its core question: what to retrieve, summarize, and clear out right now? A window full of noise wastes even the best prompt, so this layer minds what comes in and what gets thrown away.

Harness engineering minds what an agent needs to carry for a single run: which tools, which actions, when to load context, how to recover from failure, and what state counts as done. Its unit is one run. Its core question: which tools, which actions, what counts as done? It arms one run — but it does not make that run repeat. With the first three layers in place, an agent runs cleanly once and then stops, waiting for you.

Loop engineering automates that "waiting for you" away. Its unit is the loop itself — a run that runs itself. Its core question: how do I make it run itself, over and over? Three verbs separate harness from loop. Runs on a timer: the loop wakes on schedule with no button-press. Spawns helpers: a turning loop splits off sub-agents — one drafts a change, another does nothing but pick it apart in review. Feeds itself: what the loop produces becomes its own input next round; yesterday's findings get written to a file, and this morning it reads that file and carries on.

That last verb — memory across conversations — is why it is genuinely a loop rather than a one-off task you happened to run many times. A task run repeatedly with no memory keeps rediscovering the same starting line. A loop remembers, so each turn begins where the last one ended. Table I lays out all four layers side by side.

Read the table as a staircase, because the four layers are not four unrelated topics — they are one quantity growing by a single size at each step. The unit of concern climbs from one sentence (prompt), to one window (context), to one run (harness), and finally to a loop that runs itself (loop). Nothing is discarded on the way up: a loop still contains runs, each run still fills a window, each window still holds prompts. That is exactly why the terms stack rather than replace. "Loop engineering" is not a newer, better name for prompting; it is the floor you reach only after the three below it already hold weight.

The reason this fine-grained split is worth the trouble is that each layer fails differently — so the check that can say "no" has to be installed in a different place at each layer. A bad prompt is caught on the spot, by you, in the same breath. Bad context shows up as a confidently wrong answer you then trace back to the poisoned window. But at the loop layer the system runs while you sleep, changes code you never looked at, and feeds its own errors into the next round — so the "no" cannot be you noticing in real time; it has to be something you built into the loop ahead of time. Keep that in mind: the higher you climb this staircase, the earlier and more deliberately you must place the thing that stops a mistake. Chapter 2 makes that danger concrete; the rest of the lesson is about where to put the "no."

Table I — The Four-Layer Stack. Each layer minds something larger than the one below.

Chapter 2: Blast Radius — Why Height Is Dangerous

Each layer of the stack fails differently, and the difference is the most important intuition in the whole field. To see it, take one fixed bug — an agent that misreads what a function returns — and watch the same mistake play out at each of the four layers. The bug never changes. Only the layer it lives in changes. And the damage it does scales wildly with that layer.

At the prompt layer, the misreading produces one wrong answer in one exchange. You are sitting right there. You read the answer, you see it is wrong, you rewrite the prompt. The mistake survives exactly one turn. Blast radius: a single bad reply, caught instantly.

At the context layer, the misreading comes from stale documentation that got loaded into the window. The model is now confidently wrong — it sounds sure because the bad source looked authoritative. But you notice the answer is off, you clear the context, and you reload fresh material. The mistake survives a little longer because it took a beat to realize the window was poisoned, but you still catch it in the same sitting.

At the harness layer, the agent acts on the misreading once — perhaps it edits a file based on the wrong assumption. But the run ends. The diff is sitting there, visible. You review it before anything ships. The mistake reached the point of doing something, but a human gate stood between it and production, and the gate held.

At the loop layer, the same misreading gets written into the state file. The next morning the loop reads that file back — not as a guess, but as established fact, because that is what state files are for. It builds the next turn on top of it. And the next. By the time anyone actually looks, the wrong assumption is load-bearing: other code now depends on it, undoing it means unwinding days of work, and nobody remembers it was ever a guess. The same one-line bug went from "caught in a sentence" to "structural."

This crystallizes into one sentence you should carry through the rest of the lesson: the cost of a mistake scales with the number of turns it survives before someone catches it — and a loop is, by construction, a machine for maximizing the number of turns. That is the central tension of loop engineering. The thing that makes loops powerful (they run unattended for many turns) is exactly the thing that makes their mistakes expensive (those mistakes also survive many turns).

Notice what is doing the damage in that walk. It is not the model — the very same one-line misreading sat at every layer. It is not even the act of acting on it; the harness layer acted on it too, and the gate still held. The damage came from distance: how far the running system is from a human who can look. At the prompt layer you are at the scene. At the loop layer you are asleep, and the system is three turns deep into building on a guess. The higher the layer, the farther you stand from the scene, and the longer mistakes pile up before anyone is looking. That distance — not model size, not bug type — is the entire risk profile of a loop.

This is why the real difficulty of loop engineering is the opposite of what beginners expect. The hard part is never building the loop — wrapping a harness in a timer and a feedback file is genuinely easy now, a few lines you will write yourself in Chapter 9. The hard part is putting something inside the loop that can stop it: a check that fires when you are not there, because by construction you will not be there. A loop is the one place in the stack where "I'll catch it when I review the diff" is no longer available to you. So the engineering effort moves entirely onto the question of what gets to say "no" while you sleep.

Everything in the later chapters — the evaluator that can say "no," the human checkpoint, the budget caps — exists for one reason: to shorten the distance between a mistake and its discovery. You cannot stop a loop from making mistakes; an automated mistake-maker will make automated mistakes. What you can do is make sure a mistake gets caught at turn 1 instead of day 5. Every safety mechanism in this lesson is a turn-shortener.

Chapter 3: The Five Moves of One Turn

The word "loop" is easy to misread as idle spinning — a thing that goes round and round doing nothing. That picture is wrong. Each turn of a real loop does something concrete: it finds work worth doing, hands it to an agent, verifies whether the result is right, saves the state, then decides the next step. Those are the five moves of a single turn: discovery, handoff, verification, persistence, scheduling. Drop any one of them and the loop will not turn — or worse, it will turn in place, looking busy while accomplishing nothing.

The cleanest way to make these concrete is Osmani's own morning triage loop, which we will return to again and again. In the morning, an automation kicks off on its own. A triage skill reads yesterday's failing CI tests, the still-open issues, and recent commits, and writes its results into a markdown file or a Linear board. For each finding worth acting on, it opens an isolated git worktree; one sub-agent drafts the fix, a second reviews it against the project's skills and tests. A connector automatically opens the pull request and updates the ticket. Anything it cannot handle goes to an inbox to wait for a human, and a state file survives so the next day picks up where this one left off. No step needs a hand — yet it stops to wait for a human exactly where it should.

Discovery figures out what this turn should do. In the example, the triage skill reads CI failures, open issues, and recent commits. The key is letting the agent find its own work rather than being handed a list. Crucially, the automation triggers a skill — knowledge made permanent — rather than a wall of instructions pasted into a cron job nobody will ever update. Discovery sets the ceiling on the whole loop's quality: surface work of no value and the other four moves are done beautifully in service of nothing.

Handoff moves the task from the scheduling system into the hands of the agent that does the work. Each finding worth doing gets its own isolated git worktree, so multiple agents can change code in separate directories without stepping on each other. The cleaner each task is cut, the easier verification and merging are later. A sloppy handoff — five agents in one directory — turns a clean loop into a merge nightmare.

Verification is the easiest move to cut corners on and the one least affordable to skip. After the first sub-agent drafts the fix, a second sub-agent reviews it — different instructions, sometimes a different model. The agent that wrote the code grades its own homework too softly; a dedicated hole-picker catches what the first talked itself into letting through. This is the "thing that can say no." A loop without a real check is just an agent nodding at itself. (Chapter 5 is devoted entirely to this move — it is the hard one.)

Persistence lands the result somewhere that survives the conversation: a PR and updated ticket via a connector, an inbox for what cannot be handled, and a state file recording progress. A loop's memory cannot live only in the context window — what is written to markdown or a board does not forget. And scheduling is what makes one turn into a loop at all: the triage runs automatically each morning, and the state file lets unfinished findings carry to the next day, which picks up on its own. Scheduling closes the cycle by feeding an unfinished turn into the next day's run. Table II maps all five moves onto the triage loop.

Table II — The Five Moves, mapped to the triage loop. Scheduling closes the cycle; verification is the move that can say "no."

Chapter 4: The Six Parts a Loop Is Built From

If moves describe what happens in one turn, parts describe what you must actually have in hand for the turn to happen at all. The two line up almost cleanly: discovery runs on skills, handoff on worktrees, verification on sub-agents, persistence on memory, and scheduling on automations. A sixth part — connectors — serves two moves at once. Six parts, six concrete things you can point at in a real repo.

Automations get the loop moving on their own, hanging off a schedule or a trigger. Without scheduling, what you hold is a single run, not a loop. The important detail: the automation should trigger a named skill, not a wall of instructions pasted into a cron job that nobody will ever update. Scheduling comes in more than one form — local (the machine must stay on) and cloud (it turns even with the machine off). Automations realize the scheduling move.

Worktrees are a built-in git mechanism for keeping multiple independent working directories inside one repo. Their value scales with parallelism: two agents writing the same file at once is exactly the same headache as two engineers committing to the same lines. Worktrees turn parallelism from "runs but messy" into "runs and clean." They realize the handoff move — each task gets its own isolated directory.

Skills make project knowledge permanent in a single file (SKILL.md), so the agent need not re-derive context every turn. Osmani names the cost they pay off as intent debt: the recurring price of explaining "what this project is, what the rules are, where the traps are" over and over. A skill can be reused and maintained; a wall of prompt cannot. Skills realize the discovery move — permanent knowledge of where to look for work.

Connectors (built on MCP, the Model Context Protocol) hook the loop to the outside world — the issue tracker, the database, a staging API, Slack. A loop that can only see the filesystem is a tiny loop. Connectors decide the loop's radius of vision, and a connector written for one tool can often be dropped onto another and used as is. They realize persistence (write a PR, update a ticket) and discovery (read issues, scan a board) — the one part that serves two moves.

Sub-agents split the one that writes from the one that judges. When a single agent is both player and referee, the referee plays favorites. Counterintuitively, tuning an independent judge to be picky is far easier than getting the generator to be hard on its own work — which is why a loop keeps an extra agent rather than letting one agent audit itself. Sub-agents realize the verification move. And memory is persistent state living outside a single conversation — a markdown file or a board. Memory realizes persistence.

That last part deserves a sharp distinction, because conflating the two is a common error. Memory is not context. Context is what the agent sees this round and is flushed on refresh — the moment a context window is cleared, the agent remembers nothing. Memory persists across rounds and days; it lands on disk so that today can pick up where yesterday left off. The slogan to keep: the agent forgets, the repo does not. Table III maps all six parts to the five moves.

Table III — Six parts mapped to five moves. With all six, a loop has a skeleton.

Chapter 5: Generator & Evaluator — The "Say No"

The hardest part of a loop is not getting the agent to run. It is putting something inside that can say "no" — and the agent writing the code is the one least likely to say it. This chapter is the heart of the whole field, because verification is the move everyone skips and the one that, skipped, ruins everything downstream.

Ask an agent to grade what it just produced and it tends to praise it, confidently, even when a human can plainly see the quality is mediocre — as Anthropic engineer Prithvi Rajasekaran observed while building long-running applications. This is not a smarts problem. It is grading one's own homework. The context window in which the code was written is already stuffed with the reasons it was written that way, so when the agent looks at its own output it does not see the result — it sees the chain of self-persuasion that led there. Inside a loop the flaw is amplified: if every "is this good enough?" is decided by the agent that just wrote it, each round it nods at itself, and the longer it runs the further it drifts from real quality.

Tune a skeptic; don't fix a modest author. Making the generator more self-critical works poorly. Rajasekaran found that tuning a standalone evaluator to be skeptical is far more tractable than making a generator critical of its own work. The difference is structural, not a matter of wording: you cannot ask an author to step outside its own perspective, but you can swap in another agent with entirely different instructions that looks at the code from scratch, carrying none of the self-persuasion. The idea is borrowed straight from generative adversarial networks (GANs) — one network builds, one picks faults — ported to a generator that writes and an evaluator that reviews.

The evaluator must act, not just read. Swapping agents is not enough. If the evaluator only reads code, it judges "does this look right," not "does it run right." On frontend tasks Rajasekaran hooked the evaluator to Playwright MCP so it could open the page, click buttons, take screenshots, and inspect the DOM like a QA engineer. That shifts the basis for judgment from "this JSX looks fine" to "I clicked the button, the page navigated, here is the screenshot." Swapping the underlying model too helps — the same model with new instructions often keeps its blind spots. A common community calibration tells the evaluator to assume the code is broken until proven otherwise: the default stance should be doubt, not trust.

Claude Code turns this whole structure into a primitive with /goal: give an agent a condition and let it run until the condition is met. After each turn a small, fast model checks whether the condition holds; if not, another turn runs instead of returning control. Completion is decided by a fresh model, not the one doing the work. This is the maker–checker principle — decades old in banking, where the person entering a large transfer and the person reviewing it must differ — applied to the stop condition. (Codex reaches the same capability through automations plus agent configuration; do not confuse /goal with /loop, which merely reruns on an interval.) Here is the reviewer agent and the stop condition, verbatim:

# Evaluator agent (.claude/agents/reviewer.md)
ROLE: Adversarial code reviewer.
ASSUME: this code is BROKEN until proven otherwise.
DO NOT praise. Find what fails.

CHECK, in order:
  1. Does it run? (execute, don't read)
  2. Tests: run them, paste real output.
  3. Edge cases the author skipped.
  4. 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.

# Stop condition, judged by a fresh small model
/goal all tests in test/auth pass and the lint
      step is clean

Read the reviewer line by line and notice every line is doing real work. ASSUME ... BROKEN until proven sets the default to doubt — it inverts the burden of proof so the agent has to earn a pass. The four CHECK items are ordered deliberately: check 1 says "execute, don't read" (the single most important shift); check 2 demands real test output, not a claim that tests pass; check 3 hunts the edge cases the author skipped (and the author always skips its own blind spots); check 4 ties behavior back to the ticket, so "runs" is not mistaken for "right." USE Playwright MCP is what makes it act. And the VERDICT is binary — pass only if every check holds, otherwise reject with reasons. There is no "looks good to me."

Chapter 6: Five Ways a Loop Goes Wrong

Before turning to loops that work, it is worth cataloguing the ways they fail — because the failures are more instructive than the successes and far more common. The beautiful symmetry here is that each anti-pattern corresponds to exactly one of the five moves being skipped. Learn the five failures and you have learned the five moves a second time, from the back.

The Nodding Loop (verification skipped) — the most common failure. The loop runs, the agent writes code, and the same agent declares it good. With no independent check, every turn produces self-approved output, and the loop accumulates plausible-looking mistakes at machine speed. The symptom is a loop that has never once said "no" to itself across hundreds of turns — a statistical impossibility for any real workload, and therefore proof that no real check exists. The fix is the generator/evaluator split of Chapter 5.

The Amnesiac Loop (persistence skipped) — the loop discovers good work, does it, and then forgets it happened, because the result lived only in a context window that was flushed. The next turn rediscovers the same work, or worse, redoes it and conflicts with the first attempt. The symptom is a loop that makes no cumulative progress: each morning it starts from the same place. The fix is a state file on disk — the agent forgets, the repo does not.

The Manual Loop (scheduling skipped) — a loop with four good moves but no automation is not a loop; it is a script the human runs by hand and then forgets to run again. It works impressively the day it is built and silently stops the day attention wanders. The symptom is a loop whose last run was the day it was demoed. The fix is a real trigger — a timer or an event — that does not depend on the human remembering.

The Blind Loop (discovery skipped) — the human still hands the loop its work each morning ("fix these three bugs"), so the loop has automated the doing but not the finding. This saves less than it appears to, because choosing what to work on is often the expensive part. The symptom is a human who is still spending their morning deciding what the loop should do. The fix is to teach discovery into a skill so the loop surfaces its own work.

The Tangled Loop (handoff skipped) — the loop runs several agents in parallel but lets them all change the same working directory, so their edits collide and the merge is a mess no one can untangle. The symptom shows up only under parallelism: a single-agent loop looks fine, and the problem appears the first morning five agents run at once. The fix is one isolated worktree per task. Fig. 4 maps all five anti-patterns to the moves they violate.

These five are not independent. A loop missing verification tends also to miss persistence, because a team careless about one check is usually careless about the others. In practice they cluster: the disciplined loop installs all five moves, and the hasty loop installs only discovery and handoff — the two that produce visible output — and skips the three that produce safety (verification, persistence, scheduling). That is the dangerous default, and we will return to it in Chapter 9. The next chapter shows three loops that installed all five.

Fig. 4 / failure table — each anti-pattern is one move skipped, mapping one-to-one onto the five moves.

Chapter 7: Three Loops That Run While You Sleep

Three public cases differ wildly in scale but share one skeleton: a trigger presses start, a set of constraints keeps it on the rails, and a human checkpoint sits at the end. "Running while you sleep" was never about how strong the model is — it is about how solid that skeleton is. Watch for the skeleton in all three.

(a) One engineer's morning. Osmani's triage loop, broken down in Chapter 3, runs automatically every morning. The one detail worth re-flagging: the automation invokes a skill, not a giant block of instructions glued into a schedule that nobody will ever update. This is what a loop one person can run looks like — one person, one machine, the grunt work done each morning. Here is the skill, in its compact form:

# .claude/skills/morning-triage/SKILL.md
NAME: morning-triage
WHEN: invoked each morning by automation.

READ:
  - CI runs that failed since yesterday
  - issues opened in the last 24h
  - commits merged since the last run
JUDGE: for each item, is it worth acting on?
  Skip noise. Keep only actionable findings.
OUTPUT: write findings + status to
  ./state/triage.md (one row per finding).

(b) Stripe's Minions: 1,300 PRs a week. For enterprise scale, the case to study is Stripe's Minions: more than 1,300 pull requests merged a week, not one line written by hand, as described by Stripe engineer Steve Kaliski on the How I AI podcast. The trigger is light — @ the bot in Slack, or add an emoji reaction. What makes it reliable is the stretch before the model wakes up: a deterministic orchestrator first assembles context, scanning links, pulling Jira, finding docs, and using Sourcegraph plus MCP to locate relevant code. Letting the LLM find its own context is the least controllable part, so that work — whose rules can be hard-coded — is taken out of the model's hands.

That is the load-bearing sentence of the whole chapter: anything deterministic logic can solve never goes to a probabilistic model. Where you draw that line decides whether the loop is reliable. The most counterintuitive point is that Minions is not built on a stronger model. It is a fork of the open-source tool Goose, and its core claim is that reliability comes from the quality of the constraints, not the size of the model. Its architecture interleaves deterministic gates and creative LLM steps (Fig. 5): the agent writes code, a hard-coded pipeline runs the linter and the agent cannot skip it, the agent fixes the lint, and a hard-coded step runs the commit.

The sandbox is Devbox on EC2, run on a "cattle not pets" basis: each environment is swapped out at will, so a thousand-plus agents run at once without stepping on each other. And critically, those 1,300 PRs are still reviewed by humans — the human did not leave, but changed desks, from writing to reviewing. That is the human checkpoint of the skeleton, scaled up.

(c) Choosing a scheduler. Local /loop and desktop scheduled tasks need the machine on; turn it off and the loop stops. To run with the machine off, the right answer is Cloud Routines or GitHub Actions schedule triggers. The choice between local and cloud is not a matter of taste — it follows mechanically from one question: is the loop's work glued to the local machine, or can it leave? A loop that must check a local development server every minute can only run locally (the cloud cannot see a process on your laptop, and the cloud interval cannot drop below an hour). A loop that should scan the repo's open issues at 3 a.m. should never be tied to a laptop — laptops get their lids closed, lose power, and get carried out the door. Table IV contrasts the options.

Table IV — Scheduling options compared. No single scheduler does it all; a mature loop often uses both.

The commands in this lesson are Claude Code's, but the capabilities are not specific to it. Codex offers the same five organs under different names, and a connector written for one side can often be moved to the other and used as is. Table V lines them up so you do not pin a command name on the wrong door. The lesson: loop engineering is a set of capabilities — scheduling, run-until-condition, parallel isolation, sub-agents, external connection, explicit skill invocation — not a product. Whichever toolchain you use, ask whether all six are present, not which brand of command provides them.

Table V — The same six capabilities across two toolchains.

Chapter 8: The Four Costs That Don't Clear Themselves

A loop that runs itself is, at the same time, a loop that makes mistakes by itself. The more cheerfully it runs, the more quietly it errs. Four costs accrue, and the dangerous thing about all four is that none of them sounds an alarm while the loop is running. They are silent debts that come due all at once.

Verification debt. Every PR opened and merged saves time, but the saved time turns into unverified output waiting to be paid back. The problem hides where tests do not cover — in the gap between "runs" and "right" — accumulating until some shipping morning when it blows up all at once. The guard is an independent evaluator: a different agent from the one doing the work (Chapter 5).

Comprehension rot. The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually understand. Reading code is more boring than writing it, and the loop has taken the writing; the codebase grows while the map in your head stalls. It sounds no alarm until a bug burrows into a corner you never read. The guard is to read the loop's output regularly and force yourself to explain a few changes — an inability to explain is a map needing an update.

Cognitive surrender. When the loop runs itself it is tempting to stop having an opinion and just take whatever it hands back. This is the attitude version of the first two: not "no time" but "no longer want to bother." The more reliable the loop, the easier it is to outsource judgment. The guard is one line — the loop can execute, but it cannot decide. You must at least remain capable of saying "this is wrong."

Token blowout. The only cost that hits the bill directly, and hard to estimate in advance: the loop hatches helpers, retries, and runs round after round, so one bug can spin idle all night and produce an unfamiliar bill rather than fixed code. The guard is hard caps set before shipping — per-run budget, daily budget, max retries — so an idle bug cannot burn an entire night's quota.

The four share one trait: silence while the loop runs. And they are not a list of independent risks — they are a single failure that wears four faces, each feeding the next. Fig. 6 shows the reinforcing cycle: unverified output erodes understanding, which invites surrender, which lets the loop run longer and spend more, which produces more unverified output. A clean circle, turning a little faster every night.

Why the costs compound instead of adding

Play the sim again with the guards off, and watch which arrow turns first. It is never the bill. The cycle ignites at verification debt — an unchecked PR ships — because that is the one cost that produces fuel for the next. Unverified output is code you now own but did not read, so it directly enlarges the gap that comprehension rot measures. A wider gap makes reading feel more hopeless, which is precisely the slope into cognitive surrender: when the map is already twenty changes behind, the rational-feeling move is to stop trying to keep it. And a human who has stopped looking imposes no ceiling on how long the loop runs or how many helpers it spawns, so token blowout follows for free — which produces yet more unverified output, closing the circle one turn tighter. Four costs, one engine; each one's output is the next one's input.

This is why the worked example above lands the way it does. Twenty green PRs is not four separate small problems you could triage one at a time; it is a single state in which all four costs have already advanced together. That is also why the sim's three guards are not "three fixes for three of the four costs." Break the cycle at any arrow and the whole engine stalls: an independent evaluator stops unverified output from accumulating, so comprehension never falls far enough to invite surrender; a token cap bounds the run regardless of whether anyone is watching; and reading a sample keeps the map close enough that surrender never feels rational. You do not have to win all four races. You have to refuse to lose the first one.

The economics underneath: what got cheap, what stayed scarce

Step back from the mechanics and the four costs resolve into one economic fact. A loop makes generation abundant — code, plans, fixes, and PRs all collapse toward zero cost, so a single engineer with a well-built loop can produce the output of a small team. When a resource becomes abundant its price falls, and the activities organized around it reorganize. The mechanical labor that used to fill an engineer's day — the typing, the boilerplate, the rote refactor — is exactly what the loop now does for free.

What stays scarce is judgment: the decision of which of the hundred abundant outputs to keep. A loop can generate a hundred candidate implementations; it cannot tell you which one is right, only which one looks reasonable — and the gap between "looks reasonable" and "is right" is exactly where engineering lives. As generation approaches free, the entire value of the engineer concentrates into that gap. Read the four costs in this light and each is simply a way of spending the scarce thing badly: verification debt is judgment never applied, comprehension rot is judgment going stale, cognitive surrender is judgment abandoned, and token blowout is judgment that failed to set a boundary in advance. The loop does not devalue the engineer; it strips away everything that was not judgment and leaves judgment as all that remains — which is why a lapse in it is now amplified instead of absorbed.

Chapter 9: Build Your First Loop Today

Stripe's pipeline is the endpoint, not the starting point. A first loop should be so small it barely looks like a system — a little thing that checks something on a timer. We will build it in five steps, each adding one move, and then read the complete annotated version where all six elements are visible at once.

Step one: run a /loop. Available after Claude Code v2.1.72, it reruns the same task on an interval. It is session-scoped, recurring tasks expire after seven days, and it runs on the local machine — turn the machine off and it stops. There are three forms:

/loop 5m check the deploy   # fixed: every 5 min
/loop check the deploy      # agent paces itself
/loop                       # runs .claude/loop.md

Step two: read CI and issues; triage first. Rerunning one line is not a loop — it has scheduling but no discovery. Give it a prompt to look at three things each morning and list what is worth handling. Scheduled plus auto-discovery is loop entry level. Crucially, the discovery logic should live in a skill, not the schedule:

# .claude/skills/morning-triage/SKILL.md
NAME: morning-triage
WHEN: invoked each morning by automation.
READ: CI failures, issues opened in 24h,
      commits merged since the last run.
JUDGE: for each item, is it worth acting on?
OUTPUT: findings + status to ./state/triage.md

Step three: add a state file. Do not leave results in the chat window — that is the Amnesiac failure waiting to happen. Write every finding, and how far it has been handled, into a markdown file (or a Linear board). The agent forgets; the repo does not. This is the loop's memory:

# ./state/triage.md (the loop's memory)
| finding         | source   | status   |
|-----------------|----------|----------|
| auth test flaky | CI #4821 | fixing   |
| null deref      | issue 92 | PR open  |
| stale dep       | commit a3| inbox    |

Step four: add an evaluator. The most critical step and the easiest to skip. Claude Code's /goal (after v2.1.139) runs until a condition is met, with a different model judging whether it holds — the maker–checker principle from Chapter 5:

/goal all tests in test/auth pass and the lint
      step is clean

Step five: add worktrees for parallelism. Use --worktree (or -w) to open an independent worktree per background agent so they do not step on each other — the cure for the Tangled failure:

# one isolated worktree per finding
claude --worktree fix/auth-test "draft the fix"
claude --worktree fix/null-deref "draft the fix"

Now the payoff: here is a minimal but complete loop that installs all six elements. It is small enough to read in one sitting and contains every organ a real loop needs, only scaled down. Read it top to bottom — each numbered comment is one element of the checklist, realized in two or three lines.

# 1. SCHEDULING -- a real trigger
#    (.github/workflows/triage.yml)
on:
  schedule:
    - cron: '0 6 * * *'   # 06:00 daily, cloud

# 2. DISCOVERY -- a skill, not a wall of text
#    invoked by the workflow:
run: claude --skill morning-triage

# 3. PERSISTENCE -- state on disk
#    the skill writes ./state/triage.md
#    and commits it back to the repo

# 4. HANDOFF -- one worktree per finding
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 -- a fresh model judges
#    /goal's stop check runs after each turn;
#    a second reviewer agent picks holes

# 6. HUMAN REVIEW -- the open door
#    PRs are opened, never auto-merged;
#    anything uncertain lands in ./inbox/

The cron line is scheduling; the skill invocation is discovery; the committed state file is persistence; the per-finding worktree is handoff; the /goal stop check plus reviewer is verification; and the never-auto-merge rule with an inbox is the human review point. A loop with all six, even a tiny one, is a real loop. A loop missing any of them is one of the five failures of Chapter 6 wearing a disguise. Table VI is the checklist to run against any loop you build.

Step two leaned on a skill for discovery, but the compact version above only sketched it. Here is the fuller annotated morning-triage skill referenced throughout the playbook — the real file, with each section labelled to show which of the five moves it serves. Read it as the discovery brain that the workflow above invokes in one line:

# .claude/skills/morning-triage/SKILL.md
---
name: morning-triage
trigger: invoked by daily automation
---

## Read   (the DISCOVERY inputs)
- CI runs failed since the last run
- issues opened in the last 24 hours
- commits merged since yesterday
- the previous ./state/triage.md

## Judge  (the part that sets the ceiling)
for each candidate, decide:
  - is it actionable now, or noise?
  - does it block a release? → priority
  - is it already tracked?   → skip
Keep only what is worth a worktree today.

## Write  (the PERSISTENCE output)
Append to ./state/triage.md:
  | finding | source | priority | status |
Commit the file so tomorrow can read it.

## Hand off  (prepare the HANDOFF)
for each kept finding, emit a task line:
  worktree=fix/<slug> goal=<stop-condition>

## Stop   (the boundary you keep for yourself)
Never merge. Never delete.
Anything you are less than confident about
goes to ./inbox/ for a human, not into a PR.

Five of the skill's six headings map cleanly onto the five moves: Read is discovery, Judge is the verification ceiling, Write is persistence, Hand off is handoff, and the scheduling that fires the whole thing lives in the workflow above. The sixth heading, Stop, is the one the loop cannot infer — it is the single place where the builder writes in, as permanent code, the boundary the loop must never cross: never merge, never delete, and anything below confidence goes to ./inbox/ for a human. This is the same idea the six-element loop carried only as a comment (# 6. HUMAN REVIEW), now made explicit and load-bearing. The loop will faithfully do everything the skill says; Stop is where you decide, once and durably, where to keep control.

Table VI — The First-Loop Checklist.

Chapter 10: Stay the Engineer, Not Just the One Who Presses Go

The same loop, built by two different people, can end in opposite places — and the difference is not in the loop. As Osmani writes, two people can build the same loop and get opposite outcomes. One uses a loop to move faster on things already mastered: they read the code, hold a firm sense of direction, and the loop scales judgment they already had. Another uses the same loop so they never have to understand again. Six months later, one has gotten stronger and the other has become the gatekeeper of a machine they cannot read.

A loop is not a tool whose quality is fixed by the tool. It is so strong that it amplifies, unchanged, whatever you bring: bring understanding and it amplifies understanding; bring laziness and it amplifies laziness. It is a faithful multiplication sign, and what it multiplies is the person. Two loops built with a "free myself fast" mindset and an "I still mean to be the engineer" mindset may be ninety percent identical in code; the difference is one or two checkpoints, and those decide whether, six months out, you stand on top of the loop or are hollowed out by it.

The economics behind this. The loop makes generation extremely cheap — code, plans, PRs, fixes, almost free. A single engineer with a well-built loop can produce the output of a small team. What stays scarce is judgment: knowing which plan is right, which line should be stopped, which output runs fine but is wrong at the root. The loop can generate a hundred options but cannot truly choose — or rather, it chooses on "looks reasonable," not "actually right," and the gap between those two is exactly the reason an engineer exists. Loop engineering does not devalue judgment; it strips away everything that does not require judgment and leaves judgment as all that remains.

The amplifier cuts both ways. Because the loop amplifies judgment, a lapse in judgment is also amplified. In the old world a bad decision cost one hand-written stretch of wrong code — limited in blast radius and slow enough to catch. In the new world a bad decision is executed faithfully, in bulk, a hundred times, by a machine that will not pause to ask whether it is right. The loop removes the slow gear that used to bail engineers out. You can no longer count on the process being slow enough to notice a mistake mid-flight, because the process has no slow gear left. That is why staying the engineer is not optional sentiment but operational necessity.

If judgment is the scarce resource, the practical question is how to spend it well. Three disciplines, drawn from the costs and cases, are worth stating as standing practice. Read a sample, always. Not everything — that would defeat the purpose — but a representative sample, every day, and force yourself to explain each sampled change. An inability to explain a change is a precise signal your mental map has fallen behind, far cheaper to discover on a quiet morning than in a production incident. Cap before you ship. Set a per-run budget, a daily budget, and a max retry count before the first unattended run, not after the first surprising bill — these are circuit breakers that convert open-ended risk into bounded risk. Keep one door open. Build at least one checkpoint where the loop pauses for a human — not because you will always intervene, but because the existence of the pause keeps you able to. The engineer who welds every door shut discovers on the day they must go in that they no longer hold the key.

Osmani's closing line is the one to carry: build the loop, but build it like someone who intends to stay the engineer, not just the one who presses go. Everything technical in this lesson serves that one posture. The evaluator, the state file, the budget cap, the open door — each is a way of keeping a human capable of saying "no" to a machine built to say "yes" at speed. A loop is the most powerful tool in this generation of software practice precisely because it is the most faithful multiplier of its builder, and a faithful multiplier is exactly as valuable, or as dangerous, as the judgment fed into it.

The Cheat Sheet — The Whole Playbook on One Screen

Glossary (Table VII)

Table VII — Terms used in this lesson.

Connections

Loop engineering sits on top of everything else in the AI Harness Engineering tier. Follow these threads: