Low-code and vibe coding make software development more accessible than ever. But not every application is suitable for every approach. When is it best to use which technology?
Low-code and vibe coding offer increasing possibilities for developers and can accelerate business processes. Yet there are also pitfalls: from license lock-in for critical applications to the loss of control over exactly what AI is building.
“The choice between low-code or vibe coding depends heavily on the context and application,” says Dirk Deridder, CTO at Smals, during a roundtable organized by ITdaily. How do you harness the potential of these rapidly evolving technologies without getting stuck?
Also at the table are Bjorn Boisschot, Quality Engineering Manager at Cegeka, Stijn Lambrechts, Global Delivery Lead Applications at Cegeka, Pieter Vercammen, Solutions Architect at Mendix, and Ron Pooters, Director of the Microsoft Innovation Hub in Brussels.
Green letters
“Low-code has existed for more than 20 years,” Vercammen begins. Yet many organizations run into an adoption problem. Vercammen is happy to dispel a stereotype here: “Many companies think that real software is only made by seasoned developers, or people sitting in a room staring at green letters,” he says with a laugh.
Low-code remains a matter of evangelizing.
Pieter Vercammen, Solutions Architect at Mendix
He notes that most customers who get over the adoption threshold for low-code come out successful. “But it remains a matter of evangelizing.”
Critical applications
Not everyone chooses this path, and there are reasons for that. “We don’t use low-code, and that is a conscious choice,” says Deridder. Although they looked at the possibilities of low-code with great enthusiasm, they took a different path with Smals. According to Deridder, this has to do with the type of application.
The context determines which technology you choose.
Dirk Deridder, CTO at Smals
Smals primarily builds large back-office platforms with many transactions, and according to them, those use cases do not lend themselves well to low-code. “In addition, the government works on a completely different time horizon than an average company: applications must last 30 years or longer. Commercially, a lot can change in two decades, and that weighs into every technology choice,” says Deridder.
Vercammen, on the other hand, does see potential in low-code for large applications. “We see business-critical applications being made in low-code. Every package delivered to your door by PostNL is built entirely in a low-code-based backend. That is a myth that needs to be debunked,” he believes.
License lock-in
Lambrechts agrees with Deridder’s point. He notes that lock-in with low-code does not lie with the implementation partner, but purely at the licensing level. That is exactly what customers are afraid of. “If you have built a complex and business-critical application that needs to last up to 20 years, you cannot leave without a heavy investment when the licensing rules are changed,” says Lambrechts.
The lock-in with low-code is not with the implementation partner, but at the license level.
Stijn Lambrechts, Global Delivery Lead Applications at Cegeka
He argues that custom development offers more control: “the license cost is virtually non-existent, and you can be more flexible with infrastructure. The downside was always that you needed more man-hours for it, but that argument is losing ground now that AI is accelerating development.” Lambrechts therefore expects that custom development will become more attractive again.
AI as a catalyst?
According to Vercammen, however, AI is increasingly providing a solution there. “What we are seeing now with AI is that replatforming from platform A to platform B is accelerating enormously.” The possibility of migrating away thus becomes less of a theoretical guarantee and more of a practical reality.
Yet he immediately adds a nuance: the long-term viability of AI providers themselves is not a given. “Billions are being burned by many software companies. OpenAI loses more per month than the Belgian budget deficit on an annual basis. At some point, you do ask the question: is that a sustainable solution in the long term?”
The migration facility of AI thus partially solves the lock-in issue, but at the same time creates a new dependency: that of providers whose business model is far from proven.
Runtime
Independence from the runtime environment is a hard requirement for Deridder. “We want to be able to run applications even after there might be problems with the provider. Platforms that align with an open ecosystem, such as Java, offer more autonomy and flexibility to port to another runtime later,” he states.
The same logic applies to AI, according to him. “As long as AI is only used to generate code or static programs, the token costs at runtime play no role. As soon as an application needs an AI system at runtime to make decisions, the context becomes decisive.”
‘AI-ifying’
Boisschot adds further nuance. Using AI for something that is deterministic is pointless, according to him. “If one plus one is two, why are you asking an LLM? The danger is that companies want to ‘AI-ify’ everything, while half of it is useless or simply costs a lot of money.”
In addition, he warns about the difference between human in the loop and human in control. One means that a human is involved somewhere in the process, the other that the human retains the final decision and monitors quality. Anyone who ignores that distinction takes a risk.”
Deridder also recognizes that difference. The human critical eye remains indispensable. “Especially with critical systems, such as healthcare or social security, the human must ultimately make the final decision. Accuracy and explainability are too important there.”
Don’t fight the technology
Low-code and vibe coding are therefore not equally interesting everywhere. Deridder emphasizes that context remains important. However, that doesn’t mean you can’t work with them. Vercammen already referred to successful applications with low-code, and vibe coding also offers added value to speed up processes, “as long as it is not in the runtime,” says Deridder.
“The last thing you should do is fight the technology,” Pooters states. The tools evolve faster than organizations can keep up, but that should be no excuse for standing still.
The last thing you should do is fight the technology.
Ron Pooters, directeur van de Microsoft Innovation Hub in Brussel
The challenge is not choosing between low-code, vibe coding, or bespoke development, but understanding when each approach fits and building a well-thought-out strategy around it. Because as Deridder summarizes: “Those who started yesterday definitely have a head start.”