A faster loop between writing code and seeing it run is a real and welcome improvement. It is easy to mistake for a faster loop on the question that actually determines whether a project goes well: is this the right thing to be building at all.
Two different clocks
Feedback on correctness — does this function do what it's supposed to, does this test pass — has gotten dramatically faster with better tooling and coding agents. Feedback on direction — is this the right feature, is this the right architecture for where the product is going — has not gotten faster at all, because it still depends on a person with judgement looking at the result and often on a client or user seeing it in context.
Why this matters more now, not less
When implementation was slow, the two clocks were closer together by accident — a feature took long enough to build that plenty of directional feedback opportunities occurred along the way, in standups, in demos, in the ordinary friction of a multi-week build. Faster implementation removes that accidental cadence. It is now possible to build a large amount of the wrong thing, correctly, before anyone with judgement about direction has looked at it.
What we changed to compensate
- Demos moved earlier and more often, specifically to reintroduce directional feedback at a cadence that matches how fast the correctness loop has gotten, rather than the cadence that used to be forced by slower implementation.
- We show working slices, not finished features, deliberately rough at the edges, because a polished demo invites feedback on polish and a rough one invites feedback on direction, which is the feedback we are trying to get more of.
- Client check-ins are scheduled by calendar day, not by "when there's something to show", because the second version silently shifts towards showing things once they are already too built-out to change cheaply.
Building the wrong thing faster is not progress. It just moves the moment you find out sooner in wall-clock time and later relative to how much has already been built.
The habit this requires from a team
Discipline to show unfinished, sometimes ugly work on schedule rather than waiting for something presentable, because the entire point is catching a wrong direction while it is still cheap to change, and cheap-to-change is a property of how much work exists, not how far into the calendar you are.
Where this leaves the productivity gain
Still real, still worth having. It just needs a directional feedback loop built to match it deliberately, rather than inherited for free from how slow things used to be.