Loop Engineering, or: The Cron Job Buys a Hat

On June 7th, Peter Steinberger — the creator of OpenClaw — posted twelve words and broke the AI-coding internet for two weeks:

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

Two-point-two million views. By the next morning the timeline had picked sides, coined a name, and held a funeral. Prompt engineering — the discipline we were assured eighteen months ago was the skill of the decade — was dead. Long live loop engineering.

It got the full ceremony. Boris Cherny, who built Claude Code at Anthropic, said the quiet part into a microphone: "I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops." Addy Osmani at Google gave it a proper name and a diagram. Then Anthropic shipped /loop and /goal as native features, and everyone who'd spent a fortnight arguing got to feel prophetic. The argument became a feature. The feature validated the argument. Beautiful.

I've run Claude Code in a terminal every working day for about a year. So let me offer the take that doesn't trend: this is a real and useful idea, and almost everyone is being insufferable about it.

What a loop actually is

Strip the costume off and a loop is three things:

1. A trigger — a schedule, a PR opening, a command.
2. A goal — something checkable. Tests pass. The build is green.
3. A verifier — the thing that checks the goal and decides whether to run the agent again.

The agent runs, checks itself against the goal, and goes again until it gets there or hits a limit. That's it. That's the paradigm shift.

Reddit, to its eternal credit, summarized the whole movement in six words: it's a cron job wearing a hat.

And — look — it kind of is. A loop with a trigger and a stopping condition is a while loop your CS professor would recognize. The genuinely new part isn't the loop. It's that the body of the loop is now a non-deterministic agent that can edit your codebase and occasionally lie about whether it worked. That's not nothing. But it's also not a new branch of engineering. It's automation, which we've had since the first person got tired of typing the same thing twice.

The number nobody puts on the slide

Here's the part the twelve-word philosophers skip.

An agent loop makes 10 to 100 times more model calls than a single prompt — and each call re-sends the whole growing conversation, so the cost doesn't just add up, it compounds. An unattended loop is a machine that consumes tokens at the exact rate of its own confidence, which for an LLM is "total" right up until it's wrong.

Which is why the people calling this obvious tend to be the people with unmetered tokens. When you work at a frontier lab, "just let it loop overnight" is free. On a $20 consumer plan, the same advice burns through your rate limit before lunch and leaves you with a branch full of confident nonsense and a usage warning. The economics of the evangelists do not generalize to the economics of the audience, and almost nobody says so out loud.

Gary Marcus called the self-improvement framing a "bait and switch" — what's actually on display is faster coding under human supervision, not a system bootstrapping itself to godhood. Ed Zitron, less gently, asked whether the whole movement is just "evangelizing autonomous token consumption" — the exact behavior the labs would most like to make a habit. You don't have to agree with either of them to notice they're asking the question the hype is built to skip past.

The trust gap a loop can't close

There's a number from this year that sits very badly next to "ship while you sleep": 46% of developers actively distrust AI output, and 3% highly trust it. And 45% say debugging AI-generated code takes longer than writing it themselves.

Read that, then re-read "design a loop that ships autonomously." A loop doesn't fix almost right — it mass-produces it. Without a real verifier, a loop is a machine that ships bugs with high confidence and excellent commit messages. Georgia Tech's security folks have already traced 70-plus CVEs to AI coding tools this year. The loop didn't introduce a new bug class; it just learned to write the old ones faster and unsupervised.

So, calmly

Loops are good. I use them. For tightly-scoped, verifiable work — make the failing test pass, fix the lint, conform to the schema — handing an agent a goal and a stopping condition genuinely beats babysitting a prompt. The verifier is the whole game. A loop is exactly as smart as the check it loops against, and a loop with no real check is just a faster way to be wrong.

What I'm allergic to is the costume. We did this with "prompt engineering." We did it with "context engineering." Now it's "loop engineering," and the harness-engineering thinkpieces are already in the chamber. Same idea — be precise about what you ask the machine to do — renamed every nine months so the timeline has something to have a funeral about.

The actual skill hasn't changed since the first cron job: know exactly what you want, and know how you'll check you got it. Everything else is the hat.