Forget Prompt Engineering: 'Loop Engineering' Is All the Rage Now
7 90An anonymous reader quotes a report from Business Insider: For the most powerful voices in AI, it's all about being in the loop. Claude Code creator Boris Cherny recently said he doesn't write his own AI prompts much anymore. Thanks to loops, he doesn't have to. "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 the same interview, Cherny said that loops and a similar feature were examples of the kind of work he would be proudest of in a decade.
Cherny isn't the only one embracing "loop engineering." OpenAI engineer Peter Steinberger, the creator of the viral OpenClaw project, wrote a public reminder to users who are still writing out prompts for AI agents. "Here's your monthly reminder that you shouldn't be prompting coding agents anymore," Steinberger wrote recently on X. "You should be designing loops that prompt your agents." [...] Steinberger shared an example of a loop he uses: "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." Claire Vo, founder of ChatPRD and host of the "How I AI," said, "it's really just reminding people that you don't have to use your human fingers to type in a prompt in order for your agent to do work on your behalf."
The days of directly prompting generative AI coding tools are "kind of over, or at least some think it's going to be," Addy Osmani, director of Google Cloud, wrote in his post explaining the concept.
7 comments
To quote the Bobs (Score: 5, Funny)
by drh1138 ( 6194498 ) on Saturday June 27, 2026 @11:40AM (#66212926)
So what exactly would you say you *do* here?
Re: Questions (Score: 5, Informative)
by ToasterMonkey ( 467067 ) on Saturday June 27, 2026 @03:56PM (#66213194)
Yah, that was the GP's problem though, the parent is right, if you let one session get too long the context goes off the rails. You're better off curating some .md files, like a README, skill files, etc and being able to start a new session for each task. You could end up paying more tokens for repetitive discovery in each task but you can improve that various ways, like indexing your code, knowledge graphs etc, same stuff YOU would do to make searching a large alien code base more efficient.
That's all best practice _already_, and it's obviously required to drive the process with some control loop too, but you guys acting like this means appending to a single context continuously are so lost. This "loop engineering" (no judgement) is just an automated control loop on top of an already reentrant process.
Re:Questions (Score: 5, Interesting)
by Anonymous Coward ( None ) on Saturday June 27, 2026 @12:00PM (#66212956)
These are people who are in the employ of companies like OpenAI and Anthropic. They're literally being paid to encourage people to use AI in the most wasteful, token-burning way possible. Until hard data comes out, one should take anything said by these people with a huge grain of salt and listen to the people who actually have to spend tokens thoughtfully because of budgets.
Re:Questions (Score: 5, Interesting)
by CAIMLAS ( 41445 ) on Saturday June 27, 2026 @08:19PM (#66213504)
Yep. The fundamental problem that requires loops is that opus et al are lazy AF. They do not "implement the plan, make no mistakes". They'll do a subset of {A..M} phases in a plan (90% of A, 70% B, 30% L, 0% M, etc.) and then say "all done!" when it compiles. So, you've got to loop it "do this until it's done". It's fundamentally brute forcing the problem, because the models aren't designed for completeness, just complete-enough, and then lies to you.
The harness exacerbates the problem. People have implemented some privately which do this correctly, but aside from the one I just made available on gh, I'm not aware of any that are public which do so natively/by core design. (And even then, it's sometimes iffy...)
Re:Questions (Score: 5, Interesting)
by bsolar ( 1176767 ) on Saturday June 27, 2026 @01:10PM (#66213034)
I'm confused about how this works. If I don't give a careful sequence of prompts to lead AI then it can go off the rails. For example, it forgets parts of the code after awhile and has to be reminded to reuse a function instead of rewriting it. What is better about the watcher agent that it will keep the AI on track? Also, when will there be a watcher agent watcher? That's what I really want
A modern coding agent can have huge context windows. I use Claude Code with Opus and 1M tokens window at work and that's plenty for "normal" coding activities. The real limiting factor are the API token costs.
As of carefully hand-holding the AI, it's often not necessary anymore since a modern coding agent can infer if there is ambiguity and proactively ask the user for further information and make use of structured development methodologies, e.g. TDD with small incremental changes.
Last week I didn't prompt anything except "implement issue xxx" and Claude Code connected to our JIRA, read the issue in question, asked clarifying question, created a plan and submitted it to me for review. I iterated on the plan a couple times as there were parts I didn't like, then let Claude proceed with the implementation. The result was correct except for a minor GUI issue and a performance optimization.
Ok. (Score: 5, Interesting)
by jd ( 1658 ) on <imipak@yaho[ ]om ['o.c' in gap]> on Saturday June 27, 2026 @11:45AM (#66212932)
So you're telling Claude something vague and washy, then Claude invents a prompt that might vaguely possibly be somehow related to what you want along with a drink that is almost but not entirely quite unlike tea. Claude then recurses through this until it has a Celtic knot so intricate that it has its own Hausdorff dimension. What burps out is a product that is completely useless and patented to the Sirius Cybernetics Corporation.
I've had poor success with this strategy (Score: 5, Informative)
by swillden ( 191260 ) on <shawn-ds@willden.org> on Saturday June 27, 2026 @12:16PM (#66212978)
I've been trying for a while to use a "loop" to optimize one particularly-tedious part of my workflow: Merging.
My employer uses Github with an extensive CI infrastructure to validate all sorts of things. After CI passes, trunk-io takes the commit and retests it in a batch with other commits and if they all pass, merges them as a set of squash commits. If something goes wrong, I have to figure out whether it's a transient failure (in which case I can tell the system to re-run the tests), or whether it requires me to fix and re-push. My commits typically build on one another so I end up with a stack of PRs that have to go through this process. When a commit finally merges the next commit up the stack has to be rebased and re-pushed.
Start to end, getting a commit to merge takes between one and four hours. This is slow enough that even though I don't have to watch the process continuously, just check in on it every half hour or so, it puts a major crimp in my productivity. If I only merge during working hours I can only merge 2-4 commits per day, but on a good day I create double that. This means that I have to be merging evenings and weekends too, or my backlog builds up. (Code review is another obstacle, but I'm focused only on the merge process here.)
There are enough possible odd failure cases in the merge process that I haven't been successful at writing a script to manage it. So I thought "Hey, why not have Claude supervise it? Claude is capable of exercising some judgment and problem-solving, right?".
Not really. If there's a problem blocking the PR at the bottom of the stack from merging, Claude is perfectly capable of analyzing the situation and determining what needs to be done to unblock it, and of performing the operations necessary -- but only with active prompting. Claude can set a timer to go periodically check the status and recognize the problem, but no matter what I do I can't get it to autonomously take the next step of correctly diagnosing and then acting on that diagnosis. Even given explicit instructions to do so, Claude either (a) fails to investigate enough, (b) fails to identify correct actions or (c) fails to perform them. When I wake up in the morning and ask Claude what the situation is, it generally correctly and accurately summarizes exactly what's wrong and exactly what needs to be done to fix it, and then when I ask why it didn't do those things it tells me that it clearly should have, but it just didn't.
I've tried various architectures, using one instance to prompt another one, using pairs of instances set up with distinct, complementary responsibilities, using instances set up with adversarial responsibilities (this is the most effective), but I just can't get it do to this work effectively.