Obviously the trick is in the difference between exact and fuzzy specifications. As a software engineer I could say my main job is to translate approximate specifications of business needs into a list of specific instructions on how to solve them i.e. code that can run on a computer. We'll probably have better tools and more efficient abstractions to do so but we'll still have to write some code.
I guess the "no code" topic could better be treated as "years of experience vs. hours of training". During my first job I once had to use a graphical programming tool to design and run computer simulations of a power plant: just connect some predefined building blocks, input some simulation parameters in each block and voilà! Except that the simulations quickly started to require hundreds of said building blocks, so that my coworkers spent their days clicking around only to start over when we needed to use different simulation parameters. Got trained a few hours on how to use the graphical tool but couldn't accept I now had to click and input numbers all day long... Somehow found that an old user manual actually existed and discovered that I could instead write plain text files to specify the computer simulations. It used a very verbose ad-hoc language so I wrote a Python script to generate the files I needed and when the requirements changed I could redefine the simulation in minutes instead of days. Later got fired for being some sort of troublemaker but I now work as a fullstack dev in Python and Javascript.