The Future Loops

I have become fascinated with agentic loops. I’ve had them run autonomously for days producing and modifying enterprise scale codebases with exacting results. I have come to believe agentic loops will play a huge role in the next phase of software development, though at the moment this way of producing software would be very alien in most enterprise environments. It calls into question most of the conventions we have taken for granted for decades. But the reward is speed with quality at scale. A rubric that has been the goal of every major advance and revolution in software development from agile methodologies, to dev ops to microservices. So what is an agentic loop in the SDLC? To understand what it is we have to understand what it is replacing.

At its most basic software development from a single person writing code to teams of hundreds and major projects has four parts: An idea, a plan, a build, followed by some kind of evaluation that informs the next Idea/Plan/Build pass: a loop! And this is basically one iteration of a loop that can iterate as many times as needed to get the product that is desired. Different methodologies have very different scales to these phases whether it is person-years or a single story point. But the basic parts are common. They are the constants in a diverse world of building software. They are so foundational that all of our roles and disciplines have formed around them and entire careers are spent becoming a deep specialist in one of these parts: Designers and Product Managers in the ideas, Program, Project Managers and Scrum Masters in the plan, and the many classifications of Engineers in the build.

As AI become an everyday part of building software, there are 4 major patterns repeated over and over in today’s SDLCs and AI-SDLCs:

The most simple is the classic SDLC, essentially things run as they have been for a long time, with AI being something that is maybe occasionally consulted or used to look up relevant knowledge needs. PMs, Devs, UX are all doing what they have always been doing.

Human in the Loop AI-SDLC

The next is what you could call Human in the Loop AI development. From a process point of view this looks like the classic SDLC. All the same roles are there with all the same handoffs. The big differences are the tools. This started with agentic IDEs like Cursor, but really took off like wildfire with Claude Code. It is like each person in the classic software development pod is donning an Ironman suit.

While the process has not changed, the power of this should not be underestimated. We are looking at people in the SDLC moving something like 3x-10x as fast using these tools. In many cases most, sometimes all, of the code is generated by AI.

As we sit here in mid 2026 this process has become most common. Interestingly though, most enterprises don’t feel like they are moving 10x or even 3x faster. The acceleration of the speed of software creation in the last 9 months has exposed that the problems that sit on either side of the SDLC: the strategy of what to build in front, and the systems to operate it at scale are now the bottlenecks to agility and speed to market. If an organization had a signal to noise strategy problem going into 2026, it is likely drowning in that noise now as any idea can be rapidly created. Likewise if operations were shaky, the acceleration is now pressure testing all the cracks.

Harness Engineering

Harness Engineering is at the frontier right now, and there is not yet a winning form. Most of the harnesses I have seen or used are taking the next step from a Human in the Loop AI-SDLC, to start replacing the human roles with AI roles, but notably not changing or re-examining the role or function itself. The AI dev still writes code, the AI PM still works with requirements, the AI designer still produces mocks and wireframes. Complex efforts still follow good code hygiene around branching and merging, using PRs.

What the Harness is pioneering is the workflow. Many of the most popular examples are using graph workflows. Graphs allow for complicated iterations where agents can work back and forth until a criteria is met, the same way humans would.

There is also another deep camp which makes the observation that as the frontier models get more capable, rigid workflows and even the more flexible workflow of a graph becomes a liability, as the more powerful models can oneshot much more complicated units of work. This argument leads to a “thin-harness” approach where the investment goes into a very simple control structure and the environment itself: tools, deterministic feedback loops, rules files, verification gates.

In the classic human-in-the-loop model, you are the control system. In harness engineering, you build the control system. That difference sounds subtle but it changes the economics of the whole SDLC. In HITL AI-SDLC the humans are evaluating each of the steps. Human attention is still the most rare commodity. In Harness Engineering humans stop evaluating each step, but the harness doesn’t. It automates step evaluation so human judgment can be spent on the system.

For the operators it requires a shift from task thinking to systems thinking. And with this shift we start to see the classic SDLC roles get blurred. The agents still represent classic dev or PM tasks. But the human operators design the system of interactions between all of them. Still though, the AI-dev/AI-PM/AI-designer pattern is essentially paving the existing footpaths. Those roles exist in-part because of human constraints (specialization limits, communication overhead,the need to divide work across brains that can’t share memory). Agents don’t have those constraints or don’t have them in the same way, so the role decomposition we’re porting over may be a transitional scaffold. Agentic Loops start to pioneer truly new paths.

Agentic Loops

An agentic loop is a form of harness engineering, however it has enough differences to treat separately. It is in the class of a thin harness in that it doesn’t create rigid or explicit workflows. The heart of the system is a loop controller that runs everything. In its simplest form, it is a while loop, which continues doing a task until an exit criteria is met. Depending on the exit criteria different context, prompts, tools and resources are used by the loop. Nearly any task in a traditional SDLC can be a loop. Nearly any task in the enterprise could theoretically be a loop! It takes a minute to get your head around this. For sure the traditional ones like planning and building work. But also for example a security review, or a loop to make documentation consistent. Any activity with an exit criteria can be a loop.

The Loop works based on three foundational pillars:

• Eventual consistency - the loops are self healing. They will go astray or miss the mark in a given iteration but ultimately converge with deep accuracy on the requirements and correct product. Because of…
• Back pressure - there must be a clear target or goal that is falsifiable by the agents. I have been using canonical specifications where the loops to make specs consistent and the loops to plan and implement have a hard firewall. The former sets canon (the back pressure), the later implements and tests against it but may not edit it.
• Context management - each loop’s context is discretely managed to be explicit on what is in and out of context for the agent, how it is gathered (typically summarized via sub agents) and loaded such that the work always takes place in the “smart zone” or upper half of the context window.

It happens that these ideas together approximate into a 100+ year old mathematical formalism: Banach’s fixed-point theorem. What is important to understand is that these pillars are non-negotiable, even if they can take many forms: canon is the fixed point, and the three pillars are what make each iteration a contraction toward it. In Geoffrey Huntley’s original minting of “Ralph Loops” the backpressure was a compiler. This works great if you are creating a new programming language. But in applying the same ideas to apps and websites I have found a spec that forms a complete and testable canonical reference works great. Regardless the idea is the same: the backpressure is the exit criteria to the loop, and the thing that forces eventual consistency.

Context management is also a critically important point as one of the chief failure modes of almost all other AI development is rollover compaction and the “dumb zone” of the context window creating slop. Loops handle this while taking on epic scoped problems by carefully curating context in each iteration as part of the loop architecture. As has been pointed out by Huntley and others this looks a lot like memory management in practice. The most precious resource is carefully curated, loaded and cleared for each increment of work.

Here frontier model diversity really comes into its own. A Sol or Fable is great for planning: scope expansion and creativity are generally your friends. But when you get to building you may have a build loop that runs for days over hundreds of iterations. You want each iteration to color just the box of the scope of the task allocated. So a Sonnet class or even Haiku is not just cheaper, it is better for these purposes. In this way with agentic loops you run the vast majority of your workload on more commodity priced LLMs. In fact they work great with open weight models that can run for free on a well provisioned Macbook Pro!

Why Try This

All of this comes together with the following advantages from other approaches: the ability to take on large epics: microservice or monolith rearchitectures, implementation of multitenancy across large architectures, building MVP grade v1s from a collection of market research, screenshots, and product briefs are all outcomes I’ve seen work. All while running inside the standard subscription costs from Anthropic or OpenAI. Maybe most impressive of all is the follow on features and maintainability. Loops are great for v2, 3 and 4 and ongoing enhancements and upgrades as you build.

Perhaps the place this is most differentiated is in managing the specification as a loop and a canonical artifact as part of the harness. It is this “debugging” and merging of conflicts at the spec phase that makes the rest of this handle high complexity with low defects. As the old saying goes, a bug found in prod is an order of magnitude more expensive than one found in testing, which is an order of magnitude more expensive than one found in the specification.

So what are the downsides? Why isn’t everyone doing this? I think more people will be, over time. But there are reasons not to do this at your day job, yet. In order for agents to run for hours or days on their own they have to stop the persistent asking of permission for every action that has some security or access implications. This means explicitly skipping permission asking. Which means solving the security and access control problem via containment not permission. Everything is run in ephemeral containers. Given the power of the command line tools in CLIs like claude code you do not want to just go YOLO in your local environment.

Another issue is the cognitive dissonance of this approach is high and is a lot of friction. The human operator is not really any one role, but is a generalist with deep customer insights, systems thinking, and high agency. Many former constructs that were process solves for collaboration simply dissolve away. The failure mode for ambiguity in what success looks like is catastrophic. All of this cuts sharply against the norms in most enterprises today.

Finally the previously mentioned issue of strategy at the front end and operations at the back end not keeping up is even worse given the scale of changes agentic loops can take into scope. Any other process that is daisy changed on this could prove a similar bottleneck.

What’s Next

Further evolution is likely required to imagine large teams using this approach at scale. It is something I think about often. Branching strategies, pull requests, standups, sprint ceremonies, the titles on our badges were designed for systems full of human operators. Take merge conflicts. For forty years we’ve resolved collisions in code, because code was where two people’s work met. The real collision was always between requirements (assumed or explicit). In an agentic loop system these conflicts will need to be resolved at the outset, via a loop designed to do just that!

Agentic loops are a way of building software that doesn’t inherit the same constraints. So the old conventions start to lose their meaning. I can imagine an enterprise where the human operators are accountable to a function and run a harness. Rather than having a functional role, they have an operator’s accountability: things like: conversion, onboarding, yield. And to move the needle on these they run harnesses with agents, loops and tools. As we move away from paving the footpaths, and forge new ways of working with new processes and new roles, we start to see where the future loops.