Who Owns the Loop? - by Matt Lambert - Cardeo Journal

Cardeo Journal

SubscribeSign in

Who Owns the Loop?<br>Automation should scale clarity, not replace judgment.

Matt Lambert<br>Jun 09, 2026

Share

Recently a practice has emerged people are calling “loop engineering.”<br>The premise is straightforward. Instead of writing prompts for AI systems, you design loops that allow agents to plan, execute, evaluate, and determine their own next actions. The human creates the system. The agents run it.<br>At first glance, this sounds like a natural evolution of prompt engineering. If AI can already generate code, review code, test code, and fix code, then why not connect those capabilities together into larger autonomous workflows?<br>The appeal is obvious. More output, more speed, and more automation.<br>But I think something important gets lost when the conversation focuses entirely on what the loop produces rather than what the loop teaches.

Loops Are Where Judgment Develops

One of the recurring themes inside SWARM is that judgment is not something we arrive with. It develops through repetition. Most of what we call experience is really the accumulation of thousands of small loops. We try something, observe the outcome, adjust, and repeat.<br>Over time, signals begin to emerge.<br>The loop is doing more than generating an outcome. It is shaping the person moving through it . Designers develop judgment through repeated critiques. Musicians develop judgment through repeated performances. Founders develop judgment through repeated decisions under uncertainty.<br>The outcome matters, but the deeper value comes from what the loop leaves behind.<br>It leaves behind better judgment.<br>The Goal Should Not Be Fewer Decisions

What strikes me about many loop engineering examples is that they optimize for reducing human involvement.<br>The agent identifies tasks, gathers information, evaluates options, and determines what should happen next. Eventually the human becomes responsible for little more than defining a goal and reviewing the result.<br>From a productivity perspective, that sounds attractive.<br>From a judgment perspective, it feels backwards.<br>The most valuable thing a loop produces is often not the artifact at the end. It is the growing ability to recognize signals while moving through the process. That ability becomes increasingly important as the problems become more ambiguous, more creative, and more dependent on context.<br>When participation disappears, the opportunity to develop judgment also disappears.<br>Scale Amplifies Everything

The promise of autonomous loops is scale.<br>A loop that can execute continuously, evaluate its own outputs, and determine its own next actions can produce an enormous amount of work. That capability is impressive, and in some situations it will be incredibly useful.<br>But scale is not inherently valuable.<br>Scale amplifies whatever already exists inside the system.<br>A loop guided by strong principles can amplify clarity.<br>A loop guided only by output metrics can amplify noise.<br>This is where I think many discussions around loop engineering become incomplete. The assumption is that more iterations automatically lead to better outcomes. In reality, more iterations often just produce more iterations.<br>Without human judgment, an autonomous loop risks becoming a supercharged slop machine. It can generate increasingly plausible outputs at increasing speed while drifting further away from meaning, context, and purpose.<br>The problem is not the loop.<br>The problem is what governs the loop.<br>That distinction becomes increasingly important as AI systems become more capable.<br>What Rapid Design Systems Taught Me

I kept thinking about this while building the Rapid Design System methodology.<br>AI was involved constantly throughout the process. It reviewed architecture, generated documentation, challenged assumptions, wrote code, accelerated implementation, and surfaced alternatives I may not have considered on my own. The amount of exploration and execution it enabled was genuinely transformative.<br>But it never governed the system.<br>The important decisions remained human.<br>Questions about component ownership, governance boundaries, complexity, consistency, and long-term maintainability could not be answered by output alone. They required context accumulated through years of building design systems across different teams and environments.<br>AI performed work.<br>It did not determine what work was worth doing.<br>That distinction became one of the foundational ideas behind the methodology.<br>SWARM Starts From A Different Assumption

The more I see discussions around loop engineering, the more I realize SWARM begins from a fundamentally different assumption.<br>Many autonomous loop systems are designed to reduce human participation as much as possible. The human defines the objective, the agents perform the work, and the system attempts to determine its own next steps. Success is often measured by how little intervention is required.<br>SWARM is interested in a...