Should we all implement “loop engineering” for software development? Not yet. By Ed Lyons

“Coding agent roller coaster” by Ed Lyons via Midjourney

Best practices around coding agents change quickly, and we are all required to follow and process what leading organizations and pioneers are doing. Lately, there is aggressive new talk about loop engineering. Yet most people should be skeptical about implementing this.

The buzz has become inescapable: articles about loops are proliferating, and loops were a big deal at the “AI Engineer World's Fair” in Las Vegas a few days ago. A few pioneers are now saying they are moving from prompts and context instructions to loops as the primary way of getting agents to accomplish what we want. Boris Cherny of Anthropic recently said, “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

Note that the biggest loop engineering promoters all have infinite resources and token budgets, which is a cause for concern. After all, isn’t everyone these days also talking about overspending through coding agents?

Most enterprise organizations should, as usual, not take the statements of agentic pioneers as a near-term direction for their efforts. The new loop engineering ideas are compelling, but require a great deal of expertise and investment. Most shops will be unable to marshal such resources right now. Also, once you do the easy cases, loops are quite difficult and costly to get right.

Moving from traditional tools and processes toward agentic development is already an enormous undertaking. Trying to also set up a lot of large, autonomous agent tasks before your organization is ready is simply too risky. How would you justify the token burn from experiments with loops that do not close any tickets when less risky agentic development techniques do close tickets faster? Even if you cut token costs by using open or local models for initial loop development, the effort is still a big investment of time.

However, it is worth understanding what loop engineering is about, and how organizations can bend their agentic development efforts toward this model, as it does feel like higher-level automation is where all of this is going. These techniques are also the foundation of the new dark software factories, another exotic new idea in the world of agents that is worth understanding, as someone will one day try to sell you their services.

What “Loop Engineering” seeks to do

The biggest immediate challenge is figuring out which loops people are now talking about. For example, were we not all talking about “Ralph Wiggum loops” for the entire winter? There is a lot of looping already going on inside our harnesses and plugins.

So inside your agent harness - such as ChatGPT, Claude Code, or Codex, your prompts are often handled in loops. When you say, “Please fix the unit tests” and it runs the tests, sees errors, tries a few fixes, runs them again, sees two that remain, fixes them, and then is done - that’s a loop. Loops have a goal, a way of knowing it’s been accomplished, a way of testing the component, and then it iterates until it is done. Claude Code even has a goal command to allow greater use of loops. A lot of the software development lifecycle plugins, such as Superpowers, use loops for things like reviews.

The basis for loops as an agentic pattern is twofold. Through trial-and-error, loops can eventually achieve compliance with standards we already have, despite the non-deterministic nature of the underlying LLMs. The second reason to use them is that sometimes we do not know the right way to accomplish a task, and we want the agent to find a solution that meets our criteria.

The “Ralph Wiggum loop” trend was about looping above your harness, by iterating against a specification. This has proved to be a very powerful technique.

But the new, post-Ralph emphasis on loops is about automating processes. There are different ideas about how to use these new loops, but let’s explore a typical situation where it can be applied.

If you are a developer who uses agents, your day might go like this: you look at your tickets. You pick one to work on. You feed that ticket to your agent, and it works on it for a while. You prompt for changes around the results until you and the acceptance criteria are satisfied. You might ask for clarifications from someone who wrote the ticket or from your visual designer. You add tests and make sure nothing is broken. You push it out for review. It gets reviewed and it goes into your build pipeline. If there are errors, you ask your agent to fix them in a new PR. You then check integration testing. Someone tests it in QA. Perhaps you do a patch. Many developers work this way. Their prompts are driving progress toward a goal, which is the deployed feature.

Loop engineering seeks to automate that day by making each piece a series of iterations toward a testable goal. With loop engineering, loops are driving progress, and humans (often not developers) are triggering these loops to execute steps toward the deployed feature. As a software developer, you are writing the orchestration and the prompts that are pieces of these loops.

Let’s take a simple example: if you see pipeline failures, you usually type in the same few prompts to analyze the problem, then to ask for the fix, and then to ask for a PR, and then to kick off new deployment. Those prompts can become part of a new loop that watches the pipeline, fixes problems, and redeploys, all by itself.

Note that most cases of loops will be far more difficult than this example, and will take a lot of time and tokens to test and optimize. For example, in many cases, the exit condition of the loop cannot be achieved because it is too vague, or because the agent gets stuck repeating strategies that will not work. Or the context window becomes filled up with so much history from failed attempts that it gets lost. Or some tool is needed that the agent does not have access to. Think of all of the times you were in a long debugging session with an agent that went nowhere. That is what can happen in loop engineering efforts.

But eventually, if you had sophisticated loops set up around the tools and people you have now, you’d have a huge roller coaster that would get you from a feature request all the way to a deployment.

Software developers would own that roller coaster and be responsible for its maintenance, failures, and improvements. This process of developing software is what Boris Cherney is describing when he works on Claude Code.

Now that you understand these ideas, you can see how a “dark software factory” could be constructed. If you had the skills to organize your entire product development processes around these iterations, and if you had components that were designed to participate in them, and if you had lots of very detailed specifications, and if you knew where the humans needed to be, you could generate huge amounts of software relatively quickly. (Yes that’s a lot of ‘ifs’ and a lot of tokens. And it is also why software factories require enormous, up-front investments.)

What should enterprises be doing about this now?

The new techniques for loops, which will continue to drive tooling innovation, should increase ambitions in existing agentic development efforts. That project shouldn’t merely be a matter of training developers to use agents more effectively to assist in the traditional software process. It should be an opportunity to imagine what it would look like for a product manager to get a feature into production without making a software developer the sole owner of that effort.

The good news is that loop engineering is built on top of processes and assets that are already part of best practices in agentic development, and are valuable on their own. For example, higher-level automation requires smooth interoperation between enterprise systems. Organizations are already using techniques such as MCP to connect agents to enterprise tooling. These efforts should continue and include more tools. For example, it should be possible for non-developers to trigger agent work using internal chat tools, such as Slack and Microsoft Teams. If a feature is being discussed, it should be possible to tag an agent to go do it, which should be able to produce the pull request without human assistance.

Another example of increasing automation might be in QA. If your existing process results in comments on tickets or new bug tickets, perhaps instead it should also kick off an agent to fix it directly and add a comment of its own about a success or failure.

You should think about all the times when a developer is merely taking direction from a system or person and handing that off to an agent. Can a developer’s process and his or her “definition of done” be put into a skill for an agent to use in a loop?

So keep automating, and look for small, durable loops you can create. Just keep an eye on your model choices and token use. Unlike working at Anthropic or Google, the tokens aren’t free.