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.
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.
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.