Low code gatecrashed the corporate landscape in the 2020s, growing faster than anyone expected. At first, we thought, “Well, it’s a cute little thing—let the users play at being programmers as long as they don’t get in the way.” Fast forward to today, and everywhere you look, even the most serious enterprise solutions are expected to have at least some low-code elements.
But why?
The hype really took off in 2021, when Gartner declared, “By 2024, 65% of all applications will be built using low-code technologies.” That stat spread like wildfire through every CIO chat group.
It’s easy to see what fuelled the buzz: COVID hit; everyone suddenly needed to work remotely; IT teams were stretched thin, and people were plugging holes with whatever tools they could find. Low code appears to get the job done—you just throw something together quickly, launch it, and the business is happy. Nobody was really thinking about how they’d have to support, upgrade, and maintain all this stuff down the road.
But here’s the thing: all the COVID-related fuss is long over, yet—according to Google Trends—interest in low code is still going strong.
Source: Google Trends
That’s odd, because it doesn’t really line up with what’s actually happening out there. The facts are that as follows: as of 2024, only 15% of enterprises are using low-code platforms for mission-critical applications—this is straight from Gartner themselves. Yet, in the same breath, they predict that by 2029, that number will skyrocket to 80%. Sure, we’ll believe it when we see it! (See source.)
How I Fell for Low Code (and Fell Out of Love)
Don’t get me wrong—I have nothing against the idea of low code as such. In fact, there are plenty of cases where this approach really shines. Take batch scanning, for example: it’s a clear, well-defined tech process, which is practically made for low code automation. Remember Kofax? That was pretty much the perfect tool for batch document scanning. The workflow was hardwired: Preparation – Scan – Recognition – Validation – Verification – PDF Generation – Export.
Everything was set up visually, and if you needed more, you could write a bit of script, something like Visual Basic. I once sold this solution to IKEA to digitize their paper financial archives, set it up myself, and supported it for a few years. This was around 2006—back when nobody had even heard the term “low code.” But that’s exactly what it was. And what about all the classic low-code pitfalls people run into today? I saw them all in that little project.
It started with the business getting fed up with digging through piles of paper to find invoices or delivery notes from five years ago. As usual, IT had no resources for the project. So, we took the classic “guerrilla” approach to bringing low code into the organization—through a specific business need that IT couldn’t or wouldn’t help with. And, as often happens with low code, we got quick results—bam, it worked! And then we got a full serving of all the typical low-code headaches.
First, the local IT team wanted nothing to do with supporting Kofax—some weird tool used by one department? No one was going to dedicate a specialist to figure it out. At least they didn’t ban it outright. Then, one day I show up—and everything they’d scanned over six months is gone. The drive with the archive just disappeared. I go to IT—they shrug their shoulders. “It’s not our system, not our problem.” Later they admitted they’d accidentally wiped it—it wasn’t their responsibility, after all. So, we scanned everything again.
Of course, there was no documentation for the solution. As soon as the business saw the price tag for documenting, they cut that entry from the budget. At the time of setting it all up, that wasn’t a big deal—the product itself was well-documented, and I kept the configuration in my head. But a year or two later, I couldn’t remember what magic I’d created. If something broke—like when documents came in on different paper stock—I basically had to reconfigure everything from scratch.
All that said, low code is a solid technology. It just needs to know its place.
Low-Code: A Cheeky Term
Marketers were quick to spot the gap between what businesses wanted and what IT could deliver. In 2014, Forrester analysts gave this gap a catchy name: ‘low-code’— and promised that now anyone could build systems without programmers. Business leaders believed it, and for a while, it worked.
But what’s really behind this promise? Low-code doesn’t eliminate programming—it just changes its shape. When you, for example, drag and drop a “Send Email” block, you’re simply calling a pre-written wrapper around an SMTP client. Everything’s already been done—just not by you. But as soon as you want to deviate from the standard scenario, you have to write your own code—not in a familiar IDE, but in some proprietary editor.
Low-code hides complexity, but it doesn’t eliminate it. The architecture and behavior of your system are dictated by the platform. Simplicity comes at the cost of flexibility, and sometimes configuring is harder than traditional programming. The moment your requirements go beyond what the visual designer can handle, you end up fighting the platform instead of building your application.
Still, some kind of aa miracle happened in the market: yesterday’s vendors of ECM, BPM, CRM systems, and 4GL languages suddenly rebranded themselves as low-code pioneers, and the market was flooded with a number of low-code platforms. Of course, nothing really has been changed inside—they just updated their slogans.
The Forefathers of Today’s Low-Code Platforms
Technically, low-code is built on the same foundations as the tools of past decades: visual modelling, templates, configuration instead of programming, and a declarative approach. We’ve already seen all this in the RAD platforms of the 1990s, 4GL languages, ERP systems, and DSL frameworks. Even Excel with macros has features reminiscent of low-code.
In other words, low-code is not a new technology. It’s a new packaging of an old idea. Here are a few examples to illustrate the point:
- VisualAge was a series of visual development environments from IBM in the 1990s that allowed users to build applications by dragging and dropping components and generating code—long before the modern low-code platforms appeared on the scene. The most famous version, VisualAge for Java, later became the foundation for the Eclipse IDE. Although VisualAge was ahead of its time with its visual programming concept, it was too heavyweight and developer-oriented to become a truly mainstream solution.
- Visual Basic appeared in 1991 as a rapid application development (RAD) tool from Microsoft. The word “visual” in its name highlights the platform’s key feature—visual design of user interfaces by dragging and dropping elements (buttons, input fields, lists) directly onto a form, which greatly simplified UI creation compared to traditional programming. Despite the convenience of visual design, Visual Basic is not a low-code platform in the modern sense, since implementing business logic and application interaction still required writing code in the Visual Basic language.
- PowerBuilder is one of the veterans of the rapid business application development world, born in the early 1990s at Sybase and long considered a dream tool for corporate developers. It was a powerful visual form builder with its own scripting language, enabling the creation of complex client-server applications much faster than coding everything from scratch. PowerBuilder is still alive and supported today though in the era of clouds and low-code platforms, it’s no longer at the cutting edge, but for many organizations, it remains a reliable workhorse with a rich history.
This image was generated by ChatGPT, but boxes look almost real! That’s pretty much how I remember them. By the way, I still have a VisualAge box lying around at home—a leftover from old stock. It’s a real collector’s item now!
As we can see, the history of low-code began long before the term itself appeared. VisualAge, Visual Basic, PowerBuilder—all of them, in their own way, aimed at simplifying development, hiding routine tasks behind visual tools, and shortening the time to a finished product. But each had its limits: as soon as you faced non-standard requirements, the developer still had to “look under the hood.”
Today’s low-code platforms have inherited that same duality: the promise of simplicity—and the hidden complexity that emerges at the next level. The only real difference is that now, the old idea is wrapped in a modern marketing facade and a whole methodology of digital transformation. New terms, old mechanisms—and the same old problems.
What if you go completely code-free?
Following the rise of low-code, a new wave emerged—no-code, as a more radical version of the same idea. In essence, it’s the same approach, just taken to the extreme: absolutely no code, not even a hint of programming. Just a mouse, ready-made blocks, a visual editor, and the dream that now the business can build whatever it needs on its own.
The idea sounds appealing: any employee can assemble a working application, automate a process, or create a simple CRM. The reality, as usual, is different. As long as the task is simple and straightforward—like building a landing page in Tilda, creating a survey in Typeform, or setting up an integration in Zapier—everything works. But as soon as the business process goes beyond the capabilities of the builder, the real challenge begins: missing APIs, insufficient logic, lack of validation, and so on. Most importantly, there is no real understanding of how things actually work.
No-code creates the illusion of independence from developers. But rather than making developers unnecessary, you simply end up needing them later—often to fix, rewrite, or integrate whatever was quickly assembled. Instead of removing technical debt, no-code solutions quietly allow it to build up behind the scenes.
Low-code is at least honest: you have to code anyway, but a little. No-code promises that you won’t need any at all. But they forget to mention that you won’t need code only until you want something real: scalability, version control, testing, complex logic, security.
Fortunately, businesses haven’t fallen for this trap, and no-code hasn’t found a place under the corporate sun. Its niche is quick-and-dirty solutions that don’t aim for anything serious—building a small website, automating a simple process for a small business, and so on. In short, you can forget about no-code if we’re talking about serious systems.
The Less Code Paradox
I don’t think I’ll surprise anyone by saying that most developers can’t stand low-code and everything associated with it. What’s especially ironic is that these same developers love tools that save them from repetitive tasks and boilerplate code, and they eagerly use high-level abstractions to write less code by hand.
Still, the amount of code in large projects doesn’t actually decrease—after all, you can’t describe complex things in just a few lines. What has changed is that developers no longer have to spend time on monotonous work: libraries, smart IDEs, frameworks, and now AI assistants take care of the routine, letting developers focus on truly interesting problems. But I’ll talk more about AI capabilities another time.
Take Lombok, for example—isn’t it low-code? A few annotations replace the tedious typing of constructors, getters, setters, and other boilerplate stuff that your code simply can’t run without. Lombok saves hundreds of lines and hours of work, and it does so at the language level, while remaining transparent to the developer. IntelliJ IDEA offers something similar, letting you generate all that boilerplate with just a couple of clicks—which is great, because it gives developers a choice.
And what about the mighty Spring framework? It truly encapsulates complexity and takes over bean management, but in return it offers developers clear rules and a rich set of features. It says, “I’ll set up the environment for you, connect the necessary components, and handle transactions—just describe what you need, not how it should work under the hood.”
So, modern tools are all about helping developers write less code and think more. In fact, these tools should have rightfully been called “low-code”, but the term was already taken. As a workaround, the term “less code” was coined—not as catchy or transparent, but at least honest. Less code is about saving effort without pretending that code is no longer needed. It’s about raising the level of abstraction, automating routine tasks, and focusing on expressiveness. Developers still write code, but they do it faster, cleaner, and with the help of powerful tools: DSLs, templates, generators, annotations, smart IDEs, and so on.
The fundamental difference between low-code and less code is this: with low-code, you really do write very little code, but everything else is a “black box”—platform components you can’t inspect or modify. With less code, everything is code, whether written by hand or generated by tools. Even the framework itself is code, you can read and modify it if necessary.
After that, you compile and run your application, just like you would with a simple “Hello, world!” In contrast, a low-code application runs in its own runtime environment, which you also don’t control.
So, unlike low-code, less code doesn’t promise that anyone can “build an app in an evening.” It simply says: you’re still a programmer, but you’ll save time on repetitive tasks. And that’s an honest deal—no misleading promises, no loss of control.
The irony is that real progress in software development is happening along the path of less code, not low-code. But the market loves flashy names, and “low-code” sounds more revolutionary. In reality, though, it’s more about rebranding than real change.
Conclusion
Low-code is neither evil nor a panacea. It’s a tool—a good one, in the right hands and with the right expectations. The problem isn’t that it exists, but that it’s been credited with too much: simplicity, universality, speed, independence, even a kind of revolutionary potential. But these are all marketing illusions:
1. The Illusion of Simplicity
Low-code seems simple—until you step outside the boundaries of its visual tools. The complexity doesn’t disappear; it just goes into hiding. But it always comes back, often with a vengeance. Yes, low-code lowers the barrier to entry, that’s true. But sooner or later, you’ll still have to dive deep into the proprietary product.
2. The Illusion of “Citizen Developers”
Low-code promises that anyone can succeed—that any specialist can become a citizen developer. In reality, professional developers still get involved: maybe later, but always on call. They come in to sort things out, fix, or rewrite. In theory, you could set up a division of labour between citizen and professional developers, but in practice, this is rare.
3. The Illusion of Speed
Low-code claims that everything can be done quickly. That’s true if your scenario is standard. But for non-standard tasks, things get complicated: configurations, platform limitations—all of this eats up time. Think ahead about where low-code is applicable, so you don’t get stuck in a project forever.
4. The Illusion of Low Cost
Low-code lures you in with a low-price tag, but that works only at the beginning. The real cost for an enterprise project can be quite substantial. Licenses, customization, integrations, and training quickly turn “cheap” into “not at all.” Make sure to estimate the total cost of ownership before jumping into a low-code solution.
5. The Illusion of Universality
Low-code claims to be suitable for every situation. Actually, it is not. This technology is great for automating simple processes or building prototypes. But using it as the core of a corporate system is a recipe for disaster.
6. The Illusion of Simplified Maintenance
Low-code offers its own deployment and delivery tools. That’s great—until you need to integrate everything into your corporate DevOps pipeline. That’s when the real fun begins. Mature platforms partially solve this problem, but the cost of integrating with DevOps remains high.
7. The Illusion of Revolution
Low-code arrives as a cutting-edge technology. In truth, it’s an old idea with a new name. RAD, 4GL, visual builders—all of this has been around before. Low-code just has better marketing.
Therefore, the main advice is this: don’t be tempted by illusions. Use low-code where it truly makes sense. But when reliability, scale, and flexibility are required, it’s better to stick with professional less code tools.