In June 2026, the engineer who built Claude Code casually detonated a small career crisis. "I don't write the prompt anymore," Boris Cherny said. Within days, a viral post and a widely read essay turned that one line into a professional obituary. Prompt engineering was dead. Loop engineering had killed it.
Somebody should tell that to the man who actually coined the term "loop engineering." Google's director of Google Cloud Addy Osmani looked at the same shift and reached the opposite conclusion: prompting didn't get easier, and it didn't disappear. "The leverage point moved". That's not a death notice. That's a promotion.
First, What a Loop Actually Is
A prompt is a single instruction, executed once. You ask, the model answers, you're done. A loop is a system you build once that keeps prompting, checking, and adjusting on its own — without you typing anything in between — until a defined outcome is reached or a limit is hit. The AI isn't just answering your question anymore. It's asking itself the next question, checking its own answer, and deciding whether to keep going.
That's the entire shift in one sentence: from a single exchange to a running process. Everything else in this article is detail on top of that idea.
The Skill Isn't Dead. It Moved.
Loop engineering doesn't replace prompt engineering — it sits on top of it. You still need the skill of asking clearly for what you want. You just need it embedded inside a system that asks a hundred times a day without you.
That distinction determines where your training budget goes this quarter. Read "prompt engineering is dead," pull funding from prompt literacy, and chase a vague new discipline nobody's actually defined for your industry — that's not modernization. That's whiplash wearing a strategy memo.
Think Thermostat, Not Driver
Think of a loop like a thermostat, not a driver.
A thermostat doesn't get told "turn on the heat" every ten minutes by a human. It's given one outcome — "keep the room at 22 degrees" — and it checks the temperature, decides whether to act, acts, checks again, and keeps doing that indefinitely without anyone touching it. Nobody eliminated the instruction. The instruction just moved from "turn on the heat" (repeated forever, by a person) to "maintain 22 degrees" (stated once, then executed by a system that checks its own work).
That's the actual shift. You stop giving repeated commands and start defining a target state plus a way to verify it's been reached.
The skill isn't gone. It's been compressed into fewer, better-designed instructions that a system then repeats on your behalf.
What a Loop Looks Like at Your Desk
Picture this through a workflow every insurance and financial services leader in the room will recognize instantly: processing a new policy application.
- Automation — a new application lands in the system; nothing waits for a human to notice it
- Worktree — that application is worked in its own contained lane, so it can't get tangled with three other cases running at the same time
- Skill — a codified underwriting checklist the system applies consistently, instead of relearning the rules each time
- Connector — the system's actual access: pulling credit data, running AML/KYC checks, checking affordability thresholds
- Sub-agent — the maker and checker process: one agent drafts the underwriting decision; a second, independent agent reviews it against policy — nothing grades its own homework
Wire those five together with a memory layer that retains context across the case, and you have a loop: application arrives, gets triaged, runs through KYC and affordability checks, gets a draft decision, gets independently verified, and only then reaches a human for final sign-off — or doesn't need to. That's not hypothetical. That's the exact shape of work insurance back-offices already run manually, now with the checking built in from the start rather than bolted on at audit time.
Two Rivals, One Playbook
Claude Code's "/goal" command lets you name an outcome instead of an instruction, and the system runs, checks, and iterates until a verifiable stop condition is met, with a different model doing the checking. But this isn't a one-vendor story. OpenAI shipped the equivalent in Codex just weeks earlier — its own "/goal" mode, released April 2026, lets a developer define a milestone and walk away for hours while the agent plans, acts, and verifies on its own. One demonstration ran unattended for over eleven hours.
That convergence across two competing labs, within the same month, is the actual signal worth paying attention to — more than either single feature. The industry is quietly agreeing on a new default: specify the outcome, not the instruction. That's a bigger implication than any one product update. It suggests the next competitive skill isn't "who writes the best prompt" but "who defines the clearest, most verifiable outcome" — a skill much closer to how good managers already delegate to good people, and far more transferable to a boardroom than any prompt-writing workshop.
The Old Problem Wearing a New Name
Here's where the excitement gets ahead of the reality. Loops don't remove risk — they relocate it, and they make it faster at compounding.
Osmani names two failure modes that get worse as loops improve: "comprehension debt" and "cognitive surrender". But strip away the AI framing and these aren't new problems at all — they're old organizational failures wearing new clothes.
Comprehension debt is what happens in any company that piles on too many management layers: the top loses visibility into what's actually happening at the bottom, not because information moves too fast, but because too many intermediary layers filter and distort it before it arrives. The fix in the human world has always been the same — flatten the structure, reduce the layers, keep visibility direct. The same discipline applies to a loop: the more sub-agents and hand-offs you stack, the more you need direct, unfiltered checkpoints back to a human, not fewer.
Cognitive surrender is even more familiar. It's what happens whenever an organization mistakes process for outcome — when "we followed the procedure" quietly replaces "we got the right result" as the definition of success. Loops make this failure mode faster and quieter, because a system that's been right for three months looks like a system you can stop questioning. It isn't. It's a system nobody has audited in three months.
Match the Spend to the Stage
The move isn't "adopt loops now" or "keep training everyone on prompts." It's matching investment to where the organization actually stands.
| Maturity stage | Where to invest | Why it fits |
|---|---|---|
| Early adoption | Prompt fluency, use-case discovery | No repeatable workflow exists yet worth looping |
| Intermediate | Small, narrow, closed loops | Mirrors the "/goal" pattern — a testable stop condition, not open-ended autonomy |
| Advanced | Maker/checker architectures with real governance | Matches what regulated work like underwriting actually demands |
The build sequence is almost anticlimactic: do the task manually first so you know what "good" looks like, turn it into a reusable procedure, add a trigger, then add independent verification — never let one agent grade its own work. Mind the economics too: a second opinion costs real compute, so spend it on decisions actually worth a second opinion, not on every trivial step in the chain.
Howard
The Network Is Only as Good as One Loop
The unit of AI work keeps getting bigger. Yesterday it was a single instruction. Today it's a loop that checks its own work. Tomorrow it's almost certainly a network of loops — orchestration layers coordinating whole fleets of agents, each running its own maker/checker cycle.
But here's the part worth sitting with: that future only works if the individual loops you build today are actually well-built. A network of loops is only as reliable as its weakest single loop, the same way an orchestra is only as good as its weakest section. Get one narrow, well-verified loop right now — one underwriting check, one claims triage step — and you've built the foundation the entire future network will stand on. Get it wrong, and you've just automated a mistake at scale, faster than any human ever could.
The real question was never whether prompting would survive. It's whether your organization builds one loop well enough today to trust a hundred of them tomorrow — or finds out the hard way, mid-quarter, when nobody was watching the checker.
