Engineering Loops

A developer kicks off an agent against a failing build at 9:14 in the morning. By 9:19 it has tried, failed, diagnosed, and retried six separate fixes — compile, read the error, patch, compile again — a cycle that would have taken a person the better part of a morning to work through by hand, one guess and one recompile at a time. The build goes green. The agent opens a small, clean pull request. The developer glances at it, satisfied, and moves on to the next ticket. The pull request sits, unreviewed, until Thursday.

Nothing in that story is a failure of the tool. The build loop did exactly what it was supposed to do, at a speed no team had access to two years ago. The problem is what happens next — or rather, what does not happen next, because the loop that used to absorb roughly the same volume of work as the build loop now has to absorb several times as much, at exactly the human pace it always ran at. That gap, and what it does to a team’s actual day-to-day practice, is this chapter’s subject.

Four loops, four speeds

Software teams do not run one feedback loop. They run at least four, nested inside each other, each with its own natural cadence, long before any AI agent entered the picture. The build loop — write code, compile or run it, see immediately whether it works — is the tightest of the four: Martin Fowler’s guidance on continuous integration treats a ten-minute build as a reasonable target and quotes Kent Beck’s stricter rule that no code should sit unintegrated for more than a couple of hours, because the entire value of the loop depends on the feedback arriving before the developer has moved on mentally to something else. The test loop, running the fuller suite rather than a local build alone, typically runs minutes to tens of minutes — fast enough to stay inside one sitting, slow enough that teams batch it rather than firing it on every keystroke.

The review loop is slower by an order of magnitude or more: hours to days, gated not by compute but by a person’s availability and attention. And the deploy-and-observe loop is slower again — days to weeks from a change reaching production to a team having enough signal to know whether it actually worked, which is close to what DORA’s own delivery metrics are built to measure: how often a team deploys, how long a committed change takes to reach production, what share of deployments require immediate intervention, and how long recovery takes when one does. Those metrics are, among other things, an instrument panel for the outermost, slowest loop in the stack — the one every faster loop underneath it exists to eventually serve.

The loop that got the fastest

AI agents plug into the innermost loop most naturally, and for an obvious reason: build-fix-build is a tight, mechanical, checkable cycle — exactly the shape of task an agent can attempt, verify, and retry without waiting on a person at all. An agent reading a compiler error, patching it, and rerunning the build can plausibly cycle through that loop many times in the minutes it would take a person to work through it once. That speedup is real, and it is also narrow. It does not, by itself, touch the review loop, the deploy loop, or anything downstream of the moment a change first exists.

This is not a hypothetical gap. This Library’s Volume VII chapters — The Verification Asymmetry and The New Code Review — document exactly what happens on the other side of it: a 2025 analysis spanning more than ten thousand developers found AI-assisted teams merging nearly twice as many pull requests while code review time grew roughly 91%, with organization-level delivery metrics essentially flat. A later pass across a larger sample found review time climbing further still. None of that is a build-loop problem. It is what a fixed-speed loop looks like when the loop feeding it just multiplied its output.

Nested loops, not independent loops

The clean way to see why this matters is to stop treating the four loops as four separate dials and start treating them as one nested system — the way control engineers treat a cascade of feedback loops deliberately run at different speeds. In cascade control, an inner loop handles fast disturbances and an outer loop handles slower ones, and the whole architecture depends on a specific rule: the inner loop has to run meaningfully faster than the loop it feeds, by a wide enough margin that its output looks close to steady from the outer loop’s point of view. Get that ordering backward, or let an inner loop’s noise reach the outer loop faster than the outer loop can absorb it, and the standard warning in that literature is blunt: a large propagation of error.

Software’s four loops were never formally engineered as a cascade, but they have always behaved like one informally — a build loop nested inside a test loop nested inside a review loop nested inside a deploy loop, each absorbing the noise of the loop inside it before passing a cleaner signal outward. What AI changes is not the nesting. It is the ratio. A build loop that used to run a few times faster than the review loop above it can now run tens of times faster, and the review loop was never built to be a shock absorber at that ratio. The propagation-of-error problem control engineers describe has a plain-language equivalent here: a queue that outruns whoever has to clear it, a growing pile of half-verified changes nobody explicitly decided to accumulate.

The trap of optimizing one loop alone

There is a name in the management literature for exactly this failure, and it predates AI by decades. Eliyahu Goldratt’s theory of constraints holds that a system’s overall throughput is set by its slowest, most constrained stage — its bottleneck — and that improving any other stage in isolation, however impressively, does not raise total throughput at all. It only produces more work piled up in front of the constraint. The framework’s own summary of the idea is direct: attempts to optimize each individual process without regard for the system’s actual constraint tend to cause problems that reduce overall performance rather than improve it.

Applied here, the trap is specific and easy to fall into precisely because it looks like progress from inside the loop being optimized. A team that speeds up its build loop watches commits happen faster, feels the acceleration, and reports it upward as a win — and every part of that can be true while deployment frequency and lead time for changes, the DORA metrics that actually describe how fast value reaches users, do not move by a comparable amount. This is the same relocation this Library’s Volume I chapter on the review bottleneck traces from the review side: the loop that got faster was very likely not the constraint. It was simply the loop AI could reach first.

Speeding up the fastest loop in a system does not speed up the system. It moves the place where the system waits.

The four loops, nested

One nested stack, four characteristic speeds, and a genuinely different failure mode at each seam once the inner loops start moving at agent speed rather than human speed:

What this looks like in a team’s own loop data

None of this requires exotic instrumentation to check. The raw timestamps already exist — commit time, build-pass time, PR-open time, first-review time, merge time, deploy time — scattered across a CI system, a code host, and a deployment pipeline that mostly do not talk to each other. Joining them, even roughly, turns "the build loop feels faster" from an impression into a measurement of where the four loops actually stand relative to one another.

What to check this week

1. Time each loop separately, not just the pipeline end to end. A team that only tracks commit-to-deploy cannot tell whether build, test, review, or deploy is the stage actually holding everything up.
2. Compare the ratio between neighboring loops, not the absolute speed of any one of them. A build loop running forty times faster than the review loop above it is a structurally different situation than one running four times faster, even if both simply feel like "the build is fast now."
3. Before investing further in speeding up the fastest loop, ask whether it is the constraint. If deployment frequency and lead time for changes are not moving, the bottleneck has already relocated, and further build-loop investment will not touch it.
4. Treat review and deploy capacity as shared, finite resources — the way a factory treats a constrained machine — rather than as a queue that will eventually catch up on its own.

This volume’s thesis is that AI does not replace systems thinking — it amplifies whatever systems thinking a team already had, or did not have. A team that already understood its four loops as one nested system, with review and deploy capacity managed as a deliberate constraint, will feel the build loop’s new speed as leverage. A team that never thought about the four loops as connected will feel the same speed as chaos: a backlog nobody planned for, arriving from a stage nobody was watching.