There's a big gap between telling an AI tool “just do this” and telling it “do this to this quality bar, check it, fix what's missing, and stop at this point.” That gap has a name now: loop engineering.
At first glance this looks like developer territory. “Loop” is a word coders have lived with for decades — while, for, condition, repeat, stop. But that framing misses the most valuable part of the idea. This guide walks through what's actually verified in the sources, and why this is turning into something anyone who does repetitive work at a computer needs to understand.
Where the term came from
Loop engineering is what happens when a hunch that had been floating around the software world for months finally gets a name. That name belongs to Addy Osmani, who spent more than fourteen years at Google leading developer experience work across Chrome and, more recently, AI. He published the post that defined the term on June 7, 2026.
The line that made it go viral, though, came from Boris Cherny, the engineer who built Claude Code at Anthropic. In an interview, he put it bluntly: “I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” That's not a futurist's soundbite — it's the person behind the most widely used agentic coding tool describing how he actually spends his day.
Developer Peter Steinberger captured the same shift even more sharply: “You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.” That's the whole idea in one sentence — you stop being the person who prompts the agent, and instead you design the system that does it for you.
Worth noting: Anthropic's own documentation doesn't use the label “loop engineering” — it organizes the same idea under agentic loop, Agents, Workflows, and Augmented LLM. The name is community-coined; the engineering underneath it is very much Anthropic's own.
What loop engineering actually is
Stripped down, a loop is four or five moves on repeat:
Discover
Gathers context, finds the work.
Act
Takes the action toward the goal.
Verify
Checks the output against a stated bar.
Repeat / Stop
Loops until the criteria hold, then quits.
Any developer already knows this rhythm: a test fails, you read the error, you change the code, you rerun the test, you keep going until it passes. AI agents have started working the same way — gathering context, taking an action, checking the result, and stepping back into the same loop if the result isn't good enough.
Here's the part that actually matters: what's cycling through the loop isn't a line of code. It's a work process. Loop engineering means describing to the AI not just what to do, but how it should repeat and when it should stop.
The four-layer stack
In under eighteen months, the field moved through four distinct engineering layers. Each one automates something you used to do by hand. Loop engineering sits at the top of that stack — and it doesn't replace the layers underneath it, it wraps around them.
| Layer | The Core Question | What It Automates |
|---|---|---|
| Prompt Engineering | What should I say to the AI? | The phrasing of a single instruction |
| Context Engineering | What should the model see? | Tools, examples, history, retrieved documents |
| Harness Engineering | What environment should the agent run in? | The scaffolding around one agent's session |
| Loop Engineering | How should the system find and verify its own work? | Discovery, handoff, verification, persistence, scheduling |
Anthropic's engineers make this point explicitly: the prompt is only one slice of what the model sees; the rest is tools, examples, message history, and other retrieved context. That's exactly why loop engineering doesn't retire the layers below it.
Why this isn't just for developers
Here's what gets missed most often: most desk workers are already operating inside a loop. Up to now, we've been running these loops manually, in our own heads.
Auditor
Reviews the report → checks for missing findings → verifies the tables are consistent → confirms the action plan has an owner and a deadline → sends it back if anything's missing.
Finance employee
Opens the spreadsheet → checks the totals reconcile → scans for wrong dates, blank columns, discrepancies → reworks the file if something's off.
Marketer
Writes the product description → checks the tone → flags anything too salesy, too long, or off-brand → rewrites if it doesn't land.
Support team
Triages incoming tickets → separates urgent from non-urgent → drafts a short follow-up question when information is missing.
We can now say to an AI system: “Do this, then check it against these criteria. Fix anything missing. Try at most 3 times. If it's still not right, tell me where it got stuck.” That single sentence is far more powerful than a typical prompt — because it doesn't just hand the AI a task, it hands it a working system.
Community coverage backs this out further: a customer-support resolution loop analyzes the ticket, drafts a response, and validates it against the knowledge base; a design loop generates mockups, checks accessibility, and iterates on feedback. Same shape, different domain.
The most important call: separate the maker from the checker
The single most consequential design decision in any loop is splitting the agent that does the work from the agent that checks it. The reason is simple: a model grading its own homework is too generous.
Anthropic's engineering finding: When a single agent evaluates its own output, it confidently praises mediocre work. Tuning a standalone evaluator to be skeptical is far more tractable than making a generator genuinely critical of its own work. This isn't a model flaw — it's a structural one.
In practice this shows up as a planner / generator / evaluator setup, or at minimum a generator-evaluator pair. Even the same underlying model, playing two different roles with two different instructions, is enough. One agent writes the code; a second, sometimes stronger, agent with different instructions checks it against the spec and the tests. In an unattended loop, a verifier you actually trust is the only reason you can walk away from the keyboard.
Anthropic has carried this split into its own product too: Claude Code's /goal command lets you write a stopping condition (“all tests in test/auth pass and lint is clean”), and after every turn, a separate, smaller model checks whether that condition has actually been met. The agent that wrote the code is never the one grading it. Anthropic's own open-source reference repo takes this further with a “default-FAIL” contract: every criterion starts as false, and the agent can't mark it passing without opening evidence first.
Five building blocks, plus one
According to Osmani, a working loop needs five pieces and one place to remember things. What's notable is how quickly this shifted: a year ago, building a loop meant writing a pile of bash scripts and maintaining them forever. Now these pieces ship inside the products themselves.
1Automations
The heartbeat of the loop. Fires on a schedule to handle discovery and triage on its own. Without this, a loop is just something you ran once.
2Worktrees
Keeps two agents working in parallel from colliding on the same file. Isolated working directories sharing the same repo history.
3Skills
Writes down the project knowledge an agent would otherwise guess at, in a SKILL.md file. Intent gets written once instead of re-derived every cycle.
4Plugins & Connectors
Built on MCP, these plug the agent into your actual tools — issue trackers, databases, Slack. The loop stops being a commentator and starts being an operator.
5Sub-agents
One agent has the idea, a different one with different instructions checks it. This is the generator-evaluator split, made concrete.
+1Memory (persistence)
A markdown file, or a project board — anything living outside a single conversation that tracks what's done and what's next. The model forgets every turn; the record doesn't.
That last piece sounds almost too obvious to matter, but it's the trick every long-running agent depends on. Anthropic frames the problem this way: “Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.” Without persistent state, every shift change is a productivity disaster.
A practical playbook, with examples
As a desk worker handing off a task to AI, describing these four things is usually enough:
Goal
What should get produced?
Check criteria
How will good output be recognized?
Stop condition
When will the AI decide it's done?
Retry cap
How many times, at most, should it try again?
A sample loop prompt for turning a report into an executive summary:
“Turn this report into an executive summary. Then check whether risk, action, owner, and deadline information is missing anywhere. If something's missing, list it and revise the summary accordingly. Do at most 3 revision cycles. If information is still missing after that, don't guess — tell me exactly what's left incomplete.”
Same logic, different domains:
The common thread: we're not just asking the AI for output. We're giving it the control mechanism too. The power of a prompt like this isn't its length — it's that it describes the loop.
Four costs that don't announce themselves
“The AI will just handle it” is a misleading way to think about this. A poorly specified loop doesn't speed things up — it can drag you into something messier. Four costs sit quietly underneath a running loop, and none of them trigger an alarm while it's running:
Verification debt
An unsupervised loop is also an unsupervised source of mistakes. “Done” is a claim, not proof. Your job is still to ship work you've confirmed actually works.
Comprehension rot
The faster the loop ships work you didn't write, the wider the gap grows between what exists and what you actually understand. Not reading what the loop produced makes this debt compound fast.
Cognitive surrender
When the loop runs itself, it's tempting to stop having an opinion and just accept whatever comes back. The most comfortable posture is the most dangerous one.
Token blowout
Someone who doesn't know what they want keeps the AI spinning in the same place. It might loop 50 times, or 500 — burning tokens and time on every pass.
Osmani's summary of this cuts right to it: two people can build the exact same loop and get completely opposite results six months later. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do.
What this means for Türkiye and institutions
In Türkiye, a large share of both public and private sector work still treats digitalization as “the software team's job.” Loop engineering breaks that framing. Standardizing audit reports, automating reconciliation checks, summarizing regulatory text while scanning it for consistency, prioritizing call-center requests — these are all loops, and none of them require a software developer. What they require is a domain expert who can define the work clearly and write a genuinely usable check criterion.
In institutional settings, three safeguards matter especially: verification (a stopping condition that refuses to guess in official documents and instead asks a human when unsure), traceability (a log you can use to reconstruct every step the loop took), and a boundary on authority (requiring human sign-off before the loop touches production systems). These three checkpoints are what turn unsupervised automation from a risk into genuine leverage.
In short: as AI tools become more agentic — reading and writing files, running commands, connecting to outside systems — how we manage them has to change too. Learning to say “do this to this quality standard, and stop here” instead of just “do this” is going to be a core skill of the next few years.
Build the loop. Stay the engineer.
Loop engineering doesn't replace prompt engineering — it turns it into a more serious working system. A good prompt still matters, but it's no longer enough to just write a nice sentence. You also have to design the loop the AI is going to run inside.
The people who use AI well over the next few years won't just be the ones asking good questions. They'll be the ones who describe good processes. Getting an AI to do a task is one thing. Getting it to run the right loop is another.
Build the loop. But build it like someone who intends to stay the engineer.
Not just the person who presses go. Designing a loop with judgment is a genuine lever; designing it to avoid thinking is a trap. Same action, opposite outcome. What decides the difference is you.
Sources and verification
Every claim in this guide has been checked against a primary or highly credible source. The list below is ordered by thematic relevance.
- Addy Osmani, “Loop Engineering”, June 7, 2026. Original definition of the term, the five-building-blocks-plus-memory model, and the failure modes. — addyosmani.com/blog/loop-engineering
- Anthropic Engineering, “Effective harnesses for long-running agents”, November 2025. The generator-evaluator split, the persistence file, and the “engineers working in shifts” analogy. — anthropic.com/engineering
-
Anthropic, cwc-long-running-agents (open-source reference repo). The
/goalgenerator/evaluator loop and the “default-FAIL” contract. — github.com/anthropics/cwc-long-running-agents - The New Stack, “The Anthropic leader who built Claude Code says he ditched prompting”. The Boris Cherny quote and the mapping of six primitives across Claude Code and Codex. — thenewstack.io/loop-engineering
- Cobus Greyling, “Loop Engineering”. A roundup of the Steinberger and Cherny quotes and the MCP-based operator loop pattern. — cobusgreyling.substack.com
- Adnan Masood, PhD, “Loop Engineering: A Guide for Engineers and Practitioners” (Medium, June 2026). Triggers, topologies, stop rules, and cost control. — medium.com/@adnanmasood
- Takashi Kishida, “How Anthropic Organizes Loop Engineering”. Anthropic's own terminology: agentic loop, Agents, Workflows, Augmented LLM, and the “prompt → workflow → agent” decision order. — note.com/takish
About the author
Ridvan Bilgin is a disaster risk management specialist coordinating Provincial Disaster Risk Reduction Plan (İRAP) work, writing on digitalization and disaster risk reduction for both Turkish and international practitioners. He is a co-author of a peer-reviewed paper on the 6 February 2023 earthquakes published in the Journal of Risk Research (Teker, Bilgin & Yildiz, 2026, doi:10.1080/13669877.2025.2611952).
What are your thoughts on this topic?
Every article is an open conversation. Whether you have a counter-argument, a local example, or a different perspective based on your own experience, your contribution makes this space better.
0 Comments