Stop Prompting Your Agents. Start Designing Loops.
On June 7th, Peter Steinberger posted twelve words that sent the AI-coding world into a week-long argument:
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
6.5 million views. Half the replies explaining what it meant. Half insisting it was just cron jobs with a rebrand.
Boris Cherny, who built Claude Code at Anthropic, had said the same thing on stage two days earlier: "I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude and figuring out what to do. My job is to write loops."
The developer debate was about architecture. The product and exec question is simpler: does this actually change how teams ship? It does. And if your team hasn't figured this out yet, the gap is already opening.
We had a feeling this moment was coming. Back in March, before the loop engineering conversation went mainstream, we published The Coding Agent That Learns From Its Own Mistakes — a breakdown of how to build a three-model feedback loop where an agent executes a task, an evaluator scores it, and a meta-prompt rewrites the agent's instructions based on what went wrong. No retraining. No weight updates. Just a system that gets better every time it fails. That piece was about the same architectural shift Peter and Boris would later describe to millions of people.
This article is the strategic layer on top of it: why that shift matters for product teams, and what separates the loops that compound from the ones that run up a bill.
Stay ahead of what's changing in AI and product development. The Product Builders newsletter covers the shifts that matter for product leaders and the teams building with AI. Subscribe here.
What Is Loop Engineering?
Loop engineering is the practice of designing automated systems that prompt AI coding agents, evaluate their output, and decide whether to continue or stop without requiring a human to supervise each step. Instead of an engineer writing a prompt and waiting for a result, a small program handles the cycle: call the agent, check the result, retry or halt based on a predefined condition. The engineer moves from being inside the cycle to designing the cycle. This is the core shift from agent-assisted development to agentic development.
Your Agent Is Frozen. Here's Why.
For two years, getting value from an AI coding agent has looked like high-effort ping-pong. An engineer writes a prompt, reads what comes back, adjusts, sends the next one. The agent is capable. But the moment the engineer steps away, it freezes. Their attention is the engine.
Think about how your team currently uses an AI coding agent. An engineer writes a prompt, reads what comes back, decides if it's good enough, then writes the next prompt. The agent is capable. But it's waiting at every step. The engineer is the one deciding when to continue, when to retry, when to stop. Remove the engineer and nothing moves.
A loop changes that contract. Instead of an engineer deciding what to ask next, a small program does it. That program calls the agent, reads the result, runs a check: do the tests pass? Does the linter come back clean? Based on the answer, it either keeps going or stops. The agent doesn't wait for a human to read its output and decide what comes next. The system does.
That's the entire mechanic. The engineer moves from being inside the cycle to designing the cycle. And the thing that makes it work isn't the agent. It's the check. If "done" is something a program can verify on its own, the loop can run at 2am. If it isn't, you still need a human in the chair.
This Time, the Models Can Actually Do It
The skeptics who called loop engineering a rebrand aren't entirely wrong. The underlying idea — agent runs task, checks result, retries if needed — has been around since the ReAct research paper in 2022. AutoGPT was an early version of it. It became famous for spinning in circles doing nothing, which seeded years of "agents are a toy" skepticism.
What changed is not the idea. It's the capability.
METR, the nonprofit that benchmarks frontier AI models, found that Claude Opus 4.6 can complete 50% of tasks that take 12 hours autonomously. A year ago, the equivalent model topped out at one hour forty minutes. The ceiling moved six times over. Context windows are now large enough that an agent can hold an entire codebase across an entire run without losing the thread. Both Claude Code and OpenAI Codex now ship loop primitives natively: scheduled runs, goal commands, sub-agents, and isolated workspaces built in, not bolted on.
The result is measurable. Anthropic disclosed in June that over 80% of the code merged into its own production codebase in May was written by Claude, up from low single digits sixteen months ago. Engineers are shipping roughly eight times more code per quarter than in 2024. Google reported roughly 75% of its new code is now AI-generated and human-reviewed, up from 25% in late 2024.
Those numbers don't come from engineers writing better prompts. They come from loops.
The Constraint Moved. Has Your Team?
The bottleneck is no longer model capability. It's orchestration. That shift has a direct cost if you haven't acted on it.
Picture a product team running a monthly bug bash: two engineers spend two days triaging minor issues, nudging an agent through each fix, re-prompting after each test failure. The agent is capable of running that entire cycle unattended. But without a loop, it waits. Every re-prompt is time. Multiplied across a sprint, across a quarter, it's a meaningful fraction of capacity spent on work that requires no judgment, only supervision.
Loops handle that supervision. Not the hard problems. The 1% improvements on cruise control: the UX paper cuts, the flaky tests, the doc updates after a schema change, the API error categories. The things that drain sprints without ever needing strategic input. Hand those to a well-designed loop and you get the hours back for work that actually requires a human.
Still manually prompting agents to get work done? The Product Builders has shipped AI systems inside Apple, Mastercard, and Toyota. If your team is ready to move from prompting to building systems that run without you, we can help you design the loops, the verifiers, and the orchestration layer to make it happen. Book a strategy call.
The Loop Stack: Four Controls That Separate Working Loops from Expensive Ones
Most loop engineering failures aren't model failures. They're design failures. Every functional loop is built on four controls.
Goal — The exit condition must be something the system can evaluate without asking a human. "Improve the code" is not a goal a loop can check. "All unit tests pass" is. "Linter returns zero errors" is. If you can't write the condition in one objectively checkable sentence, the loop doesn't know when it's done.
Context — The agent needs fuel: project conventions, past run logs, error traces, known gotchas. Loops that start each run without memory of the previous one are starting from scratch every time. A markdown file, a JSON state log, anything that survives between runs and gets read at the start of each one.
Verifier — A model checking its own output is consistently too lenient. The verifier must be a separate component: a second model with different instructions, a test suite, a rubric applied independently. This is the most underbuilt part of most agentic workflows, and it's the part that determines whether "done" means something real or just means the agent stopped.
Ceiling — Without a hard cap on iterations, a no-progress check, and a token budget, a stuck loop becomes an open invoice. Uber burned through its entire 2026 AI budget in four months before capping individual tool spend at $1,500 per person per month. Every loop ships with these three controls or it doesn't ship.
The Debt Loops Create When You Build Them Wrong
Here's the part most loop engineering explainers skip.
A 2026 NBER study found AI agents raised the volume of code written by 180% while code that actually shipped to production rose only 30%. That gap has a name: comprehension debt. Code that lives in your repo but that no one on your team fully understands, written by a system that was confident it was done and had no one checking carefully enough to disagree.
Comprehension debt accrues fastest when verification is weak. When "done" is a claim the agent made rather than a condition the verifier confirmed. And it compounds quietly, with each loop run adding to a codebase that moves faster than the team's understanding of it.
A loop with a careful verifier, real project conventions baked into its context, and someone reading the diffs will build something. A loop without those things generates technical debt at machine speed. It doesn't produce less output than a well-built loop. It produces more.
The real competition isn't between teams running loops and teams that aren't. It's between teams that built the verification layer and teams that didn't. The dangerous position isn't no loops. It's confident loops with thin rubrics, running unattended, shipping work that passes the check without meeting the bar.
Start Here
Pick one repetitive task your team currently does by manually prompting an agent. Write the exit condition in one objectively checkable sentence. Build the verifier before you build anything else. Set an iteration cap and a spend ceiling. Run it on something low-stakes.
The architecture gets more sophisticated from there. But the first loop that runs and halts correctly teaches you more than any explainer. Including this one.
The teams that pull ahead in the next 18 months won't win because they shipped more code. They'll win because they built loops that knew when to stop.
Frequently Asked Questions
What is loop engineering? Loop engineering is the practice of designing automated programs that call AI coding agents, evaluate their output against a predefined condition, and decide whether to continue or stop without a human supervising each step. The engineer designs the system; the system runs the agent.
How is loop engineering different from just using cron jobs? A cron job triggers a task on a schedule. A loop actively evaluates whether the task was completed correctly and decides what to do next based on the result. The verification and conditional logic are what make it a loop rather than a scheduled script.
What AI coding agents support loop engineering? Claude Code and OpenAI Codex both now ship with native loop primitives including scheduled runs, goal commands, sub-agents, and isolated workspaces. Earlier tools required engineers to build orchestration layers manually.
What's the biggest mistake teams make with loop engineering? Skipping the verifier. Most teams define a goal and build the loop, but let the agent evaluate its own output. A model checking its own work is consistently too lenient. A separate verifier — a second model, a test suite, or an independent rubric — is what makes "done" mean something real.
Is loop engineering only for large engineering teams? No. The entry point is a single repetitive task — a bug triage, a doc update, a schema change — that your team currently handles by manually prompting an agent. One loop, one exit condition, one verifier. That's the starting point regardless of team size.
Want to ship products faster with AI? The Product Builders are operators who've built at Fortune 500 scale and know the difference between AI that creates competitive advantage and AI that creates expensive demos. If you're ready to build the systems that move your product faster, let's talk. Book a 30-minute strategy call — no pitch, no fluff. Just an honest conversation about what you're building and what we'd do differently.