No-code is always doomed to fail because the forefront of development always requires complex reasoning and understanding of leaky abstractions. I worked at one

No-code is always doomed to fail because the forefront of development always requires complex reasoning and understanding of leaky abstractions. I worked at one point with a business rules engine, and non-programmers are fine with a decision tree, but start introducing loops, queues, function calls with multiple parameters, database queries, or even complex logic in if statements and it gets hairy. It takes training to reason like that. It doesn't matter how nice the UI is, there's a fundamental level of complexity there that requires study and training that also induces anxiety in an untrained person. No-code can handle a significant percentage of work. In the system I experienced ten years ago I would guess 20-30%? In that case, we had close collaboration between developers and business people within the same building, and some of the business people were even willing to be trained in SQL (!). It's certainly useful in that regard, but it doesn't eliminate the custom stuff. The eventual interactions between the custom and no-code logics are something that requires balancing too.