Loop Engineering | Composable and distributed systems study group
Mon, 2026-06-22
Sharing our experimental call summaries.
Al-generated digests of Yak Collective study groups.
Reading: https://x.com/sydneyrunkle/status/2066928783534289358?s=61&t=Z7ogL5oXQlE-zjAQ_mFVBw + other links here.
Reframing “Looping”: From Autonomy Theater to Feedback Control
The discussion spent most of its energy trying to clean up what “looping” actually means. A recurring complaint was that recent writing frames loops as “remove the human so you can walk away,” which several people thought was the wrong abstraction. The stronger definition that emerged was: a loop is a feedback process that compares expected outcomes to actual outcomes and then corrects based on the difference. In that framing, the key question is not whether a human is present, but where the error signal comes from.
That shift mattered because it let the group distinguish several different kinds of loops that often get lumped together. One taxonomy discussed included: feedback from unmodeled reality (like a thermostat or cruise control), feedback from bounded rationality in hard search problems (like chess or NP-hard tasks), feedback from revealed human preferences, and feedback from exploration/exploitation processes such as gradient descent, simulated annealing, or multi-arm bandits. The underlying claim was that these are all “loops,” but they differ in what generates the corrective signal and therefore in how automatable they are.
A useful point of convergence was that humans remain necessary only when the missing information lives inside the human—taste, preference, ambiguous intent, or a not-yet-articulated goal. If the human is only acting as a detector or verifier—checking whether a robot fell over, whether a balance condition held, whether an output matches a known target—that role could in principle be outsourced. The discussion did not fully settle how often real software work falls into the first category versus the second, but it did establish a clearer vocabulary for arguing about it.
Brownfield Loops, Frontier Prompts
One of the most useful distinctions was between loops and prompts as tools for different phases of work. The group’s rough synthesis was that loops make the most sense when there is already something substantial to operate over: an existing system, a backlog of tickets, a production environment, a codebase that needs maintenance, or a process with measurable outcomes. In that sense, loops are naturally “brownfield.” Prompts, by contrast, were associated with frontier work: discovery, expansion, generating the first version of something, or operating where goals and context are still being formed.
This was not treated as a strict binary. One hypothesis raised was that greenfield work may still be loopable if there is enough “meta-awareness” about how context is discovered and narrowed. Another view was that much of what gets called prompt engineering at the frontier is still a kind of loop if viewed through the right lens—just a looser, more exploratory one. Still, the broad convergence was that loops become more effective the farther “behind the frontier” the task is, because there is more stable structure to iterate on and less need for human judgment about what the task even is.
A larger implication followed from that: the current rise of “loop engineering” may be a signal that agentic software work is maturing from “make a new thing” into “maintain and steer an existing thing.” That was presented less as a conclusion than as a reading of the moment. In distributed systems terms, the conversation was implicitly moving from provisioning to operations; in control terms, from open-ended design to regulation around a target state.
The Control Theory Lens
Control theory became the deepest shared framework in the conversation. The central bridge was that many open-ended real-world systems are easier to reason about as control problems than as purely static modeling problems. The data center cooling example made this concrete: what might once look like “just” a thermodynamics or fluid dynamics problem increasingly looks like a control systems problem that happens to involve thermodynamics and fluid flow. That is, the key challenge is not only modeling the physics, but continuously steering the system under changing conditions.
This framing also linked naturally to AI workflows. Residual-style iteration—run a forward pass, compute error, update, repeat—was described as familiar from computational modeling and now increasingly relevant to how people work with language models. The analogy here is not perfect, but it was productive: AI-assisted work begins to resemble computational modeling of an adaptive system, where the loop is not just “ask again,” but “measure deviation from target, revise, and re-run.” A speculative extension raised in the discussion was that this could eventually grow into something like a fuller “computational modeling of intelligence,” though that was clearly framed as forward-looking rather than established.
For a cross-domain reader: in chip design or CAE terms, this resembles iterative convergence under constraints; in distributed systems terms, it resembles feedback-based stabilization rather than one-shot execution. The group did not claim these are identical, only that the control lens is proving unusually generative across domains.
Practical Harness Use: Why People Choose Different Tools
A more grounded thread focused on coding harnesses and why preferences diverge. One participant described a pattern that currently feels effective: using one model for security review or hardening, then having another model review that output. Passing work between agents was described as one of the better practical patterns available now. Another noted that some teams they follow are not using loops at all, viewing them as mostly a way to burn tokens at current model quality. Hermes was mentioned as a potentially promising but not yet fully tested harness.
A competing tool preference emerged around Claude Code versus Codex-style setups. Claude Code was valued for being proactive, conversational, and able to infer intent when the user does not yet fully know what they want. Codex, by contrast, was described as more literal—better when instructions are crisp, less comfortable when the user is still discovering the task. That difference was framed not as one tool being universally better, but as matching different users, project types, and working styles. One analogy compared harness choice to choosing among schools of psychology: the tradeoffs reflect temperament and method as much as objective capability.
There was also a strong operational caution: too much harness variety creates overhead. In production systems, where people need reliability and fluency rather than endless experimentation, reducing the number of tools can be a rational choice. One participant summarized loop engineering at this level as “providing context at a higher abstraction level with a while loop underneath,” which captured both the appeal and the skepticism: the abstraction is useful, but the branding may be doing more work than the concept.
Where Loops Fail Today: Meta-Rationality, Drift, and Human Judgment
The sharpest practical objection to autonomous looping was not that loops are useless, but that models still lack the meta-rationality to know when they are solving the wrong problem. A recurring failure mode is that the system encounters a sub-problem, starts “fixing” it, and in the process undermines the larger purpose of the task. In other words, the local correction is valid, but the global objective is lost. That is why, in current practice, a human often still has to intervene and say: stop, that technically solves the sub-problem, but it violates the actual intent.
This issue appeared in a second form in production environments: goals shift, feedback is noisy, and even identifying the real signal is itself a judgment task. When that is true, the loop cannot simply optimize against a stable target because the target is moving and partially socially constructed. The notes suggest a divergence here. Some participants treated this as a temporary limitation of today’s tooling; others implied it may be a more durable feature of human-facing work, where the “objective function” is often discovered midstream rather than specified upfront.
A social consequence also came up: teams working at different levels of LLM-native abstraction can struggle to coordinate. If one person is operating by direct manipulation and another is steering at a higher abstraction layer, they may appear to be talking about the same work while actually interacting with very different objects. That gap was observed rather than resolved.
CAD Defeaturing as a Concrete Loop Engineering Test Case
The clearest domain-specific application discussed was CAD defeaturing. The problem described was common in industrial or manufacturing CAD: input geometry may contain non-manifold or self-intersecting surfaces and other artifacts that make it hard to model computationally. “Defeaturing” here means cleaning that geometry into a coherent, usable volume. This was presented as a promising loop problem because the desired outcome is relatively well defined: start with a “dirty CAD” object and iteratively transform it into a clean manifold representation using available kernel tools.
This example mattered because it grounded the more abstract loop discussion in a case where the target state is concrete, the scope is constrained, and the process plausibly fits a fixed compute budget. That makes it different from open-ended product discovery or shifting production requirements. In simulation/CAE terms, it is closer to iterative repair under geometric validity constraints than to free-form design ideation. A brief trial with Fable was mentioned as showing early promise, though the notes do not claim a full result.
More broadly, this use case supported one of the evening’s main claims: loops are strongest when the objective is determinable and the correction signal can be computed from the artifact itself rather than from a human’s tacit preference.
Wrap-Up
The conversation converged on a more rigorous and less hype-driven understanding of loop engineering. The group did not reject loops; if anything, it treated them as real and increasingly important. But the strongest view was that “looping” should be understood as feedback control around an error signal, not as a synonym for autonomy or human removal. From there, the practical questions become sharper: what generates the error, how stable is the target, and when is human judgment actually intrinsic versus merely a temporary proxy?
Key takeaways
“Looping” was reframed as feedback correction between expected and actual outcomes, not simply automation.
Humans are only intrinsically necessary when the error signal depends on human preference, taste, or ambiguous intent.
Loops currently seem better suited to brownfield maintenance than frontier creation, though that boundary remains debated.
Control theory provided the most generative shared language for understanding both agent workflows and physical systems.
Tool choice depends heavily on user style, task structure, and tolerance for experimentation overhead.
Current failure modes center on drift: models can optimize sub-goals while losing the real objective.
CAD defeaturing stood out as a plausible concrete test case for loop-based agent workflows.
Open questions explicitly surfaced
Can loops be made useful during greenfield discovery if enough meta-awareness is supplied?
How much of today’s human-in-the-loop requirement is temporary model weakness versus a durable feature of open-ended work?
What kinds of harnesses will best support these workflows as the tooling landscape keeps shifting?
Call chat on Yak Collective Discord:
https://discord.com/channels/692111190851059762/1518427600102625381
Interested in distributed and composable systems? We meet weekly on Mondays, at 1600 UTC: https://www.yakcollective.org/join
New here? Start here for some background context:
1) About Yak Collective
2) Online Governance Primer
Are these posts fully automated from transcript to posting out of curiosity? This one was quite nice.