This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?

I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.

First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.

The things that take up more time in software development just for engineers, leaving aside things that design and pms do.

• Coming up with that concrete design for a change (humans may do this in many ways, one of which is writing the code without a plan and refining)
• Architecting the system at all levels. This one is continuous and huge. A good architecture will easily adopt changes as they come, but you can never foresee all possibilities, and even if you could, there’s usually other people around you who can’t, which brings me to
• Communicating the system design and coming to consensus about aspects of it. This is mostly applicable to teams and is the primary reason individuals can often outperform entire teams. It’s also one reason why throwing a second LLMs at a problem doesn’t solve it at twice the rate. You’ll never get linear scaling
• Upkeep tasks: what needs to be replaced and fixed now, how do we best monitor and alarm to figure this out in the future.

There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.

Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.