COBOL was taught to me as a programming language that can supposedly be used directly by business than business telling programmers and programmers writing the code. For people who have never tried COBOL, you write programs called “Essays” with “Paragraphs” and with a lot of capital letters and leaving whitespace margins on the left. The software industry always has this fascination towards no code technology, it wants the business to be able to create software that is not lost in the translation. Which clearly proves the point that building software is not a technology problem but a communication problem in using technology.
The closest any one getting to success with a no code tool is none other than the infamous excel sheet. Why did it succeed? It succeeded because the data, formula and output were close to each other with a very small learning horizon. Business people who started using it turned it into a personal software that does a lot of things for them but is not useful to put to use even in simple production scales or customise it for others. I have been given excel sheets during requirements phase and asked to transform that into a software that can be used and extended as well. So though it worked, it could not scale to be a full fledged software.
Rather than concentrating on no code solutions as a means to cut down programmer involvement, it should be seen as a powerful tool to enhance communication with programmers on what business is looking for.
Quick prototypes could be made both by businesses and programmers using no code/low code solutions that can shorten the learning horizon. Learn quickly from prototypes and then take it production grade at required scale when you learn from it. Isn’t this what agile manifesto is saying for last 20 years. Produce working software through emphasis on individuals and interactions, respond to change and have business collaborate well with programmers.