A few months ago ‘Loop Engineering’ became a hot topic in the AI agent space. I couldn’t find a compelling reason to add a loop to my agentic AI usage just for the sake of it. Neither did I understand what it really meant. I even made a short video about this.
Late last year, there was a lot of excitement about Ralph Loops. There was also Steve Yegge’s GasTown which, to me, was a framework to do much more sophisticated forms of multi-agent work than loops. The OpenClaw wave was the first large-scale demonstration of the power of AI running in a loop.
My guess is that the recent trend towards ’loop engineering’ really took off with the idea of the ‘Dark Software Factory’. The gist of the idea seems to be that instead of giving a prompt for doing one part of the software engineering process, define multiple agents with their own prompts and let them continue working in a loop until the goals are met. My friend Nate demo’ed a project he had done based on this idea, and his loop had 15 steps in total, if I remember correctly.
The first time I tried a small, controlled version of loop engineering was about a month ago. Li Yin, the founder of AdaL gave me a nudge over a DM that I need to try out loop engineering. I tried it using the tool her startup builds (which I use quite regularly), and exhausted my rate limit in an hour!
The following week, I tried again, and was able to add an enhancement to one of my full-stack projects without supervision. And without messing with rate limits. This was a two-agent version of loop engineering, where one agent ‘builds’ and the other one ’evaluates’, based on a set of plans created by the top-level agent. It was simple to understand, and seems to be working. I used it a couple more times, including one time when I used it on a project which I had already launched, and another time when I was busy with my kid because the nanny was on leave.
I think this kind of ’loop engineering’ can be helpful in fixing bugs and adding small changes to existing software. It can also be helpful in regular software maintenance tasks, like triaging failures or categorizing bugs. In short - in all the ‘boring’ tasks one needs to do after a software product has started to sell and needs to be kept in good shape. From my professional experience, that is a large part of a software engineering. One of my mentors used to call it ’lather, rinse, repeat’.
Another situation where this might be useful is when top-class frontier models cannot be used. Think of local LLMs, which might need more assistance in order to solve a problem.
Again, this is my opinion only - I don’t think you should use ’loop engineering’ for a creative task. Because creative tasks need the human to be actively involved. So I don’t recommend using loops for starting off a new product, or for writing a new report. I am not sure it is going to be useful for debugging as well, because debugging needs creative breakthroughs and single-minded focus. Which is completely fine, I think. As we try to rave about autonomous AI agents, I keep feeling that interactive AI agents are still very powerful tools for human beings.
Like every other term that has sprung up in AI, ’loop engineering’ could have a half life of three months. I think the name could be better, like ‘multi-agent-team engineering’. The concept seems relevant and is unlikely to go away. Who knows, the entire loop might become a ready-made API endpoint, served by frontier LLMs.