Articles like this seem to keep highlighting a fundamental disconnect between what software teams really do vs what the people "managing" software teams a couple of layers above think those teams actually do.

The people up in the clouds think they have a full understanding of what the software is supposed to be, that they "own" the entire intent and specification in a few ambiguously worded requirements and some loose constraints and, being generous, a very incomplete understanding of the system dependencies. They see software teams as an expensive cost center, not as true the source of all their wealth and power.

The art of turning that into an actual software product is what good software teams do; I haven't yet seen anything that can automate that process away or even help all that much.