Stop Prompting Your Agent, Start Designing the Loop — An Introduction to Loop Engineering

The way we use AI coding agents has changed fundamentally over the past year.

Until recently, the job looked like this: write a good prompt, read what comes back, write the next one. The agent was a tool, and you held it in your hand the whole time.

A different idea is now taking hold, and it flips that premise. It’s called Loop Engineering. In one line:

Replace yourself — the person prompting the agent — with a system you design.

Google’s Addy Osmani helped give the term its current shape in June 2026, and it spread quickly from there. A "loop" here means an iterative process around a goal: you define the objective once, and the AI keeps working until the stop condition is met. Your role moves from the person who keeps typing prompts to the engineer who designs the system.

Introduction — Where This Article Fits

A quick word on where this piece sits.

Most of what I’ve written before has been on narrower topics: enterprise-oriented design theory, autonomous loops built around an evaluator, and so on. Here I’m deliberately pulling back to the foundation underneath all of it — what Loop Engineering actually is — and laying it out cleanly. If you’ve read my other articles, you already know I’ve spent the past several months running this loop theory inside my own development setup. The main lesson I’ve taken from that experience is that Loop Engineering isn’t just a convenient automation trick. It changes how you work with AI coding agents at a basic level.

Most of what follows pulls together ideas already discussed by frontline practitioners and official documentation, reorganized from English-language primary sources. Read it as a consolidation rather than a new discovery.

I won’t stop at organizing, though. Once you’ve seen the whole picture, one question tends to remain: I get the theory — but how do you actually build one? This article is meant to carry you through to that. The first half builds the theory; the end shows a concrete implementation you can try right away. I’d like the two halves to read as one continuous thread.

This article is organized as follows:

• 1. The path that led here (prompt → context → harness → loop)
• 2. What Loop Engineering actually lets you do
• 3. The theory underneath
• 4. From theory to implementation — loop-kit

How We Got Here — The Four Layers That Led to Loop Engineering

Loop Engineering didn’t appear overnight. Over the past few years, the center of engineering effort has shifted steadily outward, from the model itself to everything around it, and Loop Engineering is where that trend has landed. Let’s take the layers in order. Each one wraps the layer before it rather than replacing it.

1. Prompt Engineering (through roughly 2024)

This layer is about how you ask. For the two years or so after ChatGPT arrived, results came down to how you wrote a single instruction: giving the model a role, showing it examples, walking it through the reasoning step by step (chain-of-thought).

Its limits were clear, too. A single instruction can’t decide what to do next, or what counts as done.

2. Context Engineering (from mid-2025)

The question moved from how you ask to what you show. Andrej Karpathy and Shopify’s Tobi Lütke made the case around June 2025 that this was the real skill, and Anthropic laid out the concept in September in its article "Effective context engineering for AI agents."

Anthropic’s definition, in plain terms: shape the whole set of tokens you hand the model — the context window — so the behavior you want is more likely to come out. System instructions, retrieved documents, available tools, past exchanges, memory and state — how you assemble those into the window often matters more than the model’s exact wording. For agents that run over many turns, this became essential.

3. Harness Engineering (from early 2026)

This layer is about building out the environment the agent runs in. It took hold in early 2026, after Thoughtworks’ Birgitta Böckeler framed it on martinfowler.com as "Agent = Model + Harness," and Addy Osmani wrote it up as "Agent Harness Engineering."

A harness is the model plus everything you build around it: prompts, tools, hooks, sandboxes, subagents, feedback paths, recovery mechanisms. As Osmani points out, Claude Code, Cursor, Codex, Aider, and Cline are all, underneath, harnesses. Give two of them the same model and what separates the experiences is the harness.

The central claim of this layer is that a decent model with a strong harness will usually beat a strong model with a weak one. Alongside it runs a second idea: once you tighten part of the system, you keep it that way. When the agent makes a mistake, rather than shrugging it off as a one-off, you treat it as a cue to tighten the system so the mistake is less likely to recur — write the convention into AGENTS.md, add a hook that blocks the dangerous command, have a review subagent watch for it. The harness gets stronger with each failure.

A harness, though, mostly governs the inside of a single run — one session. Running several subagents in parallel within that run is common; Claude Code does it routinely. What a harness doesn’t cover is the space between runs, and that’s what the next layer designs: the loop.

4. Loop Engineering (from June 2026)

One layer up from the harness sits Loop Engineering. Addy Osmani introduced the term on June 7, 2026, drawing together two practitioners who had been making the same point:

• Peter Steinberger (founder of PSPDFKit; creator of the open-source agent "OpenClaw," which drew hundreds of thousands of stars almost overnight; now at OpenAI) — stop prompting the agent, and design the loop that prompts it instead.
• Boris Cherny (head of Claude Code at Anthropic) — I don’t prompt Claude directly anymore. I run a loop that prompts Claude and decides what comes next. My job is to write the loop.

A harness builds out the inside of a single run; a loop designs the space between runs. It starts on a schedule, spins up subagents when it needs them, decides its own next move, and keeps itself going. It finds work, hands it out, checks it, records what’s done, and picks what’s next — a small system that runs that cycle for you, so you’re no longer the one prompting turn by turn.

One thing worth noticing: this is no longer about showing off homemade tooling. A year ago you’d have written a pile of bash scripts yourself and maintained them forever. Today the same pieces ship as standard features inside products like Claude Code and Codex. So the real question is less which tool and more how you design a loop that works on any of them.

The progression, in short:

One caveat is worth keeping in mind. Feed a loop sloppy prompts and you get sloppy work, just produced faster. A loop adds the machinery to run the whole thing on its own; it doesn’t raise the quality of the layers beneath it.

What You Can Actually Do with Loop Engineering

Before the theory, the practical payoff — the examples Addy Osmani gives make it concrete.

The morning triage loop. It wakes up on its own each morning and reads yesterday’s CI failures, the open issues, and recent commits. It writes what it finds to a Markdown file (or a Linear board). For anything worth acting on, it spins up an isolated workspace — a git worktree — has one subagent write the fix, and has a second subagent check that draft against the project’s skills and existing tests. Through connectors it opens a PR and updates the ticket. Whatever it can’t handle goes into a triage inbox for a human. A state file lets it remember how far it got today, so tomorrow morning it resumes from there. That’s a full engineering workflow, start to finish, and the person who designed it set it up once. Nobody is prompting the individual steps.

Variations on the same idea are already in use:

• PR babysitter: watches your PRs, answers review comments, and fixes failing CI.
• Dependency sweeping: dependency updates and CVE (vulnerability) fixes, with major changes still routed through human approval.
• Issue triage, changelog drafts, post-merge cleanup.
• Routine summaries: a daily digest of a given Slack channel, for instance.

Osmani writes that OpenAI runs this kind of thing internally for the boring-but-necessary chores: triaging daily issues, summarizing CI failures, condensing commits, and hunting down bugs that slipped in the week before.

For a team, it pays off in a couple more ways:

• Less key-person dependency: capture each person’s tacit "here’s how we fix things in this repo" as skills (below), so any loop runs at a consistent quality.
• Ties into existing tools: connect to Linear, Jira, or Slack and move tickets from inside a closed loop.

Everything so far runs on a schedule. There’s a second use with a different character: handing a loop a one-off but genuinely complex implementation.

Say you want to build a whole feature, but the requirements are still fuzzy and you haven’t worked out the details yourself. Here the loop earns its keep. First you have it work through the requirements: surface what’s undecided and where a judgment call is needed, check those with you, and settle them into a spec. With the spec pinned, it writes tests against it, implements, and keeps iterating until every test passes. Once you’ve handed over the requirements and signed off at the start, you can step away until it’s finished. It doesn’t run every morning, and it doesn’t run unattended forever, but it still cycles until a stop condition is met — so it’s a loop all the same.

The through-line: loops are good at work with a clear finish line that a machine can check. Routine work that recurs every morning gets cleared while you sleep; a one-off complex build gets pushed to green while you’re focused elsewhere.

Understanding the Machinery — The Theory of Loops

Now for the theory behind why this works. Once this lands, the difference between a good loop and a risky one comes into focus.

What a loop is

Anthropic’s official definition (from the Claude Code team) is the cleanest: a loop is an agent that repeats a cycle of work until a stop condition is met.

Put plainly, a loop is a task with a check — a verification step — attached. A task with no check is just a wish. Everything rests on that: do something, confirm the result, decide whether to keep going or stop. Most of the real work is in making that check trustworthy and deciding when to stop.

The four loop types Anthropic lays out

Anthropic’s docs sort loops into four kinds by how they start and how they stop. For a newcomer the taxonomy is clarifying, so here it is as-is. The examples use Claude Code feature names, but the ideas carry across tools.

1. Turn-based: your prompt starts it; it stops when Claude decides it’s done or that it needs more information. Every ordinary back-and-forth is this — the most basic loop there is.

2. Goal-based (/goal): you define what "done" means. After each turn, a small evaluator model — separate from the working agent, and Haiku by default — checks whether the criteria are met and sends the agent back to work until they are, or until the attempt limit you set. One detail is worth getting right: as of the current spec (July 2026, Claude Code v2.1.139 and later), that evaluator doesn’t run commands or read files on its own. It judges only from what’s already in the conversation transcript. So your criteria have to be things Claude’s own output can demonstrate. "All tests pass" works because Claude actually runs the tests and the result lands in the conversation. The criteria that work best are the ones whose evidence shows up in the transcript in a form a machine can check.

3. Time-based (/loop, /schedule): runs on an interval. Good for recurring routine work, or for reacting to changes in an external system like a PR or CI.

4. Proactive: fires on an event or a schedule, with no human in real time. Each task ends when its goal is met; the routine itself runs until you shut it off.

If a task is simple, skip the complex loop. Anthropic’s own advice is to start with the simplest approach and move up a type only when you need to.

The parts that make up a loop: five, plus memory

Addy Osmani lists the tool-independent building blocks of a loop as five parts, with memory kept separately as its own thing. (Claude Code and Codex now both ship all five.)

• 1. Automations: kick off on a schedule and do discovery and triage themselves — the thing that wakes the loop at each interval.
• 2. Worktrees: isolation so parallel agents don’t overwrite each other’s files. A separate git working directory where one agent’s edits can’t reach another’s.
• 3. Skills: project knowledge the agent would otherwise guess at, written down externally (for example, SKILL.md). Instead of pasting a long instruction each time, you call it by name.
• 4. Plugins and connectors: wire the agent into the tools you already use — updating tickets, opening PRs, posting to Slack (over MCP).
• 5. Sub-agents: one proposes, another checks (the key principle, below).

What Osmani calls the sixth piece is state, or memory: a Markdown file, a Linear board, anything that outlives a single conversation and holds "what’s done, what’s next." The model forgets everything between runs, so memory belongs on disk — in files and git history — not in the prompt. The agent forgets; the repository doesn’t. That’s the piece long-running loops lean on.

A note: this "fresh context every time, memory written to files" pattern owes a lot to what Geoffrey Huntley popularized in early 2026 as the "Ralph technique." You run the agent inside a plain while loop, advancing one step per pass, each time with a fresh context and a written spec as the reference point.

The most important principle — separate the maker from the grader

This is the core of loop theory: the model that wrote the code is too easy on itself to grade its own homework.

A model that generates code tends to rationalize or affirm what it just wrote. A reviewer working from different instructions — sometimes a different model — can catch the spots where the first model talked its way past a problem. So you split the roles: one agent writes the code, a different one checks it (maker–checker, or generator–evaluator, separation).

Claude Code’s /goal is one form of this: it hands the "is it OK to stop?" call to a model separate from the working agent. But as noted, that evaluator only reads what’s in the conversation; it doesn’t re-run the tests. So you get independence of judgment but not independence of verification. If the working agent writes "tests passed" into the conversation, the evaluator takes that as given. Pushing one step further — having the checker run the verification commands itself — is exactly what loop-kit aims at, later in this piece.

The order of evaluation matters, too: the mechanical, trustworthy check comes first. Run the tests and see if they go green; then AI review; then the human, last, looking only at the evidence. Verification quality is what most shapes how good the loop turns out.

Designing stopping rules — "finished" and "succeeded" aren’t the same

Designing against runaways is part of the theory. The classic trap is mixing up the stop condition with the success condition. A triage loop can end cleanly, without errors, and still turn out to have fixed nothing. That happens more than you’d think. "The loop stopped" doesn’t mean "the loop succeeded," so the stopping rule has to grade the output, not just ask whether it finished.

In practice you set explicit hard brakes:

• An iteration cap (stop after five tries, say).
• A budget or token cap, to keep it from burning indefinitely.
• Stagnation detection — is it hitting the same failure over and over, is there any diff at all?
• Human gates: anything irreversible, or anything that would change the requirements themselves, stops for a human.

What a Loop Won’t Take Off Your Plate — Three Problems That Get Sharper as It Improves

Loops are powerful, and Osmani spends just as much energy on the dangers. His point is that three problems don’t ease up as the loop gets better — they get sharper.

• Verification stays on you. A loop that runs unattended also makes mistakes unattended. "Done" is a claim, not a proof. Your job is to ship code you’ve confirmed works, and Osmani keeps coming back to it.
• Comprehension debt. The faster the loop ships code you didn’t write, the wider the gap between what actually exists and what you understand. A smooth-running loop, left alone, widens it faster. Which means you have to read.
• Cognitive surrender. When a loop just runs on its own, it’s tempting to stop forming opinions and take whatever comes back at face value. Designing a loop can cut either way: done with judgment it sharpens you, done to dodge thinking it dulls you — same action, opposite outcomes.

One of Osmani’s sharper observations: two people running the same loop can land in opposite places. One spends the freed-up time going deeper on hard problems; the other spends it avoiding them. The loop can’t tell the difference — only you can. Which is why designing loops isn’t easier than designing prompts; if anything it’s harder.

Cherny’s point comes out the same way: the work didn’t get easier; it moved — from writing prompts to designing loops.

Or, borrowing Osmani’s closing line: build loops, but build them as someone who means to stay an engineer, not as someone pressing a button.

And one more thing to hold onto: prompting directly still works. You don’t have to route everything through a loop. It’s a matter of picking the right approach for the job.

From Theory to Implementation — loop-kit as a Worked Example

So how do these principles — verification at the center, maker separated from grader, memory kept outside, hard brakes against runaways — look in actual code? Of the three warnings above, the one loop-kit takes on directly is the first: verification is still your job. Turning "it’s done" from a claim into something the system can prove — that’s the piece I built out, as one worked example, and released as loop-kit.

It’s not a toy prototype. loop-kit started as something I built for my own daily production work, then generalized and pared down by stripping out everything specific to one project. I took a setup that had been designed and proven in real use, then reshaped it into something anyone can pick up and use to try Loop Engineering. In a line: a thin, shell-based harness plus a set of skills that runs Claude Code not as a single chat but as a system that keeps cycling through the work until a stop condition is met. No server, no daemon — just shell scripts and prompts.

Of the four loop types, loop-kit implements the goal-based one: fix a spec, cycle until green. That "one-off but complex implementation" use from earlier is exactly this. Why start there? Because I think a goal-based loop with verification at its center is the natural basic unit the other kinds build on. It’s small and self-contained, and the outer mechanisms — time-based, proactive — mostly come down to calling and combining it: start it on a schedule, fire it on an event. The self-improving loops I’m working on sit on the same base. For an introductory implementation, it’s the most sensible place to start.

What happens once you hand over the requirements

From handing over the requirements to a finished result, it runs roughly like this:

1. Build the contract. Claude Code explores the repo interactively and, asking only about the unknowns it can’t resolve itself, writes out the requirements, non-goals, acceptance criteria, and success criteria — when it’s allowed to stop — as a "contract."

2. Approve the contract. The moment you approve, the content is locked to a hash, so the success criteria can’t be quietly changed later.

3. Split into tasks. It draws up a plan from the contract and handles dependent pieces in sequence and independent pieces in parallel, each in its own isolated workspace.

4. Run the loop. For each task it reads the contract, plan, and progress, implements one step, then a non-model script re-runs your verification commands to confirm the result (verify), and a reviewer with a fresh context reads the requirements first and the diff last, checking for drift from the spec and for regressions (review). If the success criteria are met, it stops; if they are not, it repeats the cycle, with a fresh context each pass. If it hits the iteration or time cap, or reaches something that needs human judgment — an irreversible action, or a change to the requirements themselves — it stops and hands off to you.

5. Produce the evidence. When it’s done, it outputs an evidence report of what was verified and how, rather than a pile of diffs. Anything that ran in parallel gets a final pass, reviewing the merged whole against the original contract.

At its heart are four steps:

Implement → verify (external evaluator) → review (independent reviewer) → stop if met, back to implement if not.

The key move: the decision to stop the cycle isn’t the working agent’s self-report. It’s made by an external evaluator that re-runs the verification commands mechanically, plus an independent reviewer working in a separate context. That’s the difference from /goal earlier — going past independence of judgment to independence of verification.

The first-half principles are built into each part of this: the contract stays fixed while the implementation stays free, no self-grading, memory lives outside and starts fresh each pass, hard brakes stop runaways, and you review evidence rather than diffs.

loop-kit may well keep changing as Loop Engineering theory does, so for usage, configuration, commands, and current implementation details, always check the latest repository README. Two practical notes before you try it. It assumes Opus by default, so depending on your plan you may want to swap in a lighter model. And some requirements push the iteration count — and token use — up, so it’s worth starting small.

• loop-kit (repository): https://github.com/Aitne-sh/loop-kit

In Closing

Loop Engineering is one of the real shifts in how engineering works in the AI era, and it drew a burst of attention in June 2026. It isn’t just "automation." It’s a higher-order skill: deciding how much judgment to keep for yourself and how much to hand to the system.

It’s early, and there’s a lot to be careful about. Token costs can balloon if you’re not watching, and comprehension debt can build up quietly. So the move is to start with one low-risk pattern — a report-only triage, say — run it once by hand, and tighten the weaknesses it exposes. loop-kit is meant, among other things, as an on-ramp for that first run.

The goal is not to fight the tools, and not to hand yourself over to them either, but to keep your judgment sharp and remain able to reason about the system you’ve built. That, to me, is what staying an engineer looks like at this new layer.

This article is based on English-language primary and official sources as of 2026: Addy Osmani’s "Loop Engineering" and "Agent Harness Engineering"; Anthropic’s official documentation ("Effective context engineering for AI agents" and the Claude Code team’s loop explainer); Birgitta Böckeler’s (Thoughtworks / martinfowler.com) writing on harness engineering; remarks by Peter Steinberger and Boris Cherny; and Geoffrey Huntley’s "Ralph" technique. Since tool features and commands can change, please confirm specific details on each official site.