Loop Engineering: Overhyped Buzzword or a Real Shift in How Coding Agents Work?

A few weeks ago the creator of OpenClaw posted that developers should stop prompting coding agents directly and instead design loops that prompt the agents for them. Boris Cherny, who built Claude Code, echoed the same idea: he no longer prompts Claude himself, he writes loops that prompt Claude. The reaction split into two camps - people calling it a fundamental shift in how they work, and developers rolling their eyes, insisting this is just while loops and cron jobs dressed up in a new name to justify burning more tokens. Both camps have a point, and the real distinction comes down to one small technical detail that's easy to miss.

What's actually happening inside a coding agent's "loop"

Send a single prompt to a coding agent like Claude Code, and it's tempting to think of it as one input, one output. In reality, the agent is already running its own internal loop: it reads context, calls a tool (edit a file, run a test), reads the result, and cycles again - until it decides on its own the task is finished and stops. Every agent ships with this loop built in.

Loop engineering isn't that inner loop. It's the outer loop wrapped around the whole process - an additional mechanism that decides when to run the agent again, when to stop it entirely, or when to send it back for more work. And as coding agent vendors keep adding more built-in looping features of their own, the line between "inner" and "outer" keeps getting blurrier.

Four levels of loop engineering

The Claude Code team maps this out into four levels, from simplest to most complex:

1. Turn-based - the default behavior of any coding agent. You give a prompt, the agent gathers context, acts, verifies its own work, and repeats as needed. The "is this done" decision sits entirely with the main agent.
2. Goal-based - a second, separate model checks after every turn whether a defined success criterion has actually been met. If not, it sends the main agent back for another round, until the goal is hit or a max-attempt limit is reached.
3. Time-based - the agent simply gets re-triggered on a schedule, either locally or in the cloud. This is, plainly, a cron job - and there's nothing wrong with that.
4. Proactive - all three levels combined: a trigger (schedule or webhook) that fires the process, a goal that defines when to stop, and a workflow that does the actual work. This is the level that lets an agent handle entire categories of tasks - triaging bugs, running migrations - with almost no human involvement.

Not a new idea - so why is everyone talking about it now?

Loops have been a basic part of programming for decades, and the "think, act, observe" pattern most AI agents run on today was published back in 2022. Technically speaking, there's nothing new here. What is new is the mindset: designing an agent upfront to run autonomously, on a schedule or toward a goal, instead of prompting it fresh every single time. It's a shift in approach, not a technical breakthrough.

The real question: who decides the work is actually done

The Claude team's own definition of a loop - an agent repeating cycles of work until a stop condition is met - collapses into a single question: how does the system actually know the work is finished?

In a goal-based loop, the checking model is deliberately small and fast, and it can't run tests itself, open files, or reload a page to confirm a real result. All it has is the conversation transcript. If the main agent genuinely ran tests, those results show up in the transcript and the evaluator can read them - but if the agent only claims it ran tests, ran just a few of them, or broke something several turns earlier, that small evaluator has no way to know. It trusts what's written, not what's actually true.

Even with that limitation, having a separate model grade the work still matters, because left unchecked, the main agent tends to declare success early.

Computational checks vs. inferential checks

To feed a loop reliable signal, it helps to separate two kinds of checks:

• Computational checks - deterministic, fast, and cheap: test suites, linters, type checkers, structural analysis. These run in milliseconds to seconds via hooks, cost zero AI tokens, and their results are fully trustworthy.
• Inferential checks - AI code review, LLM-as-judge, semantic analysis. Slower and more expensive, but able to catch things computational checks can't - from a lightweight sub-agent reviewing a change before merge, to a heavier fan-out review across the whole diff, to a judge running on a schedule against a live system. The richer the feedback, the more trustworthy the loop - which is exactly why AI agents excel at writing code (fast, objective feedback) and struggle more in domains where correctness is harder to verify.

Concurrency, stopping, and cost: the practical risks

A few things worth watching before running autonomous loops for real:

• Concurrency - agents working the same codebase in parallel need isolated workspaces (git worktrees, for example) so they don't step on each other. It works, but adds operational complexity.
• Iteration limits - loops need a hard cap on the number of rounds, or they can run indefinitely. A "soft" limit (asking the agent to stop after N attempts) is less reliable than a hard limit enforced in code.
• Token cost - the easiest part to overlook. A workflow spinning up several agents in parallel can burn through millions of tokens chasing a single goal. It's worth remembering that the loudest voices pushing "loop engineering" are often the ones who profit from token consumption - so it's reasonable to treat bold claims skeptically and actually track what a loop costs in practice.

The takeaway

Loops themselves aren't new - they've been a basic part of programming for decades, and the agentic pattern behind them has been around for years too. What's actually changing is the approach: designing agents upfront to run autonomously, and making sure they genuinely know when they're done - not just when they think they are. A good loop is only as good as its checker: fast computational feedback for everything code can verify, more expensive inferential feedback for everything that needs judgment, and a human still deciding when to give the green light and when to pull the plug.