This idea gets recycled every generation. I can’t count how many “low code” no-programming-skills-required tools I’ve seen come and go in the last four decades. Both COBOL and SQL got presented in these terms. I’ve yet to see a “non-technical manager” write a non-trivial SQL query, much less know how to confirm they got the correct results. The various 4GL tools that proliferated in the 90s led to complex amateur spa…
So third paragraph contradicts things written in the second.
Low-code tools promise to address "problem of the language" so it is easy to translate business knowledge into the tool. Keep in mind low code tool should ideally be used by domain expert, so another promise is that you don't need business analysts and developers so problems with communication or misunderstanding is removed.
Going back to second paragraph:
Good part that was noted, there were loads of spaghetti apps in Access and File maker, let alone all those Excel sheets that are still everywhere. There was no one to maintain them and low code tools don't provide enough means for maintaining complex systems.
Running and maintaining computer systems is 80% of cost for software, maybe translating it into code is hard, but debugging, fixing, adjusting, keeping operational knowledge is much more expensive.
Silly Excel file that architect Jane was using for 5 years and then she quits, you hire John while you can do knowledge transfer - it is still hit or miss just as noted in second paragraph John will be more comfortable doing his own excel from scratch than learning what Jane did.
Even with developers it is the way that everyone wants to do "greenfield" and understanding what other people wrote before in some unfamiliar system is hard work. Low code even makes it harder to understand existing stuff with their GUIs.
Whole DevOps tooling/movement grew just because of that fact, none of the "low-code" tools is addressing it.