I think most people on HN are building large applications that are supposed to be highly scalable, ready to have hundreds or thousands of users.
Low code tools are often aimed at applications used by 1-2 people to perform some simple business process which would otherwise be done by paper and a spreadsheet. These users never get applications built for them because the IT team has a long list of priorities for development which come before dedicating time to make the lives of some low-level administrative clerks easier.
I built a simple billing tool in Retool in an afternoon which one person uses but which we could have never approved an IT team working on. The tool I built probably saves them 20% of their time, but if we went to IT they would have said that a proper tool built from scratch would probably take a team a few sprints to build and would have had a very long ROI because IT teams cost more than one administrator. IT teams do not want to spend the resources of several engineers to save the time of one administrator anyway.
So a key benefit of Low-Code to me is that problems can be solved in low-code that otherwise will go unsolved because IT teams don't want to / can't commit the resources to solve them 'properly'.
Ask those same developers if they'd want to use code for everything an experienced finance or accounting person uses Excel for. You can -- and there are cases where you should in fact be using Python or R. But generally, no. Excel is the perfect tool for its (very large) market niche, and all this current low / no code trend amounts to is people searching for more market niches.
And within that umbrella, some of them are relevant to the HN crowd.
Your examples, like spreadsheets for supply chain planning or DAWs for music production, are indeed disconnected from what developers touch. Your Ableton projects don't concern them.
But other times, the tool very much impacts developers. For instance, I work on https://www.plasmic.app, which lets marketing teams build landing pages and other content on React websites. Here, the stakes are higher when it comes to page performance, design system consistency, component reuse, and so on. As such, developers heavily vet the tool, similar to picking a CMS, and virtually all of our customer adoption was driven by developers.
So relevancy to devs depends entirely on what specific tool/use case you're talking about.
The HN crowd is not the target, so do not expect to understand it. in fact, you should expect to NOT understand it.
I’d say that no-code tools are made with the same mindset as spreadsheets: to put into the hands of non-engineer specialists (accountants, marketers…) a subset of what engineers can already do without said tools.
it’s democratizing a (small?) part of the engineering mindset. As such, it is not a threat to engineers at all, as most of the difficult tasks of engineering are still unavailable (or hardly available) within the reach of these no-code tools.
I do not care that this or that tool is Turing-complete. Actually, I find it a vanity feature and it makes me smile at best.
Some no-code tools may very well succeed someday in some non-software engineering communities, and I wouldn’t feel threatened.
When you think about it, the music production tools have had such tools for ages and no engineer was hurt in the process.