Development speed is not a bottleneck

It reads like the author never debugged a program. Development speed is not just the time to write code, but also test, stabilize and debug it, with most of the latter being a risk that might cost you a lot much later. If your engineers have to take a two hour or two day or two week timeout to debug issues from weeks, months, or years back, then that really costs as development time.

Vibe coding is going to make this so much worse; the tech debt of load-bearing code that no one really understands is going to be immense.

Oh, development sure does mean the whole package. Architectural design, automated tests, coding, refactoring, code review and post-review changes, deployment, manual tests, etc.

A question: what if all those activities are to build a feature that will harm user retention or a product no one wants?

A follow-up question: what if we could have known that up front, or there was a simple way to learn that?

Because so often we build stuff that shouldn't have been built in the first place (appalling startup success rate is probably a good enough statistical measure of that). And yes, there are ways to learn that we're building the wrong thing, other than building a fully-fledged version of it.