When implementation is nearly free, deferring the tests or the edge case stops being a time-saving decision and starts being a decision to ship something worse for no real saving.
For most of my career, the instinct to cut scope was correct. Every additional thing you built cost real time, and time was the scarcest resource on any project, so the discipline that mattered was knowing what to leave out. Ship the smallest thing that solves the problem, table the rest, come back to it later if it turns out to matter. That instinct is now, for a specific and growing category of work, actively wrong, and I have had to unlearn it deliberately rather than let it keep running on autopilot.
The thing that changed is the marginal cost of the extra work — the tests, the documentation, the edge case you would normally defer, the second thing you noticed while fixing the first. When that work can be done in the same pass as the feature, at close to the same cost as the feature alone, "table the tests for later" stops being a time-saving triage decision and starts being a decision to ship something worse for no real saving. The old arithmetic that justified deferring it no longer holds, but the habit of deferring it is still there, inherited from years of the old arithmetic being right.
"Table this for now" was never really a plan to come back to it. It was a polite way of saying no, wearing the costume of a plan, because the moment usually never came back around before something more urgent replaced it. The thing about a workaround left in place under time pressure is that the pressure which justified it eventually goes away, but the workaround stays. Something patched around because the day was rushed does not get revisited once the rush is over — it becomes the permanent shape of the code, because revisiting it never becomes anyone’s actual priority.
Doing the whole thing while the context is loaded is also, practically, cheaper than doing it later, independent of the general cost drop. Whoever has the problem fully in working memory right now can extend a fix to cover the adjacent case in minutes. The same extension a week later means reloading the whole problem from scratch, which costs more than the extension itself would have cost the first time round.
None of this is an argument for scope creep in the sense of adding features nobody asked for. It is specifically about the parts of a task that were always part of the task and got quietly excluded by habit — the test coverage, the documentation update, the second call site with the same bug as the first one found. Those are not new scope. They are the whole of the original scope, minus the parts an old cost model taught everyone to skip.
The one part of the old arithmetic that still holds is the reading. Producing the extra tests and the extra documentation got cheap; establishing that any of it is correct did not, because that still costs a person their attention, one file at a time. So completeness is nearly free right up to the point where somebody has to review it, and past that point a thousand generated tests are not more thorough than fifty good ones — they are fifty good ones plus a review burden nobody budgeted for. What that means in practice is that the thing to do completely is the work itself: the edge case, the second call site, the documentation that was always part of the task. Volume for its own sake just moves the cost from the part that got cheap onto the part that did not.
The standard this argues for is not "good enough," because good enough was the correct target when completeness was expensive. It is closer to: if the marginal cost of doing it properly just dropped near zero, the honest question is not whether you can get away with less, it is why you would ship less than the whole thing on purpose.