* An IDE that knew anything; I literally wrote in Notepad
* Backup/restore procedures to speak of.
* Defined release/rollback procedures.
* Any monitoring beyond "walk to the server and look at the CPU monitor".
* Source control.
* 3rd party libraries.
* Cloud deployment complexities; one server, one deployment.
* A DBA or anything resembling one.
* Automated testing.
* A (solid) distinction between dev & production
* QA
* Cloud/reliable 3rd party logging.
* PII or other info control issues
* Security/compliance software, needs, etc.
* Documentation requirements
Many of these are only partially automatable by some service. Some are not automatable at all. Some you can automate to your heart's content but it won't matter because the user has an irreducible responsibility to use them correctly themselves, no matter how much you simplify it, like source control or writing documentation.
Last week one of my tasks was to dive into codebases that were 17 years old, and hadn't been touched in 12, and figure out what was going on and how to fix a new issue. At that point in time this company was a startup and certainly wasn't following 2022 best practices by any means, but at least they had source control, the source code was checked in, and it still built. (Very simple C programs, fortunately, single files with no external dependencies.) On the one hand, enough good dev practices that I could still pick up the pieces even if they are sadly deficient by modern standards, on the other hand, still more good dev practices than you can ask for from a non-programmer.
What does the equivalent of this look like for this "no-code" stuff? Who is going to poke through a big pile of stuff, where even if it is nominally "source controlled" or has a "managed DB" was not source-controlled well and the "managed DB" amounts to "well, when they guy who didn't understand DBs at all and was in fact aggressively told he shouldn't have to because this software Does It All decided he needed to add a column, it just went ahead and did it" and so and and so forth, is now a 10-20 year old pile of vendor-specific "no code"?
The intrinsic contradiction of the "no code" stuff is that we programmers do not have all this source control and testing platforms and QA procedures and deployment and rollback procedures and all of that other stuff because we are sticks in the mud who love process. We have all these things because we've learned the hard way they are necessary. I use them even on my projects where I have a single developer for maybe a month! And that's a tiny project, and they still save my bacon over and over. I look at my 1997 list in 2022 and both despair and laugh at what passed for a production deployment back then. For a modestly critical system for what is basically a ~50,000 person company. No-code trades short-term easier for medium- and long-term harder.
I can't even imagine what legacy no-code will look like and what a nightmare it will be. Without sarcasm, I'm sure it will make the 20-year-old, umpty thousand line Perl code base that I was also in last week look like paradise.
No-code is great for exploration of problems, and for all I may seem to be slagging on it here, I believe it has a place and it is worth exploring. But it is sheer foolishness to think it can "solve overworked IT department"'s problems. A no-code solution would be lucky to make it easier in the short term, but even if it manages that, the medium and long term graphs of difficulty are a nightmare. As a professional programmer, I'd LOVE to just be able to bash on code and not worry about backups and staging and rollbacks and QA and source control and all this other stuff. I'm not doing these things to gatekeep, I'm doing it because I need to!
To put it in physical terms, sometimes I think no-code is like someone passing highway construction and asking "What's with all these people? What's with all these machines? What's so hard about highway construction, it's just concrete on the ground, right? We don't need centralized planning and all this money! Let's just give shovels out to everybody and some cement mixers and turn them loose!" Well, you know, arming people with shovels and cement mixers can be very empowering in certain circumstances. But try to build a local city network that way and you're just going to reinvent everything you threw away, because it turns out trying to drive thousands of semi trucks a day at 70mph down a path some guys shoveled out and poured a bit of concrete over doesn't work.