Loops That Earn Their Place

The advice arrives every week now, six words wide: stop prompting, start building loops. Hand the work to a system that runs itself, and go think about what to build next. The instinct is right. The leverage in any tool stops being how fast you operate it and becomes how well you design the thing that operates it for you. But the version being repeated skips the only question that decides whether it pays off: which loops, and where. Run that question through a discipline that has studied feedback for seventy years, and most of the answer turns out to be the opposite of the hype.

The discipline is cybernetics, the study of how systems steer themselves using feedback. It is the same idea behind a thermostat and the governor on a steam engine, and it has a clear, unsentimental view of when a loop is worth building. That view is what the current excitement is missing.

A loop is a regulator. It senses the gap between where something is and where it should be, acts to close that gap, then senses again, and keeps going until the gap is gone. A thermostat reads the room, compares it to the setpoint, runs the heat, reads again. James Watt’s governor on a steam engine spins faster as the engine speeds up, and that spinning pinches the steam back. The thing to notice is that the point of a governor is not motion. It is stillness. At the setpoint it does almost nothing. A good loop spends most of its life idle, holding a target, not thrashing toward one.

There are two kinds of feedback, and the difference is the whole story. Negative feedback corrects toward a target and settles, like the damped signal on the cover, swinging wide at first and then coming to rest on the line. Positive feedback does the opposite: it amplifies, each pass feeding the next, until the system runs off a cliff. The agent that keeps “improving” a piece of work forever, producing more, changing little, billing the whole time, is not a sophisticated loop. It is uncontrolled positive feedback with no setpoint. The slop machine everyone fears has a precise name, and naming it tells you the cure: give the loop a target it can actually reach, and a way to know it got there.

Here is the cost the hype walks past. Every loop pays for its own sensor on every single pass. Before it can correct the error, it has to measure the error, and measuring is not free. A loop is only ever as cheap as the thing that checks its work.

Some sensors are nearly free and exact. A test passes or it does not. Code compiles or it does not. A search finds a banned word or it does not. You can loop on sensors like these all day, because checking costs almost nothing and the answer is unambiguous. The loop knows, cheaply and certainly, whether it is done.

Other sensors are expensive and vague. Asking a model “is this any good” costs real money every time, and it gives a slightly different answer each time you ask. Build a loop on a sensor like that and you pay a premium, over and over, to chase a target that keeps moving. The loop never quite knows whether it is done, so it does not stop, and the bill is the only thing that converges.

So the first rule is blunt. You may loop where the sensor is cheap and crisp. Everywhere else, measure once, and hand the judgment to a person. The quality of the sensor, not the cleverness of the agent, decides whether you are allowed to loop at all.

A loop is worth building only when four things are true at the same time.

• A setpoint. A definition of done you can point at, not a feeling. The loop needs to know when to stop.
• A cheap sensor. Measuring the error has to cost far less than the work, or the loop spends more checking than doing.
• A convergent fix. Each pass has to reliably reduce the error, and the correction has to hold. Removing a banned word converges. Make it feel more premium does not.
• Real variety. If the outcome is predictable, you do not need a loop. You need to specify it correctly once. Spend control only where the world can actually surprise you.

All four, and a loop is the right tool, so make it tight. Miss one, and you are either burning money on an expensive sensor, chasing a target that will not sit still, or building an elaborate regulator for a problem that never varied in the first place. The last condition is the one engineers forget. A loop around something that always comes out the same is just a slow, costly way to write a straight line.

That leads somewhere counterintuitive. If loops are this demanding, then most of a well-built system should not loop at all.

The alternative to feedback is feedforward: doing it right the first time from a good model of the problem, with no measure-and-correct cycle. Wherever you can predict the result, feedforward wins, because it pays the cost once instead of every pass. A pure transformation, a deterministic step that turns the same input into the same output, a single generate-then-check: these are feedforward with one gate at the end, not loops. Wrapping them in iteration adds cost and removes nothing, because there was no error to regulate, only an answer to compute.

So the honest shape of a good system is mostly straight-through work. Feedback is reserved for the few seams that are genuinely uncertain and cheaply measurable. Human judgment is placed wherever the error is a matter of taste. Speed where the sensor is free, and no loop at all everywhere else. That is the optimisation the hype has backwards. It wants everything fast and looping. Cybernetics wants almost nothing looping, and the few real loops kept tight.

The loops that survive contact with a real system tend to run at two very different speeds, and they do different jobs.

The fast inner loop regulates a single piece of work to spec. It is tight, cheap, capped, and idle most of the time. It catches the few mechanical ways a thing goes wrong and fixes them before a human ever sees them. It is a governor, not an explorer, and it is allowed to run fast precisely because its sensor is free.

The slow outer loop is the system learning to do the work better. It runs at the speed of reflection, not tokens, so it costs almost nothing, and it is where the compounding actually lives. Every finished job teaches the system something that sharpens the next one: a pattern that worked, a way a thing slipped through, a check worth adding. This is second-order feedback, learning how to steer rather than just steering, and for anything that runs more than once it beats the fast loop for leverage by a wide margin.

The wasteful instinct is to pour engineering into the fast loop, adding agents and passes and orchestration. The disciplined move is to keep the fast loop minimal and instrument the slow one, so that the system gets quietly better every time it runs, at no token cost at all.

We build loops into how we work, but frugally, and on purpose. The work has a clear shape: understand a business, build its site, ship it, learn from what happened. Most of that is deliberately not a loop, and keeping it that way is the point.

The understanding and the brief are feedforward. We research a business once, keep what is evidenced, flag what is missing, and move on. There is no error signal to regulate there, only judgment to apply, so iterating it in a loop would buy nothing. Turning that understanding into a build brief is a deterministic step, the same inputs producing the same brief, with no model in the middle. Looping a step like that would add cost and change none of the output.

The one place we loop is the build, and only on the parts a machine can measure for free. Does the site compile. Does it accidentally borrow bloom’s own look instead of the client’s. Did a placeholder get left unfilled. These are exact, cheap, certain checks, so a tight, capped loop catches them and fixes them automatically, and stops the instant they are clean. It is a governor on the few mechanical failures, nothing more.

Everything taste-shaped is measured once and handed to a person. Whether the site moves toward the brands the client loves, whether it tells the right story, whether it sounds like the founder: a model can describe that gap, but it cannot be trusted to close it in a loop without chasing its own shifting opinion and billing us for the chase. So it reports, and a human decides. The error there is taste, and the right controller for taste is a person.

And the loop that matters most is the slow one. Every business we build sharpens the next. A pattern that worked becomes part of how we read the following client. A way a build slipped becomes a new automatic check on the fast loop. That outer loop runs at human speed, costs almost nothing, and is the one that compounds. The understanding is the asset, and the slow loop is how it grows.

The hype measures progress by how many agents you can run at once. That is the wrong meter. The real question is narrower and much older: where is there a gap worth measuring, cheap enough to measure, that an action can reliably close. Wherever that is true, loop, and make the loop tight. Everywhere else, specify it well, or let a person judge.

A system with few loops is not a system lacking ambition. More often it is a sign that someone understood it well enough to know which parts needed feedback and which did not. The marble comes to rest on the line not because the loop tried hard, but because it was pointed at a real setpoint, given a cheap way to see it, and allowed to stop.

Feedback is essential, and feedback is expensive. The craft is knowing the difference, and spending it only where it pays.