Prompt engineering is dead. The hottest term in Silicon Valley in 2026 is loop engineering — not you prompting the AI, but designing a system where the AI prompts itself. And no, this is not another concept bubble.
In the second week of June, one idea reorganized how an entire generation of developers talks about AI. It started as an X post that crossed 6.5 million views in six days. Google’s Addy Osmani gave it its name. And Anthropic’s Boris Cherny compressed its weight into one sentence: “I don’t prompt Claude anymore.” Pressed at the @Scale conference two months earlier on whether loops were the next hype cycle, Cherny didn’t hesitate: “It’s real. Two years ago we hand-wrote code. Then we moved to having agents write code. Now we’re transitioning to agents prompting agents, which then write code. The loop step is as big as the step from source code to agents.”
This is not an overreaction. It is a quiet career restructuring.
From Holding the Tool to Standing Outside the Loop
The evolution from 2023 to 2026 fits in one table, and every row is an abstraction level that devalues the skill before it. In 2023, you wrote the code — you were the executor. In 2024, you prompted AI to write it — the operator. In 2025, you wrote loops that let AI prompt AI — the manager. In 2026, you build systems where the loops run themselves — the system designer. Each promotion retired the previous stage’s core skill from competitive advantage to infrastructure-level default. Writing a good prompt was scarce in 2024; orchestrating parallel agents was scarce in 2025; by 2026 both are entry tickets.
Cherny’s one-liner is not rhetorical flourish. He has repeated the substance across venues: since 2026 he has not hand-written a line of code; he merges dozens of pull requests daily from his phone; and 100 percent of Claude Code’s own codebase is written by Claude. Anthropic now merges over 80 percent AI-generated code internally; Google’s contemporaneous figure is about 75 percent. His daily workflow: wake up, open Claude Code on the phone, type a short goal — “optimize the payment module’s error handling” — and the model reads the codebase, decomposes tasks, writes, tests, and files the PR. He reviews. Sometimes another loop does the reviewing. When you read those numbers, ask the follow-up: who writes the remaining 20 percent of human code? People like Cherny — the ones who built Claude Code. And they have stopped too.
Loops Aren’t New — Old Knowledge, Reinvented
Strip the packaging and an agent loop is four moves on repeat: discover, plan, execute, verify — repeat until a condition holds. You used to be the loop. You stood between every step of the agent, read the output, spotted the error, decided the next action, told it to retry. Loop engineering’s core move is extracting yourself from that inner cycle and stepping back one level to design the track the agent runs on. Any CS undergraduate recognizes the pattern — recursion plus a termination condition. What is genuinely new is that the loop’s judgment logic became non-deterministic: the stop condition is no longer a hardcoded i < 100 but a subagent’s own judgment of “is this done?”
Loop engineering also did not appear from nowhere. It is the fourth layer of a four-year stack-up. Prompt engineering (2022-2024) optimized every word you wrote — roles, steps, examples — with a hard ceiling: no prompt conjures facts the model never received. Context engineering (2025) shifted attention from how you say it to what you show it — conversation history, retrieved documents, tool outputs, agent state; Karpathy called it “the delicate art of filling the context window,” and prompts became a subset of context. Harness engineering (early 2026) arrived when agents started autonomous multi-step production work and needed an environment — toolsets, constraints, feedback channels, permission controls. Loop engineering (mid-2026) isolates the part of the harness that actually generates autonomy: the iteration cycle itself. Where the harness asks “what environment does the agent need,” the loop asks “what cycle drives it toward the goal, and when does it stop.” These are not four waves replacing each other; they are nested concerns. You still write prompts, still manage context, still build harnesses. Loop engineering bolts an engine onto all of them.
The Verification Loop Is the Actual Scarcity
Every loop has two halves: a generator that produces work and a verifier that judges whether the work is acceptable. For two years the industry obsessed over generators — tuning prompts, swapping models, arguing about temperature. But inside a loop, the generator runs repeatedly at nearly zero marginal cost. What determines whether all that motion creates value is the verifier. A loop with a weak verifier does not fail loudly. It fails productively — efficiently, confidently, churning out garbage hundreds of times while you watch. Which yields the sentence nearly every loop-engineering tutorial skips: the bottleneck is not the model. It is the verifier.
By June 2026, the most popular loop pattern was a simple structure called the Ralph Loop (named for Ralph Wiggum of The Simpsons). The logic: after every iteration, summarize completed work and ask “is the goal met?” — until the answer is yes. Its variants split by openness into two families. Closed loops fix the success criteria before the loop starts — “make the test suite green” — with every step verifiable and convergence guaranteed; safe, predictable, cheap, and incapable of surprising you beyond the assigned task. Open loops hand over a goal and loose constraints — “optimize this app” — where output can be genuinely stunning or quietly degrade into a very expensive nonsense machine. Engineered loops mix both: hard checks as the floor, one open instruction as the ceiling — “and if everything passes, surprise me.”
What a real loop system looks like in production is worth dissecting. AI Jason, a practitioner running loops company-wide, needs only the simplest primitive: a support loop. Every thirty minutes a cron wakes the agent, pulls all support tickets, answers what it can, and logs friction points and product ideas into a shared folder called signals. Then loops stack: the same loop, on discovering a bug, spawns a coding agent to fix it, monitors whether the fix worked, and retries if users hit the same problem again — a symptom, not a cure. He runs five or six loops at once: support every thirty minutes producing signals and engineer tasks; SEO daily at 9am producing pages and conversion-gap signals; product growth on a daily schedule producing task lists; Reddit operations on fixed times producing comment drafts. The critical design: they share one filesystem. The SEO loop’s signal “this keyword converts but has no content” feeds the content loop directly; the support loop’s repeat-bug signals get picked up by the product loop. The shared brain compounds — Jason’s output runs twenty to forty quality pages a day without supervision.
Verification Is an Organizational Problem, Not a Technical One
In a world where loops run overnight, the signals an agent uses to verify itself are not vibes — they are test suites, type checks, lint rules, and runtime errors. Those signals must be good enough to substitute for you sitting there watching. Which forces a brutal corollary: your codebase’s quality now determines your agent output’s quality. Low test coverage, tangled architecture, and missing documentation make agents lose the plot faster, because they cannot even find the definition of “correct.” Conversely, a project with good tests, clean module boundaries, and precise lint rules — agent-ready, in practitioner parlance — lets loops produce stably with no human in the seat. This is not about how strong your agent is. It is about whether your organization deserves one.
Which produces the most counterintuitive conclusion in this whole discussion: loop engineering does not make engineers less important. It makes taste a hard skill. When the model owns “writing,” the engineer’s scarcest outputs become: writing good verification conditions — defining what “correct” means, since a verifier with 90 percent precision caps output quality at 90 percent; designing verifiable systems — module boundaries clean enough that an agent can safely modify one without detonating the rest; judging when to intervene — which tasks a loop can run unsupervised and which demand human eyes; and iterating the verifier — because when a loop finishes and the result disappoints, the problem usually is not the agent, it is your verifier’s definition. This converges on what management used to file under soft skills: judgment. In the loop era, judgment is the only job a loop cannot do.
One honest caveat: the loop’s shadow is denominated in money. Letting agents iterate burns tokens fast; five loops running in parallel, feeding each other signals, optimizing the codebase — burns faster. TechCrunch’s coverage said it plainly: if this sounds expensive, it is. Noam Brown’s observation that problem-solving capability scales with test-time compute describes an “unlimited supply” model whose premise is that you can pay. Amazon, Google, and Anthropic don’t sweat token costs — they sell tokens. A fifty-person company running loops overnight is racking up four-figure API bills. The near-term future therefore forks: big companies run loops as fully automated continuous optimization; smaller companies run them on precise, bounded tasks — until token prices fall further.
You Are Not Alone in the Loop
Loop engineering is a turning point — not because the technique is new (loops in computer science are older than most of its readers), but because its popularization marks a boundary crossing: you no longer talk to the AI, you are not its interface, you are no longer the intermediary between it and the code. You have stepped outside, designing systems from beyond the loop. For practitioners in 2026 this means four things. Engineers: stop worrying about whether AI replaces you; start worrying whether your taste has earned the right to design loops. Writing verification conditions is harder than writing code — and it is your new core value. Engineering managers: stop asking how many people AI can replace; ask whether your codebase deserves to have loops run on it. Test coverage, documentation completeness, architectural clarity — these used to be called technical debt; they are now the automation tax. If you’re deciding whether to invest: start from one small, precise closed loop — “run the test suite at 3am, fix failures, file a PR” — not a super-loop that does everything. Loops are an engineering problem, not a model-size problem; your architecture skills set how far yours runs. If you’re worried about your skills: the scarcest ability today is not writing prompts, tuning models, or curating data. It is judgment — when to loop, when a human steps in, and how good “good enough” is. Your verification loop is your moat.
Sources: Addy Osmani, “Loop Engineering” (2026); Boris Cherny interviews at @Scale, Sequoia AI Ascent, and The Pragmatic Engineer; AI Builder Club, “Loop Engineering Guide” (2026); TechCrunch, “The AI world is getting loopy” (June 22, 2026); Tosea.ai, “What Is Loop Engineering? A Complete Guide” (2026).
