Feedback Loops

A regression ships on a Tuesday afternoon, bundled into a release with fourteen other changes. Eleven days later, a support ticket connects a customer’s broken export flow back to that release, and the engineer who has to fix it is not the one who wrote it — that person moved onto a different service two sprints ago. Reconstructing what happened costs a day of git archaeology, three Slack threads, and a stand-up spent explaining a decision nobody in the room quite remembers making. The same defect, if the team’s test suite had covered that export path, would have been a failing build four minutes after the commit and a five-line fix before lunch.

Nothing about the underlying mistake changed between those two versions of the story. What changed was how long the system took to tell somebody about it. That gap — between an action and the information that the action was wrong — is not a footnote to this particular incident. It is close to the single variable that decides whether an engineering organization corrects itself in an afternoon or in eleven days, and most teams have no name for it beyond “we should really improve our testing,” said the way people say it about flossing.

What a feedback loop actually is

The formal name comes from systems dynamics, not software engineering, though software engineering has been quietly practicing it for decades. A feedback loop exists whenever the output of a process becomes an input that shapes that same process’s own future behavior — a thermostat reading the room it heats, an account balance whose interest compounds into the figure the next interest payment is calculated from, a test suite whose failure changes what the next commit looks like. Donella Meadows, whose Thinking in Systems remains the clearest general-audience treatment of this vocabulary, built an entire account of how systems behave — economies, ecosystems, organizations — around structures like these, on the argument that a system’s structure, more than the intentions of the people inside it, is usually what determines its behavior.

Every engineering practice that claims to make a team better is, whether anyone frames it that way or not, a bet on some feedback loop. Code review is a loop. A test suite is a loop. A postmortem is a loop running on a much longer clock. Some of these loops work well. Some have quietly stopped working without anyone noticing, because a stopped loop does not announce itself — it just leaves a team correcting the same class of mistake the same way, at the same pace, indefinitely.

Balancing loops and reinforcing loops

Systems dynamics names exactly two kinds. A balancing loop — sometimes called a negative feedback loop, though nothing about it is bad — is goal-seeking: it resists a change and pushes the system back toward some target, the way a thermostat cuts the heat once a room reaches its set point. A test suite that blocks a merge until a regression is fixed is a balancing loop with the correctness of the codebase as its goal. A reinforcing loop does something structurally different: it amplifies whatever direction the system is already moving in, for better or for worse, because each cycle through the loop feeds a larger input into the next one. Nothing about a reinforcing loop’s structure guarantees it points somewhere good.

The two reinforcing rows in that table are not two different phenomena. They are the identical loop — review turnaround shaping commit size, which reshapes review turnaround — running in opposite directions depending on which way it happened to start. That is the uncomfortable part of reinforcing loops: their structure is neutral. Nothing about a reinforcing loop announces, on day one, whether it is compounding a good habit or a bad one; that only becomes visible after several cycles, by which point a vicious loop has usually recruited its own justification. “We batch changes because review is slow” is also, quietly, the reason review is slow.

The variable that decides whether a loop helps: delay

A loop’s value is not just a function of whether it exists. It is a function of how quickly it closes — how much time passes between an output and the moment that output changes the process’s behavior. A bug caught by a compiler closes in seconds: the type error is visible before the engineer has finished the thought that produced it. A bug caught by a code reviewer closes in hours or days, and by then the mental context that produced the mistake has partly evaporated — the reviewer is reconstructing the author’s reasoning from a diff, not watching it happen. A bug caught by a customer in production closes in weeks, after the change has shipped, after other changes have layered on top of it, and after the cost of fixing it has stopped being “edit a function” and started being “coordinate a hotfix, write an incident report, and find out who else touched this file since.” These are not the same kind of expensive. They differ in kind, not only in degree.

Exactly how much later-caught defects cost is a genuinely contested question in software engineering, and this Library has already worked through why: the Volume III chapter on plan-mode thinking covers Barry Boehm’s escalating cost-of-change curve and Laurent Bossavit’s critique of how thin its empirical basis actually is, a debate this chapter has no reason to relitigate. What survives that debate is the qualitative direction, which is far less controversial than any specific multiplier — information that arrives sooner is cheaper to act on than information that arrives later, because less has been built on top of the mistake in the meantime.

Continuous integration is, in this framing, an engineered short loop. Frequent, automated integration exists specifically so a regression surfaces within hours of the commit that caused it, rather than after however long a feature branch happens to sit unmerged, because a problem visible against a few hours of change has far fewer places to hide than one visible against a few days of it.

The key to fixing problems quickly is finding them quickly.

Martin Fowler, on continuous integration

The same logic scales up past a single build. DORA defines lead time for changes as the time from a commit landing to that change running in production — one full turn of an organization’s largest engineering feedback loop — and the spread between organizations on that single measure is not incremental. Reporting built on DORA’s own performance bands has put elite performers at under a day for that loop and the lowest-performing organizations at one to six months, for the identical loop, measuring the identical thing. That is not primarily a difference in how well either team’s engineers write code. It is a difference in how long their organization takes to tell them when they haven’t.

Generation got fast; the loops around it didn’t

This is the systems-level reason AI-assisted engineering makes loop speed more consequential rather than less. An agent that can produce a working draft in the time it takes to read the ticket has not shortened the path from commit to production — it has sped up the one stage of that path, generation, that was rarely the bottleneck to begin with. Every loop downstream of generation still closes at whatever speed it closed at before: the test suite still takes as long to run, a reviewer still needs the same time to reconstruct intent from a diff, the deploy pipeline still gates on the same checks it always gated on. Volume VII of this Library names this directly as the verification asymmetry — generation got cheap; verification did not get cheaper at anything close to the same rate. This chapter’s systems framing is the more general version of that specific finding: it is not only verification that failed to speed up. It is every loop an engineering organization depends on to correct itself, and an unsped-up loop wrapped around a sped-up generator does not average out to a faster system. It produces a queue.

The evidence that this is already happening is not hypothetical. A 2025 analysis spanning more than ten thousand developers found AI-assisted teams completing roughly 21% more tasks and opening nearly twice as many pull requests, alongside code review time up about 91% over the same period and organization-level delivery metrics essentially flat. Read as a loops problem rather than a productivity problem, that is a balancing loop — review, gating what reaches production — straining to absorb a reinforcing one, faster generation feeding more review volume, running well ahead of it. DORA’s own research frames AI’s effect on an organization as an amplifier of whatever was already there, for capability and for dysfunction alike. A team whose loops closed slowly before AI arrived does not get faster loops from AI. It gets the same slow loops, now with a larger backlog pressing against them.

A framework for auditing your own loops

Naming a loop and its type is the diagnostic step. The practical one is inventorying which loops an engineering organization actually depends on and being honest about how long each currently takes to close. None of the rows below are exotic — most already exist in a team’s tooling in some form — but few teams have ever written them down next to each other with a real delay estimate attached, rather than a felt one.

What to check in your own telemetry

Operon does not yet have a large enough cross-team sample of loop-closure times to publish this as a measured finding, so treat the figures below as illustrative of the shape worth instrumenting, not as a benchmark to hit.

None of this argues for chasing every loop toward zero delay — a loop closed too fast can trade away thoroughness for speed in a way that lets bad changes through faster, which is its own failure mode. It argues for treating loop delay as a decision made on purpose, loop by loop, rather than an accident of whichever tooling a team happened to adopt first. A generator now producing work faster than any of the surrounding loops can absorb is not, by itself, a productivity story. It is a queue with good PR, until something downstream closes the gap.