Although no-code platforms allow more people to create applications, they will never completely replace writing actual code because of two reasons. First, at some point in the stack there has to be code that can run on a CPU. Second, for the vast majority of cases, writing actual code is faster and more concise, if you know what you’re doing.
There are certainly benefits that no-code platforms bring to the world. Not only can it make the job of creating yet another CRUD app for a random internal business process easier, but it also allows more people to do it. I feel like there is a vague notion that the rise of no-code platforms will mean fewer jobs for software developers, but that cannot be further from the truth. In any case, it allows more people to get into software development by easing them into a logical way of organizing digital actions and information. For the CRUD apps that no longer need to be created, it will hopefully give more programmers a chance to get out of a rut that they may have found themselves in. Perhaps they can work on internal process builders for their company, and once their no-code tools (written with code, of course) get in the hands of users, there’s sure to be no shortage of edge cases that require additional “real” programming work to improve.
Let’s talk about the first of the two reasons I mentioned at the beginning. It’s kind of like the chicken and egg problem. If the egg came first, there must have been a chicken to lay the egg. But that chicken had to come from an egg, and that egg had to come from a chicken, and…" Likewise, a no-code platform might have been created with a no-code platform, but somewhere along the line there has to be “real” code that created the no-code platform, and if there’s “real” code, it will have to be maintained. Just think of how much we hear about something being hacked, often due to mistakes in the code. Those mistakes will need to be corrected. If we can’t even write “real” code without problems, any no-code platform built from a no-code platform is just going to be a propagation of those errors. You can’t have no-code platforms without code. To correct the analogy, we might have to say that a chicken can give birth to another chicken, but somewhere down the line the first chicken must come from an egg. Okay, maybe the analogy doesn’t really work, but you get the point.
You can take it really far down, all the way to the CPU, where you have to run something that can make simple decisions. Even if those decisions come from a drag-and-drop builder, it’s inherently code for what the CPU should calculate. And if it’s code, and I’m using that word as in “code word” or “instruction”, it can be expressed in more than one way, one of which is the code we all know and love, which brings me to the second reason.
Writing “real” code, it’s possible to express what you want to achieve in a concise manner, and you can express it quickly. Sometimes you might use a general-purpose programming language, and other times it’s a domain-specific language. For any use case that can be solved using no-code tools, writing the equivalent code, if you have done something like it before, is almost always faster. For example, to fetch and process some data from an HTTP API for use in a random task, it’s probably faster to write a Deno script than it is to fire up a no-code editor and do the same, especially when it comes to the data manipulation part. If a no-code tool is flexible enough for all use cases, it slowly becomes “real” code. I’m thinking of building blocks like loops and conditionals, where if concepts like those are introduced into an editor that allows you to move them around, it’s pretty much “real” code at that point.
Of course, that’s a simplistic view of no-code tools, and they’re more likely to be abstracted a little so that for some particular use case, it is more efficient to use the tool than to write the code by hand. There are therefore two things that no-code tools optimize for. The one I mentioned previously, allowing more people to program, is one. For this, a drop-and-drop editor that kind of resembles code is an okay goal to shoot for. If the no-code tool is trying to make itself the choice for a particular task, such that it’s simply better than writing the actual code regardless of who is using it, then that’s where they tend to be a little more thought out.
That’s my prediction: no-code tools cannot replace code, not because people don’t want to lose their jobs, but because it’s not possible to replace code. There has to be code somewhere hidden in those tools, and with the right talent, code provides a flexibility unlike any other to create anything out of nothing. Yes, a no-code platform could slowly introduce the ability to make more and more things, but a single tool doing more and more would eventually just be code. It’s a continuum.
Now, if we’re talking biological computers, then no-code might be the norm, but I think it’s fair to say that “no-code” in marketing speak does not imply some kind of biological computer.