Itdaily - Low-code, vibe coding of toch zelf bouwen: de context is bepalend

Low-code, vibe coding of toch zelf bouwen: de context is bepalend

low-code

Low-code en vibe coding maken softwareontwikkeling toegankelijker dan ooit. Maar niet elke toepassing is geschikt voor elke aanpak. Wanneer gebruik je best welke technologie? 

Low-code en vibe coding bieden steeds meer mogelijkheden voor ontwikkelaars en kunnen bedrijfsprocessen versnellen. Toch schuilen er ook valkuilen: van licentie-lock-in bij kritieke applicaties tot het verlies aan controle over wat AI precies bouwt. 

“De keuze voor low-code of vibe coding is sterk afhankelijk van de context en applicatie”, vertelt Dirk Deridder, CTO bij Smals tijdens een ronde tafel georganiseerd door ITdaily. Hoe benut je het potentieel van deze snel evoluerende technologieën, zonder jezelf vast te rijden?  

Rond de tafel zitten ook Bjorn Boisschot, Quality Engineering Manager bij Cegeka, Stijn Lambrechts, Global Delivery Lead Applications bij Cegeka, Pieter Vercammen, Solutions Architect bij Mendix en Ron Pooters, directeur van de Microsoft Innovation Hub in Brussel.  

Groene letters 

“Low-code bestaat al maar dan 20 jaar”, begint Vercammen. Toch botsen veel organisaties op een adoptieprobleem. Vercammen helpt hier graag een stereotype de wereld uit: “Veel bedrijven denken dat echte software enkel door doorwinterde ontwikkelaars gemaakt wordt, ofwel mensen die in een kamer zitten staren naar groene letters”, vertelt hij al lachend. 

Low-code blijft een kwestie van evangeliseren.

Pieter Vercammen, Solutions Architect bij Mendix

Hij merkt op dat de meeste klanten die de adoptiedrempel voor low-code over geraken, er succesvol uitkomen. “Maar het blijft een kwestie van evangeliseren.” 

Kritieke applicaties 

Niet iedereen kiest voor deze weg, en dat heeft redenen. “Wij gebruiken geen low-code en dat is een bewuste keuze”, vertelt Deridder. Hoewel ze ook met veel enthousiasme hebben gekeken naar de mogelijkheden van low-code, sloegen ze toch een andere weg in met Smals. Volgens Deridder heeft dit te maken met het type van toepassing. 

De context is bepalend voor welke technologie je kiest.

Dirk Deridder, CTO bij Smals

Smals bouwt voornamelijk grote backoffice-platformen met veel transacties, en die use cases lenen zich volgens hen niet goed voor low-code. “Daar komt nog bij dat de overheid op een heel andere tijdshorizon werkt dan een doorsnee bedrijf: toepassingen moeten 30 jaar of langer meegaan. Op commercieel vlak kan er veel veranderen in twee decennia, en dat weegt mee in elke technologiekeuze”, aldus Deridder.  

Vercammen daarentegen ziet wel potentieel in low-code voor grote applicaties. “We zien bedrijfskritische applicaties die gemaakt worden in low-code. Elk pakketje dat aan je deur geleverd wordt bij PostNL, wordt volledig in een low code-gebaseerde backend gebouwd. Dat is een mythe die doorbroken moet worden”, vindt hij.  

Licentie-lock-in 

Lambrechts sluit zich aan bij het verhaal van Deridder. Hij merkt op dat de lock-in bij low-code niet zit bij de implementatiepartner, maar puur op licentieniveau. Dat is exact waar klanten schrik voor hebben. “Als je een complexe en bedrijfskritieke applicatie hebt gebouwd die tot 20 jaar moet meegaan, kan je niet zonder zware investering vertrekken wanneer de licentieregels worden aangepast.”, aldus Lambrechts.

De lock-in bij low-code zit niet bij de implementatiepartner, maar op licentieniveau.

Stijn Lambrechts, Global Delivery Lead Applications bij Cegeka

Hij stelt dat specifiek ontwikkelen meer controle biedt: “de licentiekost is quasi onbestaand, en je kunt flexibeler omgaan met infrastructuur. De keerzijde was altijd dat je er meer werkuren voor nodig had, maar dat argument verliest terrein nu AI de ontwikkeling versnelt.” Lambrechts verwacht dan ook dat specifiek ontwikkelen opnieuw aantrekkelijker wordt.

AI als katalysator? 

AI biedt daar volgens Vercammen echter steeds meer soelaas. “Wat we nu met AI zien, is dat het replatformen van platform A naar platform B enorm versnelt.” De mogelijkheid om weg te migreren wordt daardoor minder een theoretische garantie en meer een praktische realiteit. 

Toch nuanceert hij meteen: de houdbaarheid op lange termijn van AI-leveranciers zelf is geen evidentie. “Er worden door heel veel softwarebedrijven miljarden verbrand. OpenAI verliest per maand meer dan het Belgisch begrotingstekort op jaarbasis. Op een gegeven moment stel je wel de vraag: is dat op lange termijn een houdbare oplossing?”  

De migratiefaciliteit van AI lost het lock-in-vraagstuk dus deels op, maar creëert tegelijk een nieuwe afhankelijkheid: die van leveranciers wiens businessmodel nog lang niet bewezen is. 

Runtime 

Onafhankelijkheid van de runtime-omgeving is voor Deridder een harde eis. “We willen applicaties kunnen draaien ook nadat er eventueel problemen zijn met de leverancier. Platformen die aansluiten bij een open ecosysteem, zoals Java, bieden daarin meer autonomie en flexibiliteit om later naar een andere runtime te porten”, stelt hij. 

Diezelfde logica geldt volgens hem voor AI. “Zolang AI enkel wordt ingezet om code of statische programma’s te genereren, speelt de tokenkosten op runtime geen rol. Zodra een applicatie op runtime een AI-systeem nodig heeft om beslissingen te nemen, wordt de context bepalend.”  

‘AI-ifyen’ 

Boisschot nuanceert verder. AI inzetten voor iets wat deterministisch is, is volgens hem zinloos. “Als één plus één twee is, waarom vraag je dat aan een LLM? Het gevaar is dat bedrijven alles willen ‘AI-ifyen’, terwijl de helft nutteloos is of simpelweg veel geld kost.” 

Daarnaast waarschuwt hij voor het verschil tussen human in the loop en human in control. Het ene betekent dat een mens ergens in het proces betrokken is, het andere dat de mens de finale beslissing behoudt en de kwaliteit bewaakt. Wie dat onderscheid negeert, loopt risico.” 

Ook Deridder erkent dat verschil. De menselijke kritische blik blijft onontbeerlijk. “Zeker bij kritieke systemen, zoals gezondheidszorg of sociale zekerheid, moet de mens uiteindelijk de finale beslissing nemen. Accuraatheid en uitlegbaarheid zijn daar te belangrijk.” 

Niet tegen de technologie vechten 

Low-code en vibe coding zijn dus niet overal in dezelfde mate interessant. Deridder hamert erop dat context belangrijk blijft. Dat wil echter niet zeggen dat je er niet mee aan de slag kan. Vercammen verwees al naar succesvolle applicaties met low-code, en ook vibe coding biedt een meerwaarde om processen te versnellen, “zolang het zich niet in de runtime bevindt”, aldus Deridder. 

“Het laatste wat je moet doen, is tegen de technologie vechten”, stelt Pooters. De tools evolueren sneller dan organisaties kunnen bijhouden, maar dat mag geen excuus zijn voor stilstand. 

Het laatste wat je moet doen, is tegen de technologie vechten.

Ron Pooters, directeur van de Microsoft Innovation Hub in Brussel

De uitdaging is niet kiezen tussen low-code, vibe coding of bespoke development, maar begrijpen wanneer welke aanpak past, en daar een doordachte strategie op bouwen. Want zoals Deridder het samenvat: “Wie gisteren is begonnen, heeft wel degelijk een voorsprong.”