Low code approaches have limits because the real problem has never been the code but the analysis and specification that has to be done (explicitly or not) befo

Low code approaches have limits because the real problem has never been the code but the analysis and specification that has to be done (explicitly or not) before code can be written. The reason most people can't / don't want to develop software isn't because they don't know the syntax of some programming language (that's the easy part) but because they can't / don't want to learn how to break down their problem into small parts and precisely explain to the machine how to solve it. The only real way to "fix" that is for the tool to already know a lot about the problem domain but that means the tool is limited in scope and things become a lot harder once you try to go outsinde the things it's designed to do. Executable specifications face the same problem. Seems like a great idea in theory to get the client / stakeholders to write a specification in a form that can executed to show the system does what's wanted. But very difficult to get them to do it. They come up with all sorts of complaints about the tooling but the real problem is that they don't want to precisely specify what their requirements are including edge cases but be vague and handwavy...