Feedback Loops

In previous posts we introduced two complementary concepts: model plasticity, which captures the cost of making a change, and mistake rate, which captures how many corrective iterations are required to get something right. But neither concept on its own tells us how quickly those corrections happen. That is the role of feedback loops.

A feedback loop is the mechanism by which a system detects that it has deviated from its intended state and initiates a corrective response. Without feedback, a system cannot self-correct. It continues in the wrong direction indefinitely, accumulating errors rather than resolving them. In this sense, feedback loops are not just useful; they are the essential control mechanism of any adaptive system.

The concept of a feedback loop comes from control theory, but it applies naturally to software development. Every time a developer writes code and runs a test, they are completing a feedback loop. Every time a product ships and customers respond, that too is a feedback loop.

The Length of a Feedback Loop

Feedback loop length is the time that elapses between taking an action and receiving information about its consequences. A short feedback loop means you know quickly whether you were right or wrong. A long feedback loop means you may spend days, weeks, or even months before discovering a mistake.

Feedback loops in software development exist at many scales: from compilation errors and test failures, to large scale refactoring or re-implementing a piece of software on a different technology stack.

Each of these loops plays a different role. Shorter loops catch smaller, more localised problems sooner. Longer loops catch broader, systemic issues, but at a much higher cost, because more work has accumulated between the mistake and its discovery. Even if correlated, this is different from the cost of change arising from model plasticity. Errors detected by long feedback loops are expensive because there are more things to change, not because it is harder to perform the change itself.

The connection between feedback loop length and convergence speed is direct: the shorter the loop, the faster the system can correct itself. Writing a correct implementation of some business logic takes at most a few hours because unit tests provide immediate feedback. Getting the right architecture for a large system may take years and several rewrites because the feedback loop is much longer.

A side consequence of the correlation of feedback loops and convergence speed is also the rate at which we learn. This is why architects are so valuable: learning those skills takes years or decades, while learning to code takes months.

The Effectiveness of Feedback

Loop length is only part of the picture. A fast feedback loop that gives you the wrong signal is worse than a slow one that tells you the truth. The effectiveness of a feedback mechanism matters just as much as its speed, and effectiveness can fail in two directions.

A false negative occurs when a feedback mechanism fails to detect a real problem. A test suite that passes despite a bug is a false negative. A code review that misses a security vulnerability is a false negative. A staging environment that does not reproduce the load conditions of production is a false negative.

False negatives don’t arise just from the lack of test coverage. A healthy software projects requires feedback loops at multiple levels: code reviews, monitoring in production, usability studies, user feedback, and so on.

A false positive occurs when a feedback mechanism reports a problem that does not exist: a flaky test, a counterproductive linter rule or an alert that fires in production for no good reason.

False positives are costly in a different way. They do not let bad changes through; they block good ones. Worse, they erode trust in the feedback mechanism itself. If a test suite has enough flaky tests, developers learn to ignore failures. If there are too many alerts from production, developers may start to ignore them as well. At that point, the feedback loop is effectively broken: it is still generating signals, but no one is acting on them.

A healthy feedback loop must be reliable in both directions. It should catch real problems and suppress phantom ones. Achieving this balance requires investment in the quality of the feedback mechanism itself, not just its speed.

The Big Picture

Feedback loops, model plasticity, and mistake rate form an interconnected system. Each concept describes a different dimension of what it costs to develop software and how efficiently that process converges on a correct result.

Model plasticity determines how expensive each corrective action is. If we consider a specific type of error, say a wrong assumtion in requirements. A highly plastic model like requirements documentation, allows corrections to be made cheaply, but typically has less reliable feedback loops. A deployed system with real users will offer more accurate feedback for the same type of error, but the cost of change is much higher, so it is less plastic.

Striking a balance between plasticity and feedback loop effectiveness is crucial. A highly plastic system with poor feedback may allow for cheap corrections, but if those corrections are not guided by accurate feedback, they may not lead to convergence. Conversely, a system with excellent feedback but low plasticity may identify problems quickly, but the cost of fixing them may be prohibitive, leading to stagnation.

Mistake rate determines how many corrections are needed. A low mistake rate means fewer iterations. A high mistake rate means even cheap, fast corrections will add up. If the mistake rate is high, even a perfect feedback loop and low plasticity may not be enough to achieve convergence in a reasonable time frame. Conversely, if the mistake rate is low, even a less effective feedback loop or higher plasticity may still lead to convergence, albeit more slowly.

Feedback loop length and effectiveness determine how quickly and accurately mistakes are surfaced. Even with perfect plasticity and a low mistake rate, a broken or slow feedback loop can stall convergence entirely.

The three concepts are separable but interdependent. Optimising only one while neglecting the others produces limited results. A system with low plasticity, high mistake rate and short and reliable feedback loops will converge but at a very high cost. A system with high plasticity, low mistake rate and long feedback loops may converge but very slowly. A system with high plasticity, low mistake rate and short feedback loops will converge quickly and efficiently.

What about Agentic Coding?

With Agentic Coding, the economy of writing software changes dramatically. Model plasticity rises significantly, but the mistake rate increases. Multiple levels of feedback loops become even more critical in this context, as they are the primary mechanism for ensuring convergence.