Stop Prompting. Design Loops: The Next Lesson of the Agent Era

The most-pinned agent tweet of the last few weeks is not a new model launch, and it is not a benchmark record.

It is plain, but the more you chew on it, the more it sticks:

“Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
— @steipete

The author is Peter Steinberger, the creator of OpenClaw and one of the most active builders in the agent toolchain. He pins it on a monthly cadence.

The reason this line broke out this June is not that he is loud. It is that the timing is unusually clean. Almost the same week, Boris Cherny, the creator of Claude Code at Anthropic, said almost the same thing on the Acquired Unplugged stage:

“A year ago I was writing code with autocomplete. Then I was running five or ten Claudes in parallel, and my ‘coding’ was prompting each one. Now? I don’t prompt Claude anymore. I have loops that are running.”

Boris is not a keyboard warrior. He is the person who actually built Claude Code. If even he has personally moved his own workflow from “prompting” to “looping,” that single fact is loaded with information.

So this June, a quiet consensus is forming inside the builder circle: the era of easy prompt leverage is closing, and the next dividing line is loop engineering.

Why prompting is no longer enough

When many people first hear the word “loop,” their first reaction is: isn’t that just firing the same prompt a few times?

It is not.

A real loop has at least three moving parts:

1. State. Persist “where I am right now” so the agent does not lose context.
2. Verification. Let another agent, or a hard piece of logic, judge whether the step is truly done.
3. Feedback routing. Use the verification signal to drive the next action, or to stop, roll back, or escalate to a human.

Boris himself writes this very plainly in How Boris Uses Claude Code:

For very long-running tasks, I will either prompt Claude to verify its work with a background agent when it’s done, use an agent-Stop hook to do that more deterministically, or use the ralph-wiggum plugin.

Three techniques, one underlying mechanism: let the agent verify itself, and let the verification decide whether to continue.

That is the real difference between a loop and a prompt.

A prompt is a single trigger. A loop is a triggered-and-then-judged cycle.

When you only send one prompt, the model can only answer based on the context it sees in that one moment. It does not know if its previous answer was right. It does not know what you asked earlier. It does not know whether you will change your mind later.

Once a loop is running, the model “sees” its own last few outputs, the test results, and the user feedback. It then uses that “seeing” to correct its next move.

This matters because almost no real task can be finished in one round. A simple-sounding “fix this bug” usually means reading the code, writing a reproduction, running tests, inspecting the diff, renaming things, and re-running. That is at least seven steps.

If you have to hand-write a prompt for every one of those steps, you are not the conductor of the agent. You are its project manager.

To put it bluntly: single-round prompts are good for demos. Loops are good for real delivery.

Loops are being productized right now

The most interesting part is that the reason steipete’s pinned tweet broke out at 13.7k likes was not that the idea was brand new. It was that he gave a name to something a lot of people were already doing.

Glance at GitHub trends and the Follow Builders feed for the last two weeks and you can piece the whole loop-engineering movement together:

• steipete/CodeLooper is his own demo repo. The README opens with “It’s all about the loop, baby.”
• steipete/agent-scripts (3.1k stars) already ships a codex-review loop skill: upload a diff or paste a PR link, the review-fix-rerun cycle runs in the browser, and it proudly advertises “no Codex CLI install, no API key.”
• anthropics/claude-code ships an official ralph-wiggum plugin in its marketplace. Run /ralph-loop "your task" --max-iterations N --completion-promise TEXT once, and Claude writes code, runs tests, gets stopped by a Stop hook, and re-feeds the same prompt to itself until the completion-promise text appears. Always set --max-iterations, or it loops until you kill it.
• Addy Osmani (the Google Chrome team lead and author of Learning JavaScript Design Patterns) published a piece on Substack on June 8 called “Loop Engineering,” opening with “Loop engineering sits one floor above the harness engineering” — promoting loop to peer status with the harness.
• Oscar Gallego Ruiz published on Medium almost the same day, “Stop Prompting Your Agent. Start Writing Loops.,” carving the prompt era and the loop era apart.

Look at the pattern. This is not one person’s bright idea. It is a circle of builders independently arriving at the same conclusion.

And note carefully: none of these are papers or slide decks. They are all running code.

The counter-argument: is prompting really done?

Of course there is a counter.

The most interesting counter is a Reddit post on r/PromptEngineering that hit 60k views: “After 1000 hours of prompt engineering, I found the 6 patterns that actually matter.” The author, a tech lead, distills the lessons into a “KERNEL” framework:

• Keep it simple
• Easy to verify
• Reproducible
• Narrow scope
• Explicit constraints
• Logical structure

He posts clean numbers: first-try success 72% → 94%, token usage -58%, accuracy +340%.

In theory, that is the strongest possible case for prompt engineering. It should be the direct rebuttal to “stop prompting.”

But read it carefully. Every single KERNEL principle is about solving “how does the agent know this round is done?”

See what happened?

KERNEL is not a counter-argument. It is quietly describing the parts of a loop, in the vocabulary of prompt engineering.

That is why I think steipete’s framing is genuinely sharp. He is not saying “prompt is useless.” He is saying “prompt should be absorbed into a loop, as a substructure of it.”

Write your prompt well, make it easy to verify, make its effects reproducible — congratulations, you have just hand-built a loop.

All steipete is doing is automating, versioning, and executing that exact thing.

The real bottleneck of loops is never the technology

Most builders nod at this point and say “yeah, makes sense.”

Then they get stuck on the same thing: there is nothing to loop over.

A real workflow needs clear actions to cycle through:

• modify code → run tests → inspect diff → rename → run tests again
• research a project → fetch README → fetch dependency graph → fetch changelog → write report
• process a ticket list → read issue → write patch → run CI → leave a comment

But if your work is “think of an idea → write a piece → revise twice → ship,” the loop is hard to automate, because “think of an idea” has no clear verifier.

So the real threshold of loop engineering is not “I can write a YAML config” or “I can install the ralph-wiggum plugin.” It is:

1. Can you break your work into steps that an external system can verify?
2. Does each step have a clear pass/fail signal?
3. On failure, does the next step roll back, retry, or escalate to a human?

In his 13-step setup post, Boris Cherny keeps repeating one thing: he himself uses “Plan mode” to grind out an “acceptable plan” with Claude before letting the loop actually execute.

In other words, a loop does not start running on day one. The first 30% of the loop’s life is spent by the human in the loop, clarifying what “verifiable success” actually means.

This is also why I think this topic is more worth tracking long-term than “the model got 5% better.”

No matter how strong the model is, given a task where even the human does not know what they want, the model can only output something pretty and useless. Whether a loop is strong or weak depends, in the end, on whether the owner can translate “what I want” into “what can be accepted.”

Is loop engineering an upgrade of prompt engineering?

I lean toward: yes, but also no.

Yes, because:

• It embeds single-round prompts into a larger structure that has state, verification, and stop conditions.
• It turns “crafting a beautiful prompt” into “designing a re-runnable process.”
• It inherits prompt engineering’s full legacy — constraints, context, examples — but turns it from an art into an engineering discipline.

No, because:

• The bottleneck of a loop is process design, not wording.
• Once a loop is built, any agent model that can plug into the loop entry point can run it.
• A loop’s value compounds over time; today’s stop condition is tomorrow’s reusable asset for the next project.

And that last point implies something many people have not internalized: the loop you design today becomes team property tomorrow.

The beautiful prompt you spent an afternoon crafting may depreciate after the next model upgrade.

That is why I prefer to see loops as a form of organizational memory, not a technical trick.

A practical test for normal people

If you are just a ChatGPT user who writes emails and edits text, loop engineering is not your problem yet.

But if you are any of the following, start thinking about it seriously:

• you write code, and bugs often take several rounds to nail down
• you do research, and the number of sources you need to check makes you flinch the moment you open your laptop
• you produce content, and you go from raw material to finished draft in many passes
• you maintain a process, and you repeat roughly the same work every week

In all of these scenarios, prompts will increasingly feel like one-off glue, while loops will increasingly feel like a reusable workbench.

The most direct first step: next time you hand an agent a multi-step task, first ask yourself “how will I know this step is actually done?” If you cannot answer that, what you are missing is not a better prompt, but a runnable loop.

One last thought

Prompt engineering is not going to disappear. It will slowly retreat from the front of the stage and become a component inside the loop.

My current read on how this evolves is very simple:

Over the next six months, the gap between coding agents will not be in how pretty their prompts are. It will be in how solid their loops are.

If you are still spending time today on crafting “the one killer prompt,” I would suggest you carve out some time to think about “the loop that can be re-run, that can verify itself, that can stop and look back.”

That single shift may be worth more than the next model upgrade.

References

1. Peter Steinberger on X, “Stop prompting. Design loops.”: https://x.com/steipete/status/2063697162748260627
2. How Boris Uses Claude Code, Boris Cherny’s long-running workflow: https://howborisusesclaudecode.com/
3. Acquired Unplugged, Boris Cherny “I have loops that are running”: https://www.acquired.fm/
4. GitHub, steipete/CodeLooper: https://github.com/steipete/CodeLooper
5. GitHub, steipete/agent-scripts (codex-review loop skill): https://github.com/steipete/agent-scripts
6. GitHub, anthropics/claude-code ralph-wiggum plugin: https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum
7. Addy Osmani on Substack, “Loop Engineering”: https://addyo.substack.com/p/loop-engineering
8. Oscar Gallego Ruiz on Medium, “Stop Prompting Your Agent. Start Writing Loops.”: https://medium.com/@garbarok/stop-prompting-your-agent-start-writing-loops-73608223f075
9. r/PromptEngineering, “After 1000 hours of prompt engineering, I found the 6 patterns that actually matter”: https://www.reddit.com/r/PromptEngineering/comments/1nvehmh/after_1000_hours_of_prompt_engineering_i_found_the_6/