I see it differently.

I see the low-code stuff as an opportunity to let the business-folks handle the usecases where the complexity is low, and value of rapid iteration with deep domain-knowledge is more valuable.

Also, they might get a better understanding of why the code stuff might make sense when stuff is actually getting complicated :)

I can imagine a few instances where giving a node-editor to business would have been a way better solution than having us re-implement it in code continuously. That said, that was always in the context of a larger, domain specific piece of software. Where I think low-code falls flat is trying to be a general purpose programming tool, which means for someone to do their domain specific tasks, learning how to make a general purpose program from scratch is a big ask. I think low-code editors should focus on this portion of the user's journey. Getting data in, data storage, manipulation, image processing, reaching out to APIs, all that stuff needs to be as easy as possible.

Low code isn't about tinkering under the hood. It's about going places.

Most cars have automatic transmissions now. Cars don't have manual chokes anymore. They're reliable enough now that most people don't need to know anything about repair, engine or otherwise, whereas that used to be widespread knowledge.

Yes, I agree. I thought that was obvious in my response. Modern cars are "low code", so mechanics don't need advanced degrees to fix them. Also: "the complexity is eventually abstracted away", which is exactly what you are saying.

Most cars do exactly the same thing, while programs there are not two the same.