I think he is saying, I hope he is saying, that software has never been writing software, it has been communications with people over what the software should be, needs to be, and the entire point all along has been to achieve better collaboration with people, and implied: to achieve their collective goal. He spends a good amount of time on how slow writing software has been in the past, and that allowed the industry to over focus on the software writing. While it has been pointed out a number of times by milestone books our industry embraced that it is the communications aspect of why and what we write that is the most important. Finally now that is being forced upon us because writing code is now automated, and all that is left is the specification and the communications with humans over what and why.

The author argues that writing code cannot be a bottleneck because work always fills up the allotted time. Developer teams should instead focus on doing less and writing better specifications.

The error in the reasoning is that while you can increase your resourcing to tenfold and gain nothing in return, the inverse is not necessarily true.

I think the point they're trying to make is that context known by humans and the requirements they agree on, is 'the' bottleneck, rather than implementation