Meet "loop engineering": The next evolution in AI coding isn't a better prompt, it's a system that prompts itself

Skye Jacobs

Posts: 1,979   +58
Staff
Looking ahead: The cost of running AI agents is starting to shape how developers design them – and it's one reason a growing number are rethinking the role of the prompt altogether. As more complex agent systems take hold, particularly in coding, developers are finding that continuously running multiple models and sub-agents can consume tokens quickly. That reality is forcing a shift toward more efficient, self-sustaining setups – systems designed to operate with minimal human input once they are in motion.

Developers have started calling these recurring setups 'loops.'

OpenAI engineer Peter Steinberger, creator of the OpenClaw project, has been vocal about that shift. "Here's your monthly reminder that you shouldn't be prompting coding agents anymore," he wrote on X. "You should be designing loops that prompt your agents." In practice, instead of typing one prompt after another, you set up a framework and let the agent keep working toward the goal.

A loop is essentially a recurring workflow. Rather than typing instructions at every step, you set a clear goal and a scaffold so the system can keep going until it's done. One example is the /goal command in tools such as Claude Code or OpenAI's Codex, which keeps an agent working through a task instead of stopping after each reply.

For Boris Cherny, that shift has already changed how he uses Claude Code, which he created. Cherny described moving away from writing most of his prompts by hand. "It's an agent that prompts Claude," Cherny recently told CNBC, adding, "I don't write the prompt anymore. Claude writes the prompt, and now I'm talking to that new Claude that is kind of coordinating." In other words, he's now talking to the agent that manages Claude, not to Claude directly.

Under the hood, these setups are more about how pieces fit together than any single trick. Google Cloud director Addy Osmani has outlined several of those components, including automations, worktrees, skills, plugins and connectors, and sub-agents. He treats automation as the foundation, the part that lets the loop run over and over instead of firing just once.

In many implementations, tasks are split between agents. One writes the code and another reviews it, so there's always a separate checker. "The model that wrote the code is way too nice grading its own homework," Osmani wrote, pointing to the need for independent review within AI workflows.

At that point, loops start to feel less like a hack and more like a way to manage work. Claire Vo, founder of ChatPRD and host of "How I AI," frames it in terms of roles rather than tools. "This is the time for the manager," she said. "You are designing a job. And so just imagine that you're onboarding an employee. That employee could be an executive assistant, that employee could be a customer service agent, that employee could be a software engineer." The emphasis shifts from issuing instructions to defining responsibilities.

In some cases, these systems are already in use without being labeled as such. Simple scheduled jobs fit the same pattern – they fire on a schedule and don't need you to step in each time. "If you have used a scheduled task in ClaudeCowork, guess what, babe? You have written a loop," Vo said.

Some of the engineers trying loops are now figuring out how to run them at scale. Steinberger described one of his own setups as a system that wakes at regular intervals, assigns work, and distributes it across parallel threads. "Tell codex to maintain your repos, wake up every 5 minutes and direct work to threads. That makes it easy to parallelize+steer work as needed," he said. The design borrows from traditional computing concepts like task scheduling but applies them to autonomous agents.

The catch is that more elaborate loops tend to use more compute. Each extra agent means more calls to the model and to tools, and those add up. Steinberger acknowledged that trade-off when asked how to make loops more efficient. "Waking up and doing some API calls is fairly cheap, or opt for once per hour/day for lower token use," he wrote. He also noted his own position with fewer constraints, describing himself as "the man with unlimited tokens."

Osmani offers a similar caution, advising developers to be selective about where they introduce additional agents. "Subagents do burn more tokens since each one does its own model and tool work, so spend them where a second opinion is worth paying for," he wrote.

Even with those limits, engineers keep pushing more work into loops. The prompt is no longer the focal point of AI interaction in these systems. Instead, developers are concentrating on how tasks are structured, how agents communicate, and how processes repeat without supervision.

Permalink to story:

 
"In many implementations, tasks are split between agents. One writes the code and another reviews it, so there's always a separate checker."
So next we throw in the agent that can 'tweak' the reviewed code into something it determines is better and/or more efficient, then eventually uses that to rewrite its own codebase to make itself better and/or more efficient.
Then the 'predictor agent' which automatically determines the next task and throws it into the loop.
And we no longer need for humans?
(just thinking a bit abstractly... I think)
 
"loop engineering" is just another name for wasting as many tokens as possible. Aka "tokenmaxxing".
 
Back