Perhaps I've just misunderstood the point, but it seems like a nonsensical argument.
Do we always have to build it before we know that it will work (or, in 9 cases out of 10, that it will not work)?
Even more so, do we have to build a fully-fledged version of it to know?
If yes, then I agree, development is the bottleneck.
Disregard parts that explicitly assume that they are relevant only because, in 2013, development was expensive. There are very few parts that you would throw out.
That sounds like an awful way of software design. Trial and error isn’t engineering but explains the current state of software security.
What would you do? Don’t change?
The effort it takes to implement a feature makes is more likely you think twice before you start.
If the effort goes to zero, so does the thinking.
We will turn from programmers to just LLM customers sooner or later.
Because testing if it works can be done by none programmers
like testing whether a building is structurally sound can just be done by the inhabitants!
It is telling that, while the article's theme is product management (and its relationship with the pace of development), that context is largely ignored in some comments. It's as if the article's scope was purely what happens within the IDE and/or AI agent of choice.
The whole point is that the perspective necessarily should be broader. Otherwise, we make it a circular argument, really: development is a bottleneck of development.
Well, hard to disagree on that.