It's just buzzword bingo. Complexity doesn't go away, it just moves around. Thinking about user interaction, product lifecycle, collaboration, knowledge pools etc. doesn't tie in to 'code' as a one-to-one, and if you swap out code for something else those still exist.
The problem isn't code, the problem is the ability to analyse the problem, formulate requirements and design a solution. How you express that is an implementation detail at best. This is also where the problem with the marketing of those tools lies: it pretends that when you don't write code, you also don't have to do those other things.
Ultimately this is just the same balance you get everywhere else. You have operating systems, tools, interfaces, frameworks, languages etc. that all do various things. Depending on what things you need to do and how novel they are you might be able to use and re-use existing systems, and you'll be adding to the same generic pool of applications that already exist. This is where automation-of-automation shines, depending on the level of genericness.
Regarding problem solving, again, not code-related, you can solve problems in a conversation, on paper, using calculations etc. Yet any anti-code product is marketed as being able to avoid those, but that is not how problem solving works.
Now, if we bring this all together a bit I find a question popping up: is this whole thing actually solving problems that exist? It's very easy to see a 'problem' if you're working in a bad workflow. But the 'problem' that is seen then often isn't the actual problem, but just a symptom. So now we are not solving a problem but 'solving' a symptom. This happens whenever someone is set to 'fix' something but doesn't actually know how to find the problem and then find the solution.
Long-winded Example:
Joe and Bob work at different companies. They need to exchange a bunch of rows of information and they do this by exporting a database table from some web app to a CSV file and emailing that.
Joe (Source) uses some Database GUI with an 'export' button, grabs the file, puts it in an email as an attachment and sends it to Bob.
Bob (Destination) receives the email, downloads the attachment, goes to his Database GUI, uses an 'import' button, points it to the file he just downloaded and now his task is complete.
Joe and Bob won't want to constantly drag and drop CSV files, so they come up with a plan to use LowCodeNoCode Creator Studio XP Edition to automatically export the CSV, email it to a predefined email address, process the email, download the CSV, and import the CSV. From their perspective, they solved the problem! Without writing code!
From a problem's perspective: the symptom is now hidden and the problem is made worse because nobody knows how this process works, why it exists, who did what, and how to manually intervene. On top of that, the real problem still isn't solved. Even the argument that "there is no code so anyone can find out how it works" doesn't hold up because while you don't need to learn some syntax you swap that problem out with learning some tool.
The real problem is Master-Slave table replication, and if we analyse it one level deeper: messing about with a database table that is owned by an application. If you want to interact with data that is owned by an application you don't go messing about with the underlying persistence store, you use the application and if needed write an API extension that does the job. Heck, that API probably already exists in any modern application! But then you'd actually have to know how systems work, how to resolve requirements and how to come up with documentation and scoping and the foresight of future endeavours.