For two years, getting something out of a coding agent meant a manual cycle. You wrote a prompt, handed over the context, read what came back, and wrote the next prompt. The agent was a tool and you held it the entire time. That era is ending, and not because the agents learned to need you less. The leverage point moved. It used to sit at the prompt: better wording, better context, a better one-shot answer. Now it sits one floor up, in the system that decides what the agent works on, when, against what test, and what it remembers between runs.

That system has a name. It is a loop. The pattern that began as a coder’s trick is spilling out of engineering into ordinary knowledge work, because the newer models are good enough to run it for people who have never opened a terminal. This Scroll is the working map: what a loop is, how to tell whether you actually need one, the parts you build it from, and the discipline that decides whether it helps you or quietly bleeds you. That last part is older than software, and it is the part most guides skip.

This Is Already Real

It is worth seeing the scale before the method, because the numbers are not subtle. GitHub counted roughly one billion commits last year. This year the figure is expected to clear fourteen billion, as people and their agents ship code together. That number comes from GitHub’s chief operating officer Kyle Daigle, and his sharpest point underneath it is that the tools changed to manage the surge while the decision of what to actually merge stayed with humans. Anthropic’s own engineers now merge around eight times as much code per day as they did in 2024. Anthropic calls that figure almost certainly an overstatement of the true productivity gain, and the honest caveat is the right instinct, but the mechanism is not in dispute: the leverage moved from typing prompts to designing the loop that prompts.

The ceiling is high and a little vertiginous. One practitioner had a loop rewrite an entire codebase from one programming language to another in about six days, work that would have taken close to a year by hand. Another builder asked a model to build an NBA front-office simulator overnight, then went to sleep. By morning he had a working game. What struck him was the self-direction: the model would reach a stopping point, decide what was still missing, write itself a fresh one-paragraph prompt, and keep going, with no hand-holding between steps. That is the upside the demos sell. The cost and the failure modes, which the demos skip, are the rest of this Scroll.

What a Loop Actually Is

Strip away the tools and a loop is simple. An agent does a slice of the work, checks the result against a goal or a standard, folds in what it learned, and writes its own next step. It repeats until the task is done or the output stops improving. That definition holds whether the output is a pull request or a spreadsheet, which is exactly why the technique is escaping the engineering team.

Three of those five stages do the real work, and they are worth naming on their own.

Verify is the heart. Without a real check on the result, you do not have a loop. You have an agent agreeing with itself on repeat. The gate is the thing that turns repetition into progress. This is the whole game, and we will come back to it twice more before the end.

State is the memory. Each pass has to remember what it already tried, or it repeats the same mistake forever. A small record kept outside the conversation means tomorrow’s run resumes instead of starting from zero.

A stop condition is the sanity. Every serious loop has two exits: success, and a hard limit like “after eight tries, stop and report.” Without one, it runs until it succeeds, breaks, or drains your budget.

This is the practice of agentic coding grown up. We can give it its own name, loop engineering: the work of building the small system that finds the task, hands it to the agent, checks the result, records what happened, and decides the next move on its own. You design that system once. From then on, it prompts the agent for you.

The Test Before You Build

Here is the honest part that most quick threads skip. Most people do not need a loop yet. A loop spreads its setup cost across many runs, so it earns its keep only under four conditions. Miss one and the loop costs more than it returns.

Run the test on a real task. Tick only what is genuinely true.

The economics are not universal, which is why smart people disagree so loudly about whether loops are obvious or reckless. They are usually describing different wallets. To the team with effectively unmetered tokens and a strong test suite, a loop is free leverage. To the solo builder on a consumer plan, the token bill arrives before the productivity gain does. Both are right about their own situation. The cost of a loop is real and it compounds: every pass re-reads the whole context, and that pile grows each time, so ten iterations is not ten prompts but ten prompts that each keep getting bigger. Splitting the work between a maker and a checker, which lifts quality, also doubles that bill.

So before any building, sort the work honestly.

The line that should stay with you: a loop only makes sense where the bottleneck is repetition, not judgment. The moment the hard part is deciding what good looks like, a single well-aimed prompt with you in the room still wins.

The Building Blocks

If a task passes the test, every loop that works is assembled from the same handful of parts. None of them is exotic. The craft is choosing the smallest version of each.

A few of these reward a closer look.

The automation is the heartbeat, and the controls matter. In Claude Code, /loop re-runs on a cadence, while /goal keeps going until a condition you wrote is actually true, with a separate small model checking completion so the agent that wrote the code is not the one declaring it done. Routines run in the cloud with your laptop closed; scheduled tasks survive a restart. Codex exposes the same shape through its Automations tab: pick a project, set a prompt, set a cadence, and runs that find nothing archive themselves. The two controls worth learning first are the cadence (run regularly regardless of state) and the goal (run until verified), because the difference between them is the difference between a loop that checks and a loop that finishes.

Worktrees are how you run more than one agent without a pileup. The second you have two agents writing the same file, you have two engineers editing the same lines without talking. A git worktree is a separate working directory on its own branch that shares the same repo history, so one agent’s edits literally cannot touch the other’s checkout. Claude Code exposes this directly, including an isolation setting that gives each helper agent a fresh checkout that cleans itself up afterward. The catch is honest: worktrees remove the mechanical collision, but your own review bandwidth, not the tool, decides how many parallel agents you can actually run. You are still the ceiling.

The checker is the move people skip and the one that matters most. Splitting the agent that writes from the agent that checks is the single most useful structural decision in a loop. The model that wrote the code, in one practitioner’s words, is way too nice grading its own homework. A second agent with different instructions, sometimes a different model, catches what the first one talked itself into. This is not a 2026 invention with a viral name. It is the evaluator-optimizer pattern Anthropic documented eighteen months earlier: one generates, another critiques, repeat.

The skill is where your project’s hard-won context lives so the loop reads it every run instead of re-deriving it. It is a folder with a SKILL.md inside, plus optional scripts and references. A small one for triaging failed builds reads like this:

name: ci-triage
description: Classify CI failures by root cause, draft fixes for the easy ones,
  and escalate the rest. Trigger on a failed workflow run or the morning loop.
---
# CI triage
## Classify
- env:   missing secret or variable        -> escalate to a human
- flake: passes on retry, no code change   -> retry once, then file it
- bug:   deterministic, tied to a commit   -> draft the smallest fix
## Never
- disable a failing test (file it as an escalation instead)
- touch src/payments or src/billing without a human
## State
- after each run, update STATE.md: files checked, classifications, PRs, escalations

Connectors, built on the Model Context Protocol, are what let the loop act inside your real tools rather than only narrate what it would do. In rough order of payback: GitHub first (read repos, open pull requests, react to events), then your issue tracker (link work back to tickets, close them when verification passes), then the team channel (post results, ping a human on an escalation), then your error tracker (investigate live alerts, draft fixes for the frequent ones). A connector you wrote for one tool usually works in the other, because the major agents all speak the same protocol.

The State File

This is the piece that sounds too dumb to matter and is the actual spine of every working loop. A markdown file, a board, a small database: anything that lives outside the single conversation and holds what is done and what is next. Agents have short memory by default. What they learn this session is gone tomorrow unless you write it down. A loop without state restarts every run; a loop with state resumes. It is the cure for drift, the slow slide off the goal as each summary step quietly loses a little of the original intent.

A useful state file is not elaborate. It is a log the next run can read:

# Loop state - ci-triage
## Last run
2026-06-09 03:30 UTC - 7 failures classified, 3 fixes drafted, 4 escalated
## In progress
- fix-auth-token-refresh : tests passing locally, awaiting CI
## Lessons (write here, not in chat)
- 2026-06-08: this runner needs bash, not PowerShell (a TLS issue)
## Stop conditions met
- goal "all auth tests pass + lint clean" hit on commit 3a7b8c1

For long-running loops that risk wandering, pair the state file with a standing one-page spec, a vision or charter the agent rereads each run. State tells the agent where it is. The spec tells it where to go.

The Light Version, By Hand

Now the part that matters most for an operator who does not write code. You do not need a coding agent to feel how a loop works. You can run one by hand in any chat window, right now, with nothing but a prompt. The trick is to hand the model all three loop parts at once: a goal, strict success criteria, and a protocol that forces it to check itself before it is allowed to stop.

Paste that in, fill the brackets, and watch what happens. The model drafts, grades its own work against your criteria, names the weakest point, and rewrites, over and over, until it actually clears the bar instead of handing you the first thing that looked close. That is a loop. You just built one with a paragraph.

Notice what it cannot do, because the gap is the whole reason the heavy version exists. You are the trigger. You opened the chat, you pasted the prompt, you are watching it iterate. Close the tab and it is gone. There is no schedule, no waking up when an email arrives. To get a loop that runs on its own, you either step up to the engineered version, or you use a consumer assistant that supports plain-language scheduled tasks. Those everyday loops are worth running in your own week, and they read like sentences:

• “Every weekday at 7am, scan my inbox and calendar and send me a 120-word brief: my top three meetings, anything urgent, and one follow-up I owe but have not sent.”
• “An hour before each meeting, remind me with the context and the decisions from our last conversation with that person.”
• “Every evening at seven, ask if I trained today, keep a streak, and do not let me quietly skip more than one day.”

Each is a loop. It just runs on a clock instead of a test suite. The honest takeaway from every serious practitioner is the same: start with what is already in front of you, and reach for the heavy machinery only when the light version genuinely is not enough.

Build the Smallest Loop That Works

If you passed the test, build the smallest loop before anything fancy. Four parts: one automation, one skill, one state file, one gate. The order is not optional. Get one manual run reliable. Turn it into a skill. Wrap it in a loop. Then schedule it. Skipping ahead is how loops fail in production, because each layer assumes the one beneath it already works.

Write the loop down before you run it. A loop’s contract fits on five lines:

GOAL:      every test in /tests/auth passes, lint is clean, no type errors.
EACH PASS: read every failure, fix the single highest-impact one, re-run the checks.
VERIFY:    green tests + zero lint warnings + zero type errors.
STOP WHEN: verify passes, OR 8 passes reached.
ON STOP:   summarize what changed and what still fails.

Track one number and ignore the rest: cost per accepted change. Not tokens spent, not tasks attempted, not loops scheduled. If fewer than half the changes a loop produces survive your review, you are doing the very work the loop was meant to remove, and the loop is losing.

The Ways Loops Die

The most common death is the quiet one. An engineer named Geoffrey Huntley documented it and called it the Ralph Wiggum loop: an agent meant to signal completion only when finished signals it early, the loop exits on a half-done job, and because nothing objective ever failed the work, it keeps spending. The fix is the gate. Something that returns a real pass or fail: a test, a build that compiles or does not, a linter that returns zero or non-zero. Not a second agent that merely has an opinion, because two optimists agreeing is not verification.

The other failure modes are worth knowing by name so you can spot them early. Here are the ones that turn a loop into a money pit:

That last one is the deepest, and it sharpens as the loop gets better rather than worse. The faster a loop ships work you did not write, the wider the gap between what your project contains and what you understand. The bill that hurts is not the token bill. It is the day you have to debug a system no one on the team has read. Its cousin is cognitive surrender, the pull to stop forming an opinion and accept whatever the loop returns. Designing a loop is the cure for that when you do it with judgment, and the accelerant when you do it to avoid thinking. Same action, opposite result. And remember that a loop running unattended is also an attack surface running unattended: a gate with no security check merges insecure code on a schedule, so the loops you let run alone are exactly the ones that need the strictest gates.

The Operator’s Application

Carry this into the week, not into a weekend build.

Do not build a loop on Monday. Take three tasks you did this week that recur, and run the four-condition test on each, out loud. Most will fail a condition, and that finding is the win. You just saved yourself from building a system that would have cost more than it returned.

Start with the light version. If you are not an engineer, the self-check prompt in a chat window and the plain-language scheduled task are the entire toolkit you need for now. Reach for the heavy machinery only when those genuinely are not enough. Most weeks, they are enough.

Name the gate first. Anywhere you do build a loop, write down the thing that can fail the work before you write anything else. If you cannot name it, you do not have a loop. You have an agent grading its own homework, and the grade is always an A.

Keep reading what it ships. Read the diffs. Spot-check that the gate actually catches the failure you care about, because gates rot. The discipline is cheap now and ruinously expensive to recover later.

Wisdom Speaks

“The unexamined life is not worth living.” — Socrates, in Plato’s Apology, 38a

Socrates never wrote a book of answers. His whole method was a loop of a kind: take a claim, cross-examine it, and keep testing until it either survived or broke. The Greeks had a word for that cross-examination, elenchus, and it names exactly what a verify step is. The point was never to be clever. It was that a belief no one ever tested is not really knowledge; it is just a thing you happened to say. An unexamined output is the same. The agent that grades its own work and the man who never questions his own life make the identical mistake: they confuse confidence for truth.

Scripture sharpens it into an instruction. “Prove all things; hold fast that which is good” (1 Thessalonians 5:21, KJV). The Greek there is dokimazo, to test something the way you would assay a coin to see whether the gold is real. Notice the two halves. Test everything, and then keep what passes. That is a verify step and a stop condition in a single verse. The gate is not cynicism; it is the precondition of holding fast to anything at all. You cannot hold to what is good until you have proven which part of the pile is good.

This is why the closing instruction is two commands and not one. Build the loop, and stay the engineer. The loop is a tool for keeping, not for surrender. The danger was never that the work got easier. It is that the leverage point moved up a floor, and you can answer that by climbing up to design with judgment, or by climbing out and handing the judgment over too. Scripture’s call to prove all things is a call to stay present, to keep an opinion, to remain the one who decides what is good. Design the loop and you are more of an engineer than you were, not less. Stop reading what it ships and you have automated your own absence.

Go Deeper

The sources behind this Scroll, if you want the long version. The big-picture reporting on loops moving past engineering is Every’s Context Window, by Laura Entis and Katie Parrott. The engineer’s discipline draws on Addy Osmani’s writing on loop engineering and a fourteen-step practitioner playbook by Lev Deviatkin. The continuous brainstorm-plan-build-review-improve cycle has an open-source home in the compound-engineering workflow associated with Every’s Kieran Klaassen. And the fourteen-billion-commit figure comes from GitHub’s Kyle Daigle in conversation on Every’s AI & I podcast. Read the reporting for the why, then come back and build the smallest loop that works.

What You’ll Carry Away

Three things to take into your next AI conversation.

First, ask whether the task even wants a loop. The four-condition test is the whole strategy in one move: repetition, an automated gate, a budget that can absorb waste, and an agent with real tools. Miss one and a single good prompt still wins.

Second, if it passes, build the smallest version. One automation, one skill, one state file, one gate, in that order, with a worktree and a separate checker once you run more than one agent at a time. Cost per accepted change is the only score that counts.

Third, keep your hand on the gate and your eyes on the diffs. The loop can carry the typing. It cannot carry the judgment, and the day you ask it to is the day comprehension debt comes due.

So take one task you did this week that you will do again next week, and run the test on it out loud. If it passes all four, write its contract in five lines: the goal, what each pass does, the gate that can fail it, the hard stop, and what it reports back. If it fails even one condition, write the single sentence that says why it stays a manual prompt. The entire discipline is being able to tell those two apart. The leverage moved. Your job did too, and it is a better job: not the one who types, but the one who decides what is worth keeping.