Stop Asking: What Loop Engineering Really Is — From Prompt to Loop, the Engineer’s Next Move
Core question this article answers: What is Loop Engineering, and why does it fundamentally change how engineers work with AI?
If you’re still prompting an AI one sentence at a time, you might be missing a massive shift. Over the past two years, we’ve moved from Prompt Engineering to Context Engineering to Harness Engineering. But Loop Engineering isn’t about helping you do the work better — it’s about removing you from the work entirely.
In short: you stop prompting the agent. Instead, you design a system that prompts the agent for you. Your job is no longer “writing prompts” — it’s “writing loops that write prompts.” This is a shift in position. You used to be the engine; now you design the engine.
Part 1: Loop Engineering Is Not Just Another Buzzword — It’s a Shift in Position
Core question this section answers: Where does Loop Engineering sit in the stack, and what position does it put the engineer in?
To understand Loop Engineering, you have to see which layer it sits on. The “XX Engineering” terms from the past two years don’t replace each other — they stack:
| Layer | Manages | Core question |
|---|---|---|
| Prompt Engineering | A single prompt | What do I tell the model? |
| Context Engineering | What’s in the window | What to retrieve, summarize, clear? |
| Harness Engineering | One run’s tooling | Which tools, actions, completion criteria? |
| Loop Engineering | Scheduling above the harness | How does it keep running by itself? |
Each layer up deals with a bigger concern — from “a sentence” to “a window” to “a run” to “an entire self-running loop.”
This is Loop Engineering’s core position: it sits one floor above the harness. The harness arms a single agent run; the loop makes it run again and again on its own. You are no longer inside the loop — you are outside, building the loop.
Reflection: When I first heard the term, I thought it was just repackaged hype. But when I compared “manually triggering agents” with “designing a morning triage system that wakes up and works by itself,” I saw the difference. What you save isn’t minutes — it’s hundreds of tiny decisions you make every day.
Part 2: Five Moves of One Loop — How It Actually Turns
Core question this section answers: What happens inside a single loop iteration? (Users might ask: how does a loop work?)
The word “loop” makes you think of repetitive code. But in Loop Engineering, each iteration does something concrete. Break it down into five moves: Discovery, Handoff, Verification, Persistence, Scheduling. Miss one, and the loop either doesn’t run or runs uselessly.
Let’s walk through a real example — a triage loop that runs every morning automatically.
Move 1: Discovery
The first thing a loop does is figure out “what needs to be done this round.” In the example, an automated skill reads three things: yesterday’s CI failures, open issues, and recent commits. Together, that tells it “what happened since yesterday that’s worth handling.” Key point: the agent finds the work itself — you don’t feed it tasks.
Move 2: Handoff
Once work is found, it needs to be handed off. Here, each worth‑doing discovery gets its own isolated worktree. Why isolate? Because two agents writing the same file is the exact same headache as two engineers committing to the same lines. After handoff, one sub‑agent drafts a fix, another reviews.
Move 3: Verification
This is the most skipped — and most necessary — step. After the first agent writes code, a second agent reviews it — different instructions, sometimes a different model. Because the agent that wrote the code is way too nice grading its own homework. A loop without real verification is just an agent nodding to itself over and over.
Move 4: Persistence
Once verified, the result must live beyond the current conversation. Changes go into a PR via a connector; tickets are updated. Unresolved discoveries go to a triage inbox. There’s also a persistent state file tracking “how far we got.” The agent forgets; the repo doesn’t — memory has to live on disk, not just in the context.
Move 5: Scheduling
The first four moves complete one iteration. But what makes it a loop is scheduling. The triage loop runs automatically in the morning — nobody clicks. The state file lets unfinished work carry over to the next day, and the next iteration picks up where it left off. Automation is what makes a loop an actual loop, not just one run you did once.
| Move | What it does | In the triage loop |
|---|---|---|
| Discovery | Finds what to do this round | Skill reads CI failures / issues / commits |
| Handoff | Hands task to agent, isolated | Each discovery gets its own worktree |
| Verification | Another agent says “no” | Second sub‑agent reviews against tests |
| Persistence | Writes state outside the conversation | Opens PR + inbox + state file |
| Scheduling | Loops automatically | Morning automation runs |
Part 3: Six Components — What You Need to Build a Self‑Running Loop
Core question this section answers: What components are required to build a loop? (Users might ask: what do I need to prepare?)
Moves describe “what happens in one iteration.” Components describe “what you must have in hand to make it run.” Six components map to the five moves. Miss any, and the loop will break somewhere.
Component 1: Automations (Scheduling)
Automation is what makes the loop start by itself — attached to a schedule or trigger. Without scheduling, you have a one‑off run, not a loop. Important detail: the automation should trigger a skill (a named skill file), not a giant wall of instructions. When logic changes, update the skill — nobody updates a giant prompt pasted into a cron job.
Component 2: Worktrees (git worktree isolation)
Worktrees let you create multiple independent working directories from the same repo. Each agent works in its own worktree without interfering. The value scales with parallelism — if you only run one agent at a time, worktrees are optional. But if you want five agents fixing five bugs simultaneously, isolation is essential.
Component 3: Skills (SKILL.md for reusable knowledge)
A skill is project knowledge baked into a file that agents can reuse every iteration, without reloading context each time. Without skills, you have to re‑explain “how this project works, what the rules are, where the pitfalls lie” every run. That repeated cost is intent debt. Skills pay it down.
Component 4: Plugins & Connectors (MCP connectors)
Connectors bring the outside world to the loop — issue trackers, databases, staging APIs, Slack. The underlying protocol is MCP. A loop that can only see the filesystem is a tiny loop. Every external system you connect extends the loop’s autonomy.
Component 5: Sub‑agents (Generator and Evaluator separated)
The key use of sub‑agents is splitting “writer” and “critic” into two. One agent generates; another agent — with different instructions, sometimes a different model — critiques. Because the same agent playing both roles plays favorites. The model that writes code is way too nice grading its own homework. A skeptical second agent catches what the first talked itself into.
Component 6: Memory (Persistent state)
Memory is the loop’s state outside a single conversation — a markdown file or a Linear board. Once the agent’s context window clears, it remembers nothing. For a loop to pick up where it left off, memory must live on disk, not in context. Without it, each iteration wakes up with amnesia.
| Component | Solves |
|---|---|
| Automation | Loop starts without human trigger |
| Worktree | Parallel agents don’t collide |
| Skill | Reusable knowledge, no repeated explanations |
| Connector | Access to external systems |
| Sub‑agents | Separate generation from evaluation |
| Memory | Cross‑iteration continuity |
Part 4: Why Code‑Writing AI Can’t Grade Its Own Homework — Generator & Evaluator
Core question this section answers: How do you prevent an AI from “self‑hypnosis” and ensure loop output quality? (Users might ask: how to make AI check its own code?)
The hardest part of a loop isn’t getting the agent to run — it’s putting something inside that can say “no.” And the agent that writes code is the worst at saying “no.”
Ask an agent to evaluate code it just wrote, and it will confidently praise it — even when quality is obviously mediocre to a human. That’s not because the model isn’t smart. It’s because it’s grading its own homework. Its context is already full of “why I wrote it this way.” It sees not the result, but the self‑persuasion trail that led there.
So what works? Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work. You can’t just say “be stricter” and expect the writer to jump out of its own perspective. But you can swap in a different agent with completely different instructions, looking at the code from scratch. It didn’t participate in writing, so it has no self‑persuasion baggage.
This draws from GANs (generative adversarial networks) — one network generates, another discriminates. Applied to agents: one generator writes, one evaluator reviews, structurally separating “writing” from “judging quality.”
Better yet: reading code isn’t enough. If the evaluator only reads the code, it judges “looks right,” not “runs right.” An evaluator that can act — open a page, click a button, take a screenshot, inspect the DOM — sees behavior, not intent.
In product form, there’s already a primitive that implements this structure: /goal. Usage: give the agent a condition and let it run until the condition is satisfied. The key: after each turn, a small, fast model checks whether the condition holds. Completion is decided by a fresh model, not the one doing the work. That’s the maker‑checker principle — the working agent is the maker, the fresh model is the checker, with no self‑persuasion baggage.
Reflection: I learned this the hard way. I started with a single agent reviewing its own fixes. It “fixed” the same bug three times, each time saying “done,” and even wrote passing tests. A separate evaluator pointed out the core oversight in five minutes. A loop’s ceiling is its generator; its floor is its evaluator.
Part 5: Loops That Run While You Sleep — Three Real‑World Examples
Core question this section answers: How does Loop Engineering work in practice? (Users might ask: are there real‑world examples?)
We’ve talked about “how it should work.” Now let’s look at three examples where it actually does — from one person’s morning to a company shipping over 1,300 PRs per week.
Example 1: One Person’s Morning Triage Loop
At daybreak, an automation wakes up, reads CI and issues, opens worktrees, sub‑agents draft and review, passes to open PRs automatically, sends unsure items to an inbox, and saves a state file for the next day. The key detail: the automation triggers a skill, not a wall of instructions pasted in a schedule. One person, one machine, pre‑filtering the dirty work every morning.
Example 2: Stripe’s Minions — 1,300+ PRs Per Week
At enterprise scale, Stripe’s Minions is the case to study. Numbers: over 1,300 PRs merged per week, none written by a human. Trigger is lightweight: @mention Minion bot in Slack, or add an emoji reaction to a message, then fire‑and‑forget.
But what makes it reliable isn’t the lightweight trigger — it’s what happens before the LLM even thinks. A deterministic orchestrator gathers all context: scans links in the message, pulls Jira tickets, finds docs, uses Sourcegraph + MCP to fetch relevant code. By the time the agent starts, all needed material is already on the table. Why does this matter? Because letting the LLM gather its own context is the most uncontrollable step. Stripe takes deterministic work (finding context) out of the LLM’s hands.
Counterintuitive point: Minions isn’t built on a stronger model — it’s a fork of the open‑source tool Goose. Core argument: AI reliability comes from the quality of constraints, not the size of the model. Architecture: six layers alternating deterministic gates and LLM creative steps. After the agent writes code, a hard‑coded pipeline runs the linter — the agent can’t skip it. After lint fixes, a hard‑coded step commits the change.
One more thing: humans didn’t exit. They just moved seats. Those 1,300 PRs are still reviewed by engineers — time shifted from “writing” to “reviewing.”
Example 3: What Does “Run While You Sleep” Actually Depend On?
Local /loop and desktop cron jobs require your machine to be on. Machine off, loop stops. To run while you’re asleep and your laptop is closed, you need Cloud Routines or GitHub Actions scheduled triggers.
| Scheduling method | Prerequisite | Best for |
|---|---|---|
Local /loop |
Machine on | High frequency, needs local files |
| GitHub Actions schedule | Cloud | Daily scans, PR creation |
| Cloud Routines | Cloud | Machine off, stateless |
No single scheduler fits all. Need a loop that checks your local dev server every minute? Local /loop only. Need a loop that scans open issues at 3 AM and files PRs? That shouldn’t be on your laptop at all.
Part 6: Loops Do Your Work — But Also Incur Debt — Four Bills You Can’t Ignore
Core question this section answers: What risks and costs come with unattended loops? (Users might ask: what are the pitfalls?)
A loop that runs unattended is also a loop that makes mistakes unattended. The faster it runs, the quieter its mistakes become. Here are four bills — none of them pay themselves.
Bill 1: Verification Debt
You let the loop auto‑open PRs, auto‑change code, auto‑merge. Every step saves your time. But that saved time isn’t free — it becomes a pile of “not yet verified” outputs waiting for you to pay. The hard part of a loop is not the loop. It’s putting something inside it that can say no. A loop without real verification is just an agent nodding to itself.
Bill 2: Understanding Decay
The loop ships code you didn’t write, day after day. It runs, tests pass, PRs merge. Everything looks fine. But something decays quietly: your mental map of the project. The faster the loop ships code you didn’t write, the bigger the gap between what exists and what you actually understand. You stop reading through code — the codebase grows, but your map stays three months old. When something breaks in a corner you’ve never read, you open the file and feel like you’re looking at someone else’s project.
Bill 3: Cognitive Surrender
When the loop runs itself, it’s very tempting to stop having an opinion and just take whatever it gives back. The more reliable the loop, the easier it is to outsource judgment entirely. Reviewing each PR properly is tiring. This is a slippery slope. The loop can execute for you, but it cannot decide for you. You must at least be able to say “this is wrong.”
Bill 4: Token Runaway
An autonomous loop’s consumption is hard to predict. Usage swings wildly, depending on whether you’re token‑rich or token‑poor. The same loop one person can afford might blow up another person’s bill overnight. One bug making it spin all night — you wake up not to fixed code, but to an unfamiliar invoice. How to protect yourself? Set hard limits before launch: per‑run budget, daily budget, max retries. Stop when hit.
| Cost | Symptom | One‑line defense |
|---|---|---|
| Verification debt | Unreviewed outputs pile up, mistakes accumulate silently | Put an independent evaluator (not the same as the doer) |
| Understanding decay | Codebase grows, your mental map stalls | Regularly read loop outputs — if you can’t explain, update your map |
| Cognitive surrender | Accept whatever the loop returns, stop having opinions | Execution can be outsourced; judgment cannot |
| Token runaway | Wild usage swings, unpredictable costs | Cap budget and retries before launch |
Reflection: Of these four, “understanding decay” is the most insidious. Token runaway hurts visibly. Verification debt shows up when something breaks. But understanding decay just makes you a stranger to your own project, and you won’t even notice it happening. My habit now: pick two loop‑submitted PRs each week, don’t look at the diff, and first say out loud “what should this code do.” If I can’t, my map needs an update.
Part 7: Stay the Engineer — The Person Building the Loop Decides the Outcome
Core question this section answers: Why can the same loop produce opposite outcomes for two people? (Users might ask: I use the same tools as others — why different results?)
Two people can build the same loop and get opposite outcomes. This sounds counterintuitive — a system is neutral, same code should produce same results, right? But it’s not about the loop. It’s about the person outside the loop.
One person uses the loop to run faster on things they already understand deeply. They read the code, know the direction, and the loop just automates manual steps. The loop amplifies their existing judgment.
Another person uses the same loop to avoid understanding. Don’t get it? The loop will write it. Can’t judge? The loop will merge. They use the loop to bypass “understanding” entirely.
The loop itself doesn’t bias either way. It’s just a faithful multiplier — and what it multiplies is you.
When something can be generated infinitely (code, proposals, PRs), it stops being scarce. What’s still scarce? Judgment — knowing which approach is right, which line of code should be blocked, which output “works” but is fundamentally wrong. The loop can generate a hundred options, but it can’t choose for you. Or rather, it can — but it chooses based on “looks reasonable,” not “is actually correct.”
So Loop Engineering doesn’t devalue judgment — it does the opposite. It takes away all the work that doesn’t require judgment, leaving only judgment. Your value gets compressed and purified into that one thing. The stronger the tool, the bigger the bet on your judgment.
When you build a loop, the mindset you bring determines what it becomes. If you build it to “get yourself out of the way,” you’ll strip out all the checks because checks are friction. If you build it as someone who intends to stay the engineer, you’ll deliberately leave checkpoints where you can say no — even if that makes it slower.
Reflection: This choice isn’t made once on build day. It’s made every day. Today you read one more PR, asked “is this really right?” — you’re still on the engineer side. Today you clicked merge without thinking — you slid one step toward being just a button. No one is permanently an engineer. It’s an identity you renew daily.
Part 8: Build Your First Loop Today — Step by Step
Core question this section answers: How do you build a working loop from scratch? (Users might ask: give me concrete steps to build my first loop.)
Many people hear “Loop Engineering” and immediately picture Stripe’s 1,300‑PRs‑per‑week pipeline — then give up because it feels far away. That’s a misunderstanding. Your first loop should be so small it barely feels like a system — just a thing that looks at something for you on a schedule.
Step 1: Run /loop
/loop is available in Claude Code v2.1.72+. It does one thing: repeats the same task on a schedule. Three forms:
-
/loop 5m check the deploy— fixed 5‑minute interval -
/loop check the deploy— Claude decides (between 1 min and 1 hour) -
/loop— bare run, executes built‑in maintenance or whatever’s in.claude/loop.md
Time units: s/m/h/d. Cron interval minimum 1 minute. Two details: it’s session‑scoped, recurring tasks expire after 7 days; it runs on your local machine — shut down and it stops.
Step 2: Make It Read CI and Issues — Start With Triage
Repeating a single sentence isn’t a loop yet. Make it read something and make a judgment. The simplest starting point is a triage task. Give it a prompt to check three things every morning: yesterday’s CI failures, new issues, recent commits. After reading, pick what’s worth handling and make a list. Schedule + auto‑discovery = loop entry pass.
Step 3: Add a State File — Give It Memory
Don’t leave the triage results in the conversation window — close it and they’re gone. Create a markdown file and write each discovery and its status there. That file is the loop’s memory. With it, today’s unfinished work can be picked up tomorrow when the loop wakes again.
Step 4: Add an Evaluator — Let It Say “No”
This is the most critical step. Claude Code provides a built‑in tool called /goal (v2.1.139+) exactly for this. Example:
/goal all tests in test/auth pass and the lint step is clean
The condition is checked by a fresh model, not the agent that did the work. Why a different model? Because the worker is too nice to its own output.
Step 5: Add Worktrees — Let It Parallelize
Use git worktrees. Claude Code’s --worktree (or -w) gives each background agent its own independent worktree, so they don’t step on each other. Two agents writing the same file is the same headache as two engineers committing to the same lines. Isolate them, then they can run in parallel without fighting.
Tool Snapshot (June 2026)
| Capability | Claude Code | Codex |
|---|---|---|
| Scheduled runs | /loop (background worker) |
Automations tab (daily/weekly + custom cron) |
| Run until condition met | /goal |
— (automation + check loop) |
| Parallel isolation | --worktree / -w |
Dedicated background worktree, results to Triage inbox |
| Sub‑agents | Subagents / Agent Teams (.claude/agents/) |
.codex/agents/ TOML definitions |
| External connections | MCP + Plugins (one‑click install) | MCP connector explicit call |
| Skills | Skills (SKILL.md) | $skill-name |
| Run while machine off | Cloud Routines (cloud) | Cloud (planned Codex Jobs) |
First Loop Checklist
| Element | Ask yourself |
|---|---|
| Discovery source | What does it read on schedule? (CI / issues / commits / inbox) |
| State file | Which disk file holds cross‑iteration memory? |
| Evaluator | Is there an independent check that can say “no”? |
| Isolation | Do parallel agents each have their own worktree? |
| Token caps | Have you set spending limits? Who stops it if it runs wild? |
| Human checkpoint | Which step pauses for you to look, instead of auto‑completing? |
The first two determine whether your loop can run. The last four determine whether it runs without causing trouble. For your first loop, make it small — but make sure it has that “say no” check and a human checkpoint.
Practical Summary / Action Checklist
-
Know your position — you’re not inside the loop, you’re outside building it. -
Five moves — Discovery → Handoff → Verification → Persistence → Scheduling. None optional. -
Six components — Automation, Worktree, Skill, Connector, Sub‑agents, Memory. -
Evaluator must be independent — the code‑writing agent cannot grade itself. -
Start small with triage — a scheduled loop that reads CI and issues beats a grand design. -
Pay the four bills — verification debt, understanding decay, cognitive surrender, token runaway. -
Engineer’s bottom line — the loop can execute for you, but it cannot decide for you.
One‑Page Summary
| Core question | Answer |
|---|---|
| What is Loop Engineering? | Designing a system that prompts agents for you — replacing yourself as the prompter |
| How does it relate to Prompt Engineering? | It sits four layers above: Prompt → Context → Harness → Loop |
| What happens in one loop iteration? | Discovery → Handoff → Verification → Persistence → Scheduling |
| Most important component? | Independent evaluator — without it, the loop just nods to itself |
| Real‑world scale? | Stripe: 1,300+ PRs per week, none human‑written |
| Biggest risk? | Unattended loop makes unattended mistakes — four kinds of debt |
| How to start? | /loop 5m "check CI" + state file + /goal + worktrees |
FAQ (Frequently Asked Questions)
Q1: Is Loop Engineering the same as Prompt Engineering?
No. Prompt Engineering focuses on “how to write one prompt.” Loop Engineering focuses on “how to make it run itself again and again.” You move from writing prompts to building loops.
Q2: Can I run a loop on just my laptop?
Yes. The local /loop command works, but it stops when your laptop shuts down. To run while you’re asleep and the machine is off, you need Cloud Routines or GitHub Actions scheduled triggers.
Q3: How do I prevent a loop from burning tokens uncontrollably?
Set hard caps before launch: per‑run budget, daily budget, max retries. Those are safety lines.
Q4: Do I have to use two different models for generator and evaluator?
Not strictly, but it’s recommended. Even with different instructions, the same model often shares blind spots. A different foundation model brings a different set of blind spots — and that diversity is valuable for evaluation.
Q5: Do I still need to review code that a loop writes?
Yes. Stripe still has engineers review all 1,300+ weekly PRs. Humans haven’t left — they moved from “writing” to “reviewing.”
Q6: How big should my first loop be?
As small as possible. Start with /loop 5m "check CI failures", add a state file, add a /goal condition. Get it running, then add components gradually.
Q7: How do I avoid understanding decay?
Pick two loop‑submitted PRs each week. Before looking at the diff, say out loud “what should this code do.” If you can’t, your mental map needs an update.
Q8: Will Loop Engineering make me obsolete?
No. It frees you from repetitive work, then compresses your remaining value into one thing: judgment. And judgment is exactly what you’ll need to compete on.
