Loop Engineering Minus the Hype

“Loop engineering” is having a moment.

Peter Steinberger, the creator of OpenClaw, told a few million people to stop prompting coding agents and start designing the loops that prompt them. Boris Cherny, who created Claude Code, says he no longer prompts Claude directly. Loops prompt Claude, and his job is to write the loops.

Then the pattern got a name, and the hot takes followed 😱

The basic idea is: instead of guiding a coding agent step by step, define a “loop” that lets it keep working until the task satisfies some “done” condition while you sleep, eat, and live the good life. The loop keeps the pesky agent accountable and on track as it builds your empire. Win-win!

With a bit of patience, you could set up teams of agents continuously building, reviewing, deploying, and repairing software while humans occasionally adjust the machinery.

This vision sounds too good to be true.

And it is, kind of.

It also contains a grain of truth.

The problem is figuring out which grain.

The agent is already a loop

The first slightly awkward fact is that a coding agent is already a loop.

Codex and Claude Code do not take one action and stop. They inspect the codebase, make a change, run a command, look at the result, reconsider, make another change, and continue until they believe they are done.

Sometimes they believe this a little too early, but the looping part is already there.

So when we add another loop around the agent, that loop needs to do something useful beyond saying:

Please continue looping. Make no mistakes!

With that said, a loop can be genuinely additive and still be a terrible idea.

Why?

I’m glad you asked.

“Make all the tests pass” is not a complete specification

The usual loop story assumes that success is already defined, or at least can be defined with little ambiguity.

Unfortunately, product development often does not work that way.

The building process and the discovery process happen together.

You change a screen because the product manager asked for it, and an end-to-end test breaks.

Is the feature wrong?

Or is the test now obsolete?

The failure tells you that two sources of truth disagree. It does not tell you which one should win.

Now the loop has a problem.

A rigid loop gets stuck banging its head against obsolete tests and irrelevant constraints.

A flexible loop can “succeed” by weakening the tests, accepting scope creep, drifting away from the original intention, or redefining the task until its current output counts as done.

This is not because the model has bad intentions but because every specification has gaps, and the model is forced to fill them.

But let’s say we can somehow write a near-perfect specification.

There is still another problem.

Sometimes defining the loop is more work than doing the task

Defining good verification upfront can take longer than building the feature interactively with the agent.

To create a robust loop, you may need to spell out:

• what should change;
• what must not change;
• which edge cases to consider;
• which risks are acceptable;
• what counts as complete;
• when the agent should stop;
• what it may fix autonomously;
• what it must escalate.

At some point you may notice that you are not merely “defining the loop.”

You are designing the feature plus massive scaffolding around it, but wait...

Interactive development with a good coding agent is already quite fast.

You ask it to build something. You look at it. You notice that the empty state is weird, the mobile layout is broken, and the filter should probably survive a page refresh.

You clarify.

It changes the implementation.

You look again.

The implementation helps you discover the specification.

So the relevant question is not:

Is writing a loop faster than writing the code myself?

That comparison is obsolete.

The real question is:

Is defining and supervising the loop faster than building the feature interactively with an agent?

For a one-off, ambiguous product feature, I suspect the answer is often no.

The obvious counterargument is amortization.

If you build the verifier once and then run it every night, across every repository, or for the hundredth dependency upgrade, the setup cost starts to make economic sense.

Correct.

That gives us a useful rule:

Loops make sense when the cost of verification can compound across many attempts or many tasks.

This brings us to the places where loops really do look powerful.

1. Handoff loops: make the agent finish its homework

Coding agents often stop at a slightly irritating point.

They implement the feature. They run a unit test. Maybe they run the type checker.

Then they proudly tell you the work is complete.

You open the app and the button does nothing.

A better handoff loop could:

• start the application;
• open the relevant flow in the browser;
• click through the changed behaviour;
• inspect console and network errors;
• run the relevant tests;
• push the branch;
• wait for CI;
• inspect review comments;
• fix clear, in-scope issues;
• surface only the comments that require an actual decision.

The goal is not full autonomy.

It is to stop involving the human before the agent has exhausted the cheap and obvious work.

The loop should not blindly satisfy every reviewer or rewrite every failing test. Its job is to finish the routine work and package the disagreements.

I think this category is immediately useful.

I also would not overinvest in it.

Browser testing, CI monitoring, and review follow-up are generic capabilities. Codex, Claude Code, and similar harnesses have every reason to absorb them.

It may be worth building a lightweight version today because it saves you time today.

It is probably not worth creating a grand internal “agent orchestration platform” around the fact that the coding agent currently forgets to open Chrome.

2. Search loops: let the agent hill-climb

The second category is repeated search against a measurable target.

Suppose the goal is:

• reduce latency;
• lower memory usage;
• increase throughput;
• migrate a subsystem;
• upgrade a dependency without breaking compatibility;
• rewrite a service in Rust while preserving behaviour.

These tasks have something precious:

A success landscape.

The agent can make a change, measure the result, keep improvements, discard regressions, and try again.

You can even run several agents in parallel and choose the best result.

This is much closer to actual software-factory work. The target is stable enough that repeated search is useful.

Of course, the target is only as good as the guardrails around it.

A Rust rewrite that passes all tests may still have worse operability, broken failure modes, or subtle behavioural differences the tests never captured.

So the first step may be building the environment in which the loop can safely search:

• benchmarks;
• regression tests;
• behavioural contracts;
• rollback mechanisms;
• resource limits;
• production-like inputs.

That setup may be expensive.

But unlike the specification for a single product feature, it can pay for itself repeatedly.

Every attempt, every parallel agent, and every future task of the same type benefits from it.

This is where the economics start to work.

3. Operational loops: the source of the software-factory dream

The third category is the most interesting because the agents do not wait for you to give them work.

The system watches the business and reacts.

It might monitor:

• production errors;
• post-deployment regressions;
• recurring support tickets;
• repeated themes in customer calls;
• security findings;
• data-quality violations;
• failed background jobs.

An agent can cluster related signals, investigate likely causes, reproduce a problem, write a regression test, prepare a fix, and open a pull request.

Sometimes it may even be safe to deploy the repair automatically.

Now we have something that really does look like a factory:

Production emits a signal. The agent investigates it, fixes the problem, deploys the change, monitors the result, and waits for the next signal.

This is the image that sends everyone racing toward fully autonomous software companies.

But there is a subtle switch hiding inside the story.

Operational loops are very good at two things:

1. restoring known-good behaviour;
2. surfacing useful evidence and insights.

They are much less obviously good at deciding what “good” should mean.

An agent can detect that a deployment broke checkout and restore the previous behaviour.

It can notice that hundreds of customers struggle with onboarding step three and present the pattern, examples, and likely causes.

But should it redesign the onboarding flow?

Which trade-off should it make?

Should the product become simpler for new customers at the expense of expert users?

Is this problem more important than the five other things the company could build?

Now we are no longer repairing the machine.

We are deciding what machine to build.

This is the distinction the software-factory metaphor tends to hide.

Regulators and reference-setters

In control-system language, loops make good regulators and poor reference-setters.

A regulator keeps a system close to a target.

A reference-setter chooses the target.

Agent loops can plausibly:

• finish predictable work before handing it back;
• search within measurable and well-guardrailed environments;
• restore established behaviour;
• monitor reality;
• turn messy operational signals into useful evidence.

They become much less trustworthy when they must:

• reinterpret vague intent;
• choose between competing product outcomes;
• change the company’s risk tolerance;
• decide which customer pain matters most;
• redefine success while trying to achieve it.

This does not make loop engineering fake.

It makes it narrower and, I think, more useful.

The software factories may be real.

They may keep systems running, optimize them, repair regressions, and continuously bring humans better information.

That would already be a very big deal.

But they will be much better at running and improving a known machine than deciding what machine the business should build next.

And that second problem is where most of the value, and most of the judgment, still lives.