Why does faster coding not produce faster delivery?#
Because writing code is one stage of getting software into production, and it was rarely the slowest one. The stage that got faster is the build loop, which runs from a specification to a merged, tested change. The waiting happens in the delivery loop around it — validation, review, approval, release windows and measurement — and none of those got faster because the code arrived sooner.
The symptom is a large gap between active time and elapsed time. A change that takes an afternoon of work and eleven days to reach a customer is not limited by how quickly it was written.
Where does the constraint go instead?#
It moves. Each time an earlier step speeds up, the bottleneck relocates, and the pattern of constraint migration commonly runs from context, to validation, to comprehension, to judgment, to intent, and finally to the organisation's ability to absorb change at all. Two teams in the same company can be stuck on different things at the same time.
This is why the useful question is not "how do we generate more code" but "where is this work being held back right now" — and why the answer has to be asked again after every improvement, because a successful fix is precisely what invalidates it.
Why do more tools rarely fix it?#
Buying the artefacts of change instead of changing how work flows is tooling substitution, and it is the most common failure in AI adoption. Automation amplifies whatever system it lands in. Where intent is clear and results are checked, it speeds things up. Where they are not, it produces unchecked work faster, which is worse than slow because the cost lands later and on somebody else.