Boris Cherny built Claude Code. He spends less time talking to it than you’d think.
In June 2026, he said something in an interview that took a few days to travel through developer circles and then didn’t stop traveling.
“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”
That sentence is now the unofficial founding document of a new discipline. Within the same stretch of weeks, Nvidia’s Jensen Huang told a room full of developers something structurally identical.
“Nobody writes prompts anymore. The new job is to write and handle loops.”
Peter Steinberger, the founder of PSPDFKit and creator of OpenClaw, made the same argument to millions of viewers in a single day.
Three people, three companies, the same conclusion, in the same month. That’s not a coincidence. That’s a discipline arriving.
If you’ve spent the last three years getting good at prompt engineering, this is the moment to ask an uncomfortable question: was that skill the destination, or was it just the on-ramp? For enterprise AI teams trying to move agents from pilot to production, the answer determines whether your 2026 roadmap is aimed at the right target.
What actually changed between prompt engineering and loop engineering?
Prompt engineering optimizes a single exchange. You write an instruction, the model responds, you read the output, and if it’s wrong, you write a better instruction.
“Prompt engineering optimizes a single turn: one input, one output, one human in the chair.”
It is, structurally, a conversation where you hold the pen the entire time.
Loop engineering optimizes something bigger: the system that runs that conversation on your behalf, repeatedly, without you reading every reply.
“Loop engineering optimizes a system that runs many turns without you. The loop decides what to ask next, reads the result, checks it against a goal, and either continues or stops.”
The model stops being the person you’re talking to and becomes a component inside something you designed.
This isn’t a rebrand of an old idea with a trendier name.
“This isn’t a rebrand. It’s a shift in what the engineer is responsible for, from the quality of one response to the reliability of an entire execution process.”
A prompt engineer is judged on one good answer. A loop engineer is judged on whether a system can be trusted to run unattended for an hour, a day, or a sprint.
IBM’s framing draws the practical line cleanly.
“Prompt engineering is the practice of creating the single most effective, optimized instruction for an AI model. Loop engineering designs automated systems that self-prompt and evaluate their own work until achieving a specified goal.”
One is a skill you apply to a message. The other is a skill you apply to an architecture.
How did we get from prompts to loops in the first place?
Nobody skipped a step to get here. Research on agentic software engineering traces a direct lineage:
“a progression from prompt engineering to context engineering, harness engineering, and loop engineering. Prompt engineering focuses on how a task is expressed to the model. Context engineering determines which instructions, data, tools, and intermediate information should be made available. Harness engineering connects the model to an executable environment containing files, software, memory, and feedback mechanisms, while loop engineering extends these ideas by defining how the system repeatedly observes, acts, verifies, and recovers.”
Each layer solved a real failure the previous layer couldn’t. Prompt engineering ran out of room once models needed more information than a clever sentence could carry, that’s what pushed teams toward context engineering. Context engineering ran out of room once agents needed to actually do things, not just know things, that’s what pushed teams toward harness engineering. And harness engineering ran out of room the moment a task took longer than one action to finish, which is most real work.
Loop engineering’s own intellectual ancestor predates the 2026 naming moment by years.
“Most modern agent loops trace back to the ReAct pattern (Reason + Act), introduced in research from Princeton and Google. The idea: interleave reasoning steps with action steps. The model thinks out loud, takes an action, sees what happened, thinks again, and acts again.”
What changed in 2026 wasn’t the pattern. It was the moment enough senior engineers admitted, on the record, that manual prompting couldn’t keep pace with what the pattern demanded.
The name for the new discipline itself has a documented origin. It was popularized in June 2026 by Addy Osmani, engineering lead at Google Chrome, synthesizing ideas from Boris Cherny at Anthropic and Peter Steinberger, founder of PSPDFKit/Nutrient.
Rare for a technical term to have a traceable birth date. This one does.
Is prompt engineering actually dead?
No, but it did get demoted. That framing is more accurate than the “prompt engineering is dead” headlines circulating this year, and it matters for how you plan hiring and training.
Gartner has been telling clients something blunter. According to Gartner, 2026, “context engineering is in, and prompt engineering is out.”
Forbes pushed back directly on the funeral narrative, arguing that the underlying skill, communicating intent precisely to a system, never went away, it just stopped being the whole job.
Here’s the version that actually holds up under scrutiny: prompt engineering didn’t disappear, it moved inside the loop. A loop still needs prompts, it just doesn’t need a human writing a new one every time the model responds. IBM’s comparison captures this precisely.
“While prompt chains follow a rigid structure, loops are dynamic and flexible. Prompt engineering is suitable for one-off interactions or individual model calls.”
So if your team spent 2024 and 2025 building prompt libraries, that work isn’t wasted. It’s raw material. The prompts you refined become the reusable components a loop calls on when it decides an action is needed, not the thing a human retypes every morning.
What does a loop actually look like when it runs?
A loop is a repeating cycle with four moving parts: it observes something, decides what to do, acts on that decision, and checks whether the result moved it closer to a goal.
“A loop, in agentic AI, is a repeating cycle where the model takes an action, receives feedback from the environment, and uses that feedback to decide its next move. The loop continues until some termination condition is met, a task is complete, a stopping criterion triggers, or the agent determines it can’t go further.”
The contrast with the workflows most teams already have in production is sharp. A fixed pipeline runs step A, then step B, then step C, in that order, every time.
“A chain runs in a fixed order: step A leads to step B, which leads to step C, and that’s it. A loop is dynamic. The agent might go from A to B, discover B didn’t work, revise its approach, and only then move to C, or it might loop back to A entirely.”
That difference is not cosmetic. It’s the difference between an agent that fails the moment reality deviates from the script, and one that notices the deviation and adjusts. Enterprise workflows deviate from the script constantly, a document is malformed, an API times out, a customer’s request doesn’t match the expected pattern. A pipeline breaks on that. A loop absorbs it.
The effect on output quality, when it’s engineered well, is not subtle. Andrew Ng highlighted a case where:
“ChatGPT 3.5 was used in an agentic workflow instead of a simple one-shot response, its coding accuracy jumped from 48.1% to 95.1%. AI expert Andrew Ng highlighted this as proof that agentic workflows help AI reason more like humans and act with greater independence.”
Same model. Same underlying capability. The only thing that changed was whether it got to check its own work and try again.
Why is the stopping condition the actual hard part?
Because a loop with no reliable way to know it’s finished doesn’t automate work, it automates confusion. Everyone who’s built one long enough to break it says the same thing.
“Loops rarely fail on the prompting. They fail on the stop condition.”
The reasoning and the acting turn out to be the easy 80%. Knowing when to stop is the hard 20% that decides whether the loop is trustworthy.
The failure mode is specific and recurring: letting the same model that did the work also decide whether the work is good.
“A separate command or checker must decide this. The agent that performed the work should not approve its own result.”
An agent grading its own homework will pass its own homework, almost every time, for reasons that have nothing to do with whether the homework is actually correct.
Good loop design treats the stopping condition as the design’s foundation, not an afterthought bolted on at the end.
“Design the stopping condition first, then design the loop mechanics. Persist project state outside context windows so long loops can resume safely.”
That ordering, condition first, mechanics second, is the single habit that separates a loop from what one researcher memorably called “a very confident token furnace.”
Where does harness engineering fit into all of this?
It’s the layer underneath the loop, and confusing the two is the most common mistake teams make right now. Harness engineering builds the environment a loop operates inside, the tools it can call, the memory it can read, the guardrails it can’t cross.
“Harness Engineering is the discipline of designing the execution environment around an autonomous AI agent. It defines which tools the agent can call, where it gets information, how it validates its own decisions, and when it should stop.”
Databricks draws the distinction plainly for teams trying to sort out which discipline solves which problem.
“What is the difference between harness engineering and prompt engineering? Prompt engineering focuses on crafting better inputs for the model.”
The harness is the world the agent lives in. The loop is the behavior it exhibits inside that world. You need both, and they’re built by different questions: the harness asks what the agent is allowed to do, the loop asks what the agent should do next and how it knows it’s done.
What does this cost you if you get it wrong?
More than most roadmaps account for. The gap between “we built an agent” and “we can run this agent without babysitting it” is where most enterprise AI budgets currently go to die. According to Forrester and Anaconda research, supported by IDC, “roughly 88 percent of AI agent pilots never reach production.”
That number isn’t a model problem. It’s a loop and governance problem. Teams build something that behaves impressively in a demo, where a human is watching every turn and can catch a mistake before it compounds, and then discover it has no way to run unattended, no way to prove what it did, and no way to roll back when it goes sideways.
“In most cases, the cause is not the model. The agent works in the demo. What fails is everything around it. Deployment gets hand built. Approvals happen over chat and email rather than through a defined process. Security is brought in at the end, if at all. There is no clean way to roll back when something breaks, and no shared record of which agents are running or who owns them.”
This is precisely the gap that governance infrastructure like the Lyzr Control Plane is built to close, taking agents built on any framework, LangGraph, CrewAI, or a custom stack, through staged promotion, automated evaluation, and version-tagged rollback before they ever touch live traffic. Loop engineering asks whether an agent knows when it’s done. Enterprise governance asks whether anyone can prove what the agent did in between.
If Boris Cherny’s 259 pull requests over 30 days sound impressive in isolation, remember:
“Claude Code wrote 100% of his code contributions over the past 30 days (259 pull requests), and merges per engineer per day on his team rose by 200%.”
That kind of throughput is only an asset if every one of those merges is traceable, reversible, and accountable. Otherwise it’s just 259 unattended decisions you can’t audit.
When should you still reach for prompt engineering instead?
Use prompt engineering whenever a human is going to read the output before it matters. That covers more ground than the loop-engineering hype suggests. Drafting a first pass of a document, brainstorming options, summarizing a report someone will fact-check, these are one-shot interactions where a well-crafted prompt and a careful human reviewer are still the right, and cheapest, tool. Lyzr’s own guide to prompt engineering covers the techniques that still matter here, from few-shot examples to structured output formatting.
Reach for loop engineering when the task has to run without someone watching every step, when it involves more than one decision point, or when “good enough” needs to be provable rather than just felt. Customer support resolution that spans multiple systems, financial report generation that pulls from five data sources, competitive research that has to keep running as new information appears, these are loop problems, not prompt problems.
The decision test is simple: if a human being unavailable for the next hour would stop the task cold, you need a loop. If a human being unavailable would just mean the task waits, a prompt is still fine.
What should an enterprise AI team actually do with this?
Stop treating your prompt library as the finish line. Audit which of your current AI workflows still require a person to read every output and manually decide the next step, then ask which of those actually need to. Some don’t, they’re one-off tasks dressed up as processes. Others genuinely do need a person there. The rest are loop candidates, and every one of those is currently costing you the manual attention of someone who should be doing something a model can’t.
Start small and verifiable, not broad and impressive. A loop with a clear, checkable goal, like clearing a support queue or reconciling a set of invoices, is easier to trust than a loop with an ambiguous one, like “improve customer satisfaction.”
“The core skill is writing the verifier that decides whether the agent’s output is good enough.”
Build that verifier before you build the loop around it, not after.
And build the governance layer at the same time as the loop, not after something breaks. A loop that can act autonomously without a registry, an audit trail, and a rollback path isn’t autonomous, it’s unaccountable. That’s the distinction that separates the 12% of pilots that reach production from the 88% that don’t. Teams mapping this out for the first time typically need a structured starting point rather than an ad hoc list of tools.
How to Build Your Agentic AI Roadmap in 2026
The same discipline extends beyond a single pilot. Teams responsible for standing up and operating agents across an organization need the loop-plus-governance mindset baked into how they staff and structure the function, not treated as a one-off checklist.
Lyzr for AI and Automation Teams
Frequently asked questions
What is loop engineering?
Loop engineering is the practice of designing systems that repeatedly prompt, evaluate, and redirect an AI agent toward a goal without a human issuing each instruction.
“It’s the practice of designing agentic workflows, or loops, that iteratively guide AI agents toward completing user-defined goals with minimal human intervention. Rather than require human prompting at every step, agent loops enable agents to dynamically act, observe, make decisions and iterate until a task is complete.”
What is the difference between prompt engineering and loop engineering?
Prompt engineering optimizes a single exchange with a model, loop engineering optimizes the entire system that runs many exchanges automatically.
“With prompt engineering, humans craft prompts, evaluate the results and create subsequent prompts at each stage. Loop engineering creates largely automated systems that refine their own internal prompts to achieve optimal results.”
Who coined the term “loop engineering”?
The term was popularized in June 2026 by Google’s Addy Osmani, building directly on public statements from Anthropic’s Boris Cherny and OpenClaw founder Peter Steinberger, all three of whom independently described abandoning manual prompting for designed, autonomous loops around the same time.
“The term was popularized in June 2026 by Addy Osmani (engineering lead at Google Chrome), synthesizing ideas from Boris Cherny at Anthropic and Peter Steinberger (founder of PSPDFKit/Nutrient).”
Is prompt engineering dead in 2026?
No. It’s been absorbed into a larger system rather than eliminated. Reports of prompt engineering’s death are overstated, since the underlying skill of expressing intent clearly still matters, it just now operates as one input inside context, harness, and loop layers rather than as a standalone discipline.
What is a stopping condition, and why is it the hard part of a loop?
A stopping condition is the check that proves a loop’s task is actually finished, rather than just abandoned.
“The key difference is simple: a fixed-timer loop does not know when the work is complete. A conditional loop stops because the work is complete. A separate command or checker must decide this.”
It’s the hard part because a self-graded loop will consistently approve its own unfinished work.
How is loop engineering different from harness engineering?
Harness engineering builds the tools, memory, and constraints an agent operates within, loop engineering designs the repeating behavior that runs inside that environment.
“Tools, knowledge sources, validation logic, architectural constraints, everything that determines whether an agent can run reliably across hundreds of decisions.”
The harness is the world. The loop is what the agent does inside it.
Is loop engineering only for coding agents?
No, though coding agents like Claude Code and OpenAI Codex are where the pattern was first named and documented most publicly.
“Loop engineering is an emerging agentic engineering practice that underpins many AI coding agents such as IBM Bob, Claude Code and OpenAI’s Codex. Loop engineering is better suited to long-running agents handling workflows such as autonomous code generation, software maintenance or multi-step task execution.”
The same pattern applies to any multi-step enterprise workflow, customer support triage, financial reconciliation, competitive research, that runs across more than one decision without a human watching each turn.
The real question isn’t which discipline wins
It’s whether your team is still measuring itself by the quality of a single prompt, or by whether a system you built can be trusted to run without you in the room. Loop engineering vs prompt engineering was never really a competition between two skills. It’s a description of where the responsibility moved, from the sentence you type to the system you’re accountable for.
The teams that treat this as a hiring problem, going out to find “loop engineers,” are going to be disappointed. The skill is the same systems-thinking your best engineers already have, applied to a new layer. What changes is the question they ask before they build anything: not “what should I say to the model,” but “what has to be true for this to run without me, and how will I know if it’s lying to itself about being done.”
That second question is harder. It’s also the one enterprise AI has been avoiding since the first pilot demo got applause and then quietly never shipped.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
