The prompt era is over. Welcome to loop engineering

An Austrian developer let his AI brew beer autonomously for 90 minutes. Another builder typed a single sentence, went to grab a coffee, and returned to three completed pull requests. What they have in common: neither of them was prompting. This is the shift the entire AI world is talking about this summer.

In the second week of June 2026, a single idea rewired how a large swath of the tech world discusses AI. It began with a post by Peter Steinberger — the Austrian behind OpenClaw, the open-source agent project that eclipsed React as the fastest-growing repo on GitHub. He wrote twelve words:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

The post reportedly garnered 6.5 million views in under 24 hours. A few days prior, Boris Cherny, the creator of Claude Code at Anthropic, echoed nearly the exact same sentiment on stage: he no longer prompts Claude himself. Instead, he has loops running that steer Claude and autonomously determine the next steps. His actual job, he noted, is writing loops.

Two statements. Millions of views. And a week of fierce debate on the timeline, primarily because hardly anyone could articulate what a loop actually is.

It is high time to clarify this concept — because beneath the hype lies a fundamental shift that will impact how every business, from solopreneurs to multinationals, operates with AI in the years ahead.

From "write the perfect prompt" to "build the system that prompts"

For two years, the method to extract value from an AI agent was simple: write a good prompt, read the output, type the next one. You were holding the tool — turn by turn. The skill was called prompt engineering: finding the right words to keep the model on track.

Loop engineering flips that script. Your task is no longer writing the prompt that finishes the job. Your task is designing the system that autonomously determines the next prompt, executes it, reads the result, and decides whether to continue — all without a human at the keyboard.

The most resonant analogy: prompt engineering is playing chess — one deliberate move at a time. Loop engineering is building the chess computer. You define the objective, establish the rules, and let the machine play.

It is helpful to recognize that this isn't a sudden leap, but rather the fourth step in a steady outward migration:

1. Prompt engineering (2022–2024) — the art of finding the right words.
2. Context engineering (2025) — everything the model sees at runtime: conversation history, retrieved documents, tool outputs. Shopify CTO Tobi Lütke provided the definition that stuck: ensure the model has all the context necessary to plausibly solve the task at hand.
3. Harness engineering (early 2026) — the entire environment of scaffolding, tools, and feedback loops surrounding a single agent.
4. Loop engineering (June 2026) — the engine that drives the agent. Each layer wraps the previous one without replacing it.

Why now? Because the underlying agents finally became good enough. By mid-2026, agents can run autonomously for long enough — and recover from their own errors well enough — that the bottleneck has shifted. When a single agent run takes an hour and touches dozens of files, the highest leverage point is no longer writing a sharper prompt. It is designing a loop that keeps the agent productive, verified, and on track — even while you sleep.

The grandfather of all loops: a bash script named Ralph

Before anyone called it "loop engineering," there was Ralph. In July 2025, developer Geoffrey Huntley described how he ran a coding agent in a standard while loop: repeatedly execute the same prompt against a written specification, let the agent pick up and execute one task, then spin up a fresh instance and run that exact same prompt again.

In Huntley's own words: "Ralph is a bash loop." Every iteration resets the context to a fixed set of anchor files. Progress lives on disk and in git, rather than in an ever-growing conversation thread. The agent completes one defined unit of work per round, validates it, and stops.

The astonishing detail: Using Ralph, Huntley built an entire programming language for roughly $297 in API costs — a figure that has been endlessly cited in industry circles ever since. It proved that a ridiculously simple system, provided it is well-designed, can deliver genuine, robust output.

Things have gotten a bit more serious since then. In one documented experiment, a single goal-driven loop ran continuously for 25 hours, consumed 13 million tokens, and produced 30,000 lines of code. Furthermore, an open-source project called Gas Town now coordinates 20 to 30 agents simultaneously via a "mayor" agent, featuring patrol agents that run continuous loops and save their state in git so the work can survive a system crash.

The anatomy of a loop: four moves, plus memory

Strip away the jargon, and a loop is essentially four repeating moves:

Discover → plan → execute → verify → (repeat until a condition is met.)

In the past, you were that loop. You stood between the agent's steps: reading the output, catching errors, and deciding what happened next. Loop engineering means stepping out of that inner cycle and leveling up to design the tracks the agent runs on.

According to the now widely accepted framework (by AI leader Addy Osmani), a truly unattended loop relies on five building blocks plus memory:

• Automations — scheduled tasks that trigger on a set rhythm and autonomously discover work. This is the heartbeat: without a schedule, you have a one-off session; with a schedule, the work gets done whether you open your laptop or not.
• Worktrees — isolated working environments ensuring multiple agents don't overwrite each other's work.
• Skills — encapsulated project knowledge, so the agent doesn't start cold and guess every time.
• Connectors (MCP) — the integration with your real-world tools: your issue tracker, your database, Slack.
• Sub-agents — separating the creator from the checker. The model that produced the work is far too lenient to grade its own homework.

And then the sixth, the linchpin: memory. A simple markdown file or a board in your project management tool that exists outside a single conversation. The model forgets everything between runs, so whatever needs to survive must live on disk. The agent forgets; the memory doesn't.

That last rule is more profound than it sounds. The memory file effectively becomes your logbook: when you sit down at the "human checkpoint" in the morning, you aren't reading the full transcript of every run — you are reading the summary of what is finished, what is in progress, and what requires human intervention.

Four patterns that cover 95% of real-world use cases

According to an analysis by Agent Shortlist, virtually all production loops are variants of four core patterns — and most workflows combine two or three of them:

1. The heartbeat. The agent wakes up at a fixed interval (every 5 minutes, every hour, every shift), checks for work, and either acts or goes back to sleep. A classic example: a support agent checking the queue every 10 minutes.
2. The cron. Anchored to time, not to state. Every Friday at 4:00 PM, the weekly analysis runs — whether someone asks for it or not. Its strength lies in predictability.
3. The event-trigger (webhook). The agent reacts to an occurrence: a new ticket lands, an email arrives. Its strength is real-time responsiveness.
4. The goal-loop. The agent is assigned an objective ("create a competitive analysis of the top five players") and keeps trying until its internal success check evaluates to true. Its strength is unbounded dedication to a well-defined goal — but this is also the most expensive and dangerous pattern.

What this delivers in practice — beyond the coding world

Loop engineering originated with programmers, but these patterns are broadly applicable. Here is a selection of workflows that businesses are already running today:

• Event-driven customer service. A ticket comes in, the agent reads it, classifies it, drafts a response, and independently decides whether to send it or escalate to a human.
• Error sweeps on production logs. A typical production environment generates hundreds of log lines daily, mostly harmless. A loop triages them hourly, suppresses false alarms that would otherwise clog up your channels, and only opens tickets with Slack notifications for genuine anomalies.
• Bulk lead qualification. The agent enriches every incoming lead, scores it against your ideal customer profile, writes a brief summary in the CRM, and triggers the appropriate next step — churning through until every lead is handled, even during volume spikes.
• Competitive monitoring. Weekly, a loop checks whether competitors have published new content or updated pricing, delivering a digest the team can read in thirty seconds instead of compiling for three hours.
• Safeguarding data quality. The agent scans records, automatically fixes low-risk issues (formatting, duplications), and escalates high-risk cases accompanied by a suggested fix.

The design principle that resurfaces everywhere: automatically handle the clear-cut cases, escalate the edge cases, and always log what was done.

The "super-individual": what OpenClaw demonstrated

No story about loops is complete without the man who got the ball rolling. Steinberger's own history is a case study in itself. He spent thirteen years building PDF software (PSPDFKit, which he sold in 2021 for over 100 million euros). After a bout of "founder depression," he started tinkering again in 2025 — and in November of that year, he built the prototype for what would become OpenClaw in about an hour.

What lies beneath the hood isn't technically groundbreaking: it simply calls the Claude API, runs on an open-source framework, and operates on standard servers. Yet, in just a few weeks, a single person managed to build something that captured the attention of the CEOs of OpenAI, Meta, and Microsoft (Satya Nadella reportedly called him personally). In February 2026, Steinberger joined OpenAI; OpenClaw remained open source under an independent foundation.

But the most interesting aspect is what ordinary people built with it. At a conference in Vienna, Steinberger met a 60-year-old beer sommelier who had never written a line of code. He connected OpenClaw to his brewing rig via Bluetooth, sent a single prompt — and the agent autonomously ran the entire 90-minute brewing process: temperature curves, hop additions, everything. Afterward, the agent suggested building a website for it, integrated payments, and a real product was born. Another user had his agent call car dealerships to negotiate the best price for a truck. In Shenzhen, people queued up outside the Tencent office to get their "lobster" installed — the city even provides subsidies for it.

This is what commentators began calling the "super-individual": a single person who, armed with well-designed loops, can handle the workload of an entire team.

The flip side: where loops break down

Let's be candid here. Steinberger himself offers the sharpest warning. Developers easily fall into the trap of the illusion of productivity — feeling like you're making rapid progress while the project itself stagnates. "Without vision and without knowing what you are building, you just produce garbage," he said. With AI, you can now "build anything," but ideas and taste are the real differentiators. Eventually, he had to force himself to stop coding along continuously — not because it wasn't useful, but because it was so incredibly useful that it became addictive.

Furthermore, three specific problems become more acute — not easier to manage — as the loop improves:

The verifier is the real bottleneck — not the model. A poignant observation from the June debates was that designing a loop is only half the battle; the other half is implementing something inside that loop capable of saying no — a test, a type check, a hard error. A loop without opposing friction is just an agent trapped in an echo chamber of self-approval. That is why you must separate the creator from the checker, and provide the goal-loop with a condition that the agent can empirically verify.

Your understanding evaporates if you let it. The faster the loop delivers outputs you didn't create yourself, the wider the gap becomes between what exists and what you genuinely comprehend. A frictionless loop accelerates the growth of that knowledge gap.

Complacency is inherently dangerous. Once the loop runs autonomously, it is deeply tempting to check out and blindly accept whatever it produces. The very act of designing the loop is the cure if executed with critical judgment, but it becomes a fast-track to disaster if used as an excuse to stop thinking.

Then there is the matter of cost. A scheduled loop with a verifier checking every turn burns through tokens rapidly; agents easily consume a multiple of what a standard chat session would, and multi-agent setups compound this further. Consequently, the primary failure mode of loop engineering is runaway costs. Here are four safeguards that belong in every production loop:

• An iteration cap (e.g., maximum 50 cycles). Goal loops do not stop on their own.
• A daily budget cap on tokens per workflow per day.
• A success condition the agent can evaluate independently.
• A rate limit — a webhook storm flooding you with ten thousand events in a minute can trigger ten thousand agent runs and deplete your budget within an hour.

Two people, same loop, opposite results

The sharpest observation from all the literature we reviewed: two people can build the exact same loop and achieve entirely opposite outcomes.

One uses it to accelerate work they understand deeply. The other utilizes it precisely to avoid doing the work to understand it. The loop doesn't know the difference. But you do.

That dynamic is exactly what makes loop design harder than prompt engineering, not easier. Cherny's point was never that the workload decreased. His point was that the point of maximum leverage has shifted.

How do you start?

For those looking to dive in, here are three pragmatic lessons from the trenches:

1. Start narrow. Pick a single, recurring, well-understood process — not your most intricate one. Build one loop around it, get it working smoothly, and only scale up from there. Trying to automate everything at once is the fastest route to a system that quietly leaks on all fronts.
2. Build the friction first. A loop without a verifier is simply an agent nodding along to its own output. Define what "good" and "done" look like before you begin, and determine exactly who or what will rigorously test that.
3. Keep humans in the loop where it matters. Not merely as an emergency net for when the agent falls short, but as a deliberate architectural choice: the AI manages whatever is logically deducible; the human handles whatever necessitates authority, context, or accountability — alongside any action that is irreversible.

The era of the standalone prompt isn't over by any means; prompting remains a highly valuable skill. However, the center of gravity is indisputably shifting, and the fundamental building blocks are now readily available to everyone — from the solopreneur with a brewing kettle to the enterprise managing a hundred operations.

Build the loop. But build it as someone intent on remaining the engineer, not just the person hitting start.

// About the author

Remy Gieling

Mede-oprichter, AI-expert & bestseller-auteur

Tech-expert (1988) gespecialiseerd in kunstmatige intelligentie en mede-oprichter van ai.nl, The Automation Group, Proxies en eBrain.ai. Oud-hoofdredacteur van diverse zakenmerken en daardoor een geoefend verteller op het podium en in de media. Verzorgt jaarlijks 150+ AI-keynotes in binnen- en buitenland en is gastdocent aan Nyenrode. Co-auteur van zeven boeken, waaronder 'Handboek AI Strategie' en 'AI Agents', en bekend als presentator op radio en RTL Z. Reist langs de labs van OpenAI, Nvidia en Tencent en vertaalt de nieuwste doorbraken naar inzichten die leiders direct kunnen toepassen.

LinkedIn