What Is Loop Engineering? A Practical Guide for Non-Developers

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.

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.

Stripped down, a loop is four or five moves on repeat:

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.

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.

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.

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.

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 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.

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.

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.

As a desk worker handing off a task to AI, describing these four things is usually enough:

A sample loop prompt for turning a report into an executive summary:

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.

“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:

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.

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.

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.

Every claim in this guide has been checked against a primary or highly credible source. The list below is ordered by thematic relevance.

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).