The fundamental problem with no-code/low-code products is that they are a solution to the wrong problem. To an outsider, code is basically indecipherable. Just

The fundamental problem with no-code/low-code products is that they are a solution to the wrong problem. To an outsider, code is basically indecipherable. Just like weird math symbols, bizarre physics equations, scientific jargon, etc. Because they don't know how to read code (or substitute in any of the other examples I gave), the outsider assumes that that's the hard part: "If the code/jargon/equation was simply in plain English, anybody could program/do science/understand math". But they're wrong. Anybody who spends enough time to pick up the actual underlying skill (whether it be programming, mathematics, or science) will trivially pick up the language of the trade, which, on the whole, exists because it expresses complicated ideas in a convenient way. The hard part of programming is solving the actual problems, not expressing those solutions in code. Likewise, the hard part of electrical engineering isn't reading circuit diagrams, or the hard part of being an author is knowing English. Thus, if you want to make programming your system easier, you don't throw out the idea of code. You solve as many of the hard problems as you can, and then supply those solutions as a library.