Loop Engineering: The Skill That's Replacing Prompting

 

June 7, 2026. A developer posted twelve words on X and walked away.

By the next morning, the entire AI-engineering corner of the internet was arguing about it.

Peter Steinberger — creator of OpenClaw and now at OpenAI posted this: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

The replies split cleanly. Half called it the realest thing they'd read all year. The other half called it a cron job wearing a hoodie.

And then Boris Cherny — the person who actually built Claude Code at Anthropic said the same thing on stage, independently, the same week: "I don't prompt Claude anymore. I have loops running. My job is to write loops."

Two practitioners. Two different companies. Same conclusion.

The post racked up millions of views and that's when people stopped arguing about whether loop engineering was real and started asking: what actually is it, and do I need to learn it? 

What Loop Engineering Actually Is

Before getting into the how, let's fix the what because most articles are circling the definition without landing on it.

Loop engineering is the practice of building a system that does the prompting for you.

You stop being the person who types tasks into an AI agent and starts being the person who designs the automated system that does it — one that picks the next task, sends it to the agent, checks the output, decides whether to retry or move on, and runs again. Without you watching.

Think of it this way. Prompt engineering is playing chess — one deliberate move at a time, all of your attention on the board. Loop engineering is building the chess engine. You define the goal, set the rules, and let the machine play.

This isn't a tool change. It's a role change.

Why Prompt Engineering Alone Doesn't Scale Anymore

If you've used Claude Code, Codex, or any serious coding agent in 2026, you've already felt this problem; you just might not have named it yet.

Your workflow probably looks like this: write a prompt → agent does something → something breaks → paste the error back → try again → repeat until you lose faith in the process or in yourself.

You wanted to offload the work. Instead, you became the work.

This is the exact tension at the heart of prompt engineering vs loop engineering. One optimizes a single conversation. The other builds a repeatable system around many conversations. The prompt doesn't die, it just stops being the thing you're responsible for crafting by hand every single time. It becomes a component inside a larger machine.

Simon Willison called this shift out in September 2025: "Designing agentic loops is a critical new skill to develop." What changed between then and Steinberger's June 2026 declaration isn't the idea — it's the infrastructure. The tooling finally caught up. Claude Code, Codex, and LangChain now ship the building blocks natively.

The Five Parts of a Loop That Works

Here's where most articles on loop engineering stop being useful. A loop isn't "AI running forever." That's not a feature. That's a runaway cost event.

A functioning agentic AI workflow has five components and two non-negotiables before you touch any of them:

Non-negotiable #1: A trigger. Something starts the loop — a pull request, a failing test, a daily schedule, a Slack message. Without a trigger, you don't have a loop. You have a one-shot script.

Non-negotiable #2: A verifiable exit condition. Something tells the loop when to stop. Deterministic (all tests pass, CI is green) or model-based (a grader agent checks output against a spec). No exit condition means no loop. It means an expensive, confident token furnace running until your budget does.

Once those exist, the five structural pieces are:

• Automations — scheduled triggers that handle discovery and triage without you

• Worktrees — isolated environments so parallel agents don't overwrite each other

• Skills — documented project knowledge the agent would otherwise hallucinate

• Sub-agents — one to generate, one to verify; the separation is what makes output trustworthy

• State memory — a file, a board, anything that lives outside the conversation window; agents forget between runs, the repo doesn't

This is what designing AI agent loops actually looks like as an architectural decision, not a vibe, not a theory. A structure with a start, a check, and a stop.

Wait, Is This Just a Cron Job?

The most common pushback. And it's fair.

Here's the real answer: a cron job runs the same fixed script every time. Same commands. Same output. No awareness of what happened before or what's different now.

A loop runs an agent that reads the current state, decides what action fits, executes it, evaluates the result, and chooses its next move — continue, retry, escalate, or halt. The decision-making lives inside the loop, not outside it.

The cron job gets dressed the same way every day. The loop checks the weather first.

That decision capability is only viable now because LLMs in 2026 are genuinely good enough to understand goals and evaluate whether they've been met which is what Boris Cherny and his team at Anthropic built Claude Code to do from the ground up.

The Part Nobody's Talking About: Loop Engineering Has Real Costs

Here's the angle you won't find in most breakdowns.

Loop engineering at scale is expensive by design. When agents are running continuously, calling tools, retrying failures, spawning sub-agents, token consumption compounds fast. According to the FinOps Foundation's State of FinOps 2026 report — based on 1,192 organizations representing over $83 billion in annual technology spend — 98% of enterprises now actively manage AI costs, up from just 31% two years ago. That's not a gradual adoption curve. That's organizations scrambling to govern costs they didn't see coming. 

The teams doing this well aren't giving agents unlimited runway. They're doing the opposite: spending limits per run, maximum iteration counts, human approval checkpoints at consequential decisions, and grader agents that kill the loop before it spends another thousand tokens on a task it's already failed twice.

This is what separates prompt engineering vs loop engineering in practice. Prompt engineering fails silently — you get a bad answer and move on. Loop engineering fails loudly and expensively if you haven't engineered the failure modes as carefully as the success path.

Controlled autonomy, not unlimited autonomy. That's the actual design goal.

What This Means If You're Not a Developer

Loop engineering is getting framed as a developer concept. It isn't, not entirely.

Every team that uses AI to do repetitive, multi-step work — content pipelines, customer support triage, QA testing, code review, data enrichment is either running a manual loop right now (you're the loop) or about to discover that building an automated one is how they scale.

The shift from prompt engineering to loop engineering isn't about which tool you use. Claude Code and Codex both support it. LangChain documents the loop levels explicitly. The shift is in how you think about your role.

You're not the agent. You're not the prompt writer.

You're the architect of the system that runs both.

If your team is still manually babysitting AI agents through every task, you're the bottleneck, and building the right loop design is what fixes that. Vovance is a tech consulting company that helps businesses move from manual prompting to production-grade agentic systems: from the trigger that starts the loop to the verifiable exit that proves it worked. If that's the next move for your team, let's build it.