Low-code is just good libraries and good frameworks. My hot take is that anything “low code” beyond that is just an aggressively user-hostile config interface.
Most(all?) self code self-hosts, which is extremely valuable. There no shortage of smart people who can creat complex tools (see Excel for examples) if hosting it wasn't currently such a ridiculous prospect.
My version of low code is writing HTML pages with a big script element full of vanilla JavaScript, and putting them in this one git repo we have which gets deployed to a web server.
Obviously it's not actually low code, it's 100% code, but it creates a space without a lot of the complexity and ceremony of 'real' software development. I don't write tests, I don't future-proof, I don't set up deployment or monitoring machinery, I don't worry about anything except solving a small, well-defined problem quickly.
It's definitely not a good approach to everything. But it's quite common for one of my users to say something like "I need a dashboard showing how the current reactor temperatures compare to the averages for yesterday, and also the available cooling water for each one", where that's all data we have existing websocket feeds for, and I can get that to them very quickly without it becoming formal feature development.
Lack of testing and monitoring means the products often break. But when they do it's typically benign - the page doesn't load, or shows no data, and if a user needs to use it, they'll complain, and I can fix it.
If a page ever got too complicated, or too critical, I might want to port it onto real software. But that hasn't happened yet.
Reactor temperature monitoring is surely the exact area of software engineering (along with medical software) where you'd want the most robust processes isn't it? If your solution says everything is fine when in fact it's not, someone will have a big problem on their hands.
I'd argue that is actually the hard part of software engineering. Sure, I can learn the basic syntax of a new coding language in a week or so, but learning all the deep frameworks to do non-trivial stuff, conventions, deployment, and how to diagnose bugs can take years to become expert at.
Much of this feels like needless complexity, but its ubiquity in almost every stack points to something fundamental, in my opinion: the classic 80/20 rule. That last, irreducible 20% complexity is where the dragons lie. Expectations for software have grown, and boundless flexibility is table stakes.