Speed looks like progress until the system needs to turn.
In the kind of AI-assisted work I now see, production that would once have been spread across months can arrive in days. Plans, code, tests and documentation can all move at once. The visible output is extraordinary. The rest of the system has not necessarily become faster with it.
People still need to understand what changed, decide whether it makes sense and notice what the work has assumed. Those are not administrative steps around production. They are part of producing something trustworthy.
When production accelerates without them, one of two things happens. Verification becomes the next constraint, or it is treated as friction and skipped. Both can make the early speed look better than the eventual result.
The bottleneck moves
This is the useful lesson I take from the Theory of Constraints: making one stage faster does not make the whole system faster. It moves pressure to whatever comes next. With AI, the new constraint is often the human work of directing, evaluating and correcting what has been produced.
A 2026 longitudinal preprint followed professional software engineers using AI coding assistants and described a shift from creation towards verification work. The authors call it supervisory engineering: directing, evaluating and correcting AI output (Vella and Blincoe, 2026). The findings are self-reported and should not be treated as a universal measure of productivity. The change in the shape of the work is the more useful point.
If five agents can produce in parallel but one person remains accountable for the result, generating more is easy. Absorbing it is not. The danger begins when we respond by delegating the decisions that required that person's context in the first place.
Wrong decisions become context
The most consequential delegation is not typing the code. It is deciding what the system is meant to be: which assumption is authoritative, which trade-off is acceptable and which direction later work should inherit.
In my own AI-assisted work, I have watched a weak decision survive one task and become the starting point for the next. Once it appears in a plan, a test or the implementation itself, another agent can reasonably treat it as settled. Parallel work gives that decision more descendants before anyone has stopped to challenge the premise.
The mistake has not become more true. It has become more consistent.
This is why recovery can feel like fighting the AI. The model does not literally believe it is right. But it is reasoning from a body of work that now points in the same wrong direction. Correcting the latest output is not enough. You have to identify the original decision, invalidate the artefacts that reinforce it and establish a clearer source of truth.
By then the speed has reversed. The work has to be broken down before it can be brought back into line. What looked like velocity was partly distance travelled towards the wrong edge.
Feedback is part of velocity
This is not a new systems problem. In a laboratory inventory-management experiment, performance deteriorated as time delays and feedback effects became stronger, even though participants knew the system's structure and had incentives to learn (Diehl and Sterman, 1995). An inventory simulation is not an AI workflow, but the mechanism matters: delayed consequences make a changing system harder to steer.
Research across 76 agile teams offers a useful boundary too. Some technical and iterative feedback practices were associated with software quality, but the relationship was more complicated than “more feedback is better” (Tripp and Sambamurthy, 2023). Feedback can become noise or another bottleneck if it is applied indiscriminately.
Low-risk, reversible work should still move quickly. The stronger check belongs where a decision changes a fundamental assumption, affects many later actions or will be difficult to unwind. It needs to happen before that decision becomes context for the next wave of work, not at the end when everything appears complete.
AI has made production cheap enough that understanding and verification can no longer be treated as the quiet work around it. They are the steering and the brakes.
Speed determines how quickly you move. Feedback determines whether that speed becomes progress.
Further reading
These books offer related lenses rather than direct proof of the argument.
- Thinking in Systems, Donella Meadows—feedback loops, time delays and the behaviour of whole systems
- The Goal, Eliyahu M. Goldratt and Jeff Cox—constraints, flow and why optimising one stage does not optimise the whole
- Accelerate, Nicole Forsgren, Jez Humble and Gene Kim—software delivery research that considers speed and stability together
- Drift into Failure, Sidney Dekker—how locally reasonable choices can accumulate into system-level failure