Vibe coding: waarom snel gebouwde software vaak niet standhoudt

Het nieuws dat Hyves terugkeert, riep meteen twee reacties op. De ene groep werd nostalgisch. De andere groep, waaronder Tweakers, stelde een scherpere vraag: is dit een doordacht product of vooral een gevoel dat wordt terugverkocht? En op X gingen mensen nog een stap verder, met het vermoeden dat de comeback zelf snel met AI-tools in elkaar is “gevibet”. Die combinatie, nostalgie zonder productstrategie plus een vermoedelijk haastige technische bouw, is precies het patroon dat we bij maatwerksoftware voor bedrijven ook zien misgaan.

Wat heeft de Hyves-comeback te maken met vibe coding?

Tweakers trok de conclusie dat nostalgie alleen geen productstrategie is. Een merk terugbrengen omdat mensen er warme herinneringen aan hebben, is geen vervanging voor een antwoord op de vraag welk probleem je nu oplost voor wie. Op X voegden gebruikers daar een technische twijfel aan toe: het geheel oogt alsof het snel met AI-codeerhulp in elkaar is gezet, zonder dat er lang is nagedacht over wat er onder de motorkap gebeurt.

Die twee kritieken raken elkaar. Een product zonder duidelijk probleem dat het oplost, gebouwd op een fundament dat niemand grondig heeft doorgedacht, is dubbel kwetsbaar. Het mist zowel een reden om te blijven bestaan als de stevigheid om dat te kunnen.

Wat is vibe coding precies?

Vibe coding is een term voor het bouwen van software door voornamelijk op gevoel en met AI-assistentie snel te itereren, zonder vooraf een doordacht technisch ontwerp, architectuurkeuzes of een security-review. Je beschrijft in gewone taal wat je wilt, de AI genereert code, en je test of het werkt. Dat kan verbazingwekkend snel een demo opleveren.

Het probleem zit niet in de snelheid an sich, maar in wat er wordt overgeslagen: wie onderhoudt dit over twee jaar, hoe schaalt het bij honderd gebruikers in plaats van tien, en wat gebeurt er als iemand een kwetsbaarheid vindt. Voor een weekendproject is dat prima. Voor een systeem waar een bedrijf van 10 tot 150 medewerkers dagelijks op draait, is dat een risico dat zich vroeg of laat aandient.

Concreet zien we drie terugkerende problemen bij software die vooral op snelheid en hype is gebouwd:

• Kwetsbaarheid. Security is geen laag die je er later overheen legt, het moet vanaf de eerste regel code onderdeel zijn van het ontwerp. Wie dat overslaat, bouwt een systeem met gaten die pas zichtbaar worden als het te laat is. We schreven eerder al over security design als uitgangspunt, precies omdat dit achteraf repareren zoveel duurder en riskanter is dan vooraf inbouwen.
• Geen onderhoud. Snel gebouwde code zonder documentatie of structuur is voor niemand anders te begrijpen, ook niet voor de bouwer zelf een jaar later. Software die niet wordt bijgehouden, verouderd stilletjes en breekt op het slechtst denkbare moment. Daar gaat het artikel over software updaten belang onderhoud dieper op in.
• Geen echt probleem opgelost. Net als bij Hyves geldt: een tool die bestaat omdat het kón, in plaats van omdat iemand er een concreet probleem mee oplost, verliest op termijn zijn bestaansrecht. Gebruikers wennen aan de nieuwigheid en haken daarna af als er geen echte waarde onder zit.

Hoe bouwt Divtag dan wel snel, zonder de risico’s?

Snelheid en een doordacht fundament sluiten elkaar niet uit. Bij Divtag beginnen we bij het bedrijfsproces en het echte probleem, niet bij de techniek. Dat betekent niet dat het langzaam gaat: we leveren doorgaans snel een werkend prototype op, zodat een klant vroeg kan zien en voelen wat de software oplevert. Het verschil zit in wat er onder dat prototype ligt.

Architectuurkeuzes maken we bewust, met het oog op wat een systeem over twee of vijf jaar moet kunnen dragen. Zo kiezen we soms voor een modulaire opzet volgens mach architectuur flexibiliteit schaalbaarheid, juist omdat dat een systeem makkelijker laat meegroeien zonder alles opnieuw te hoeven bouwen. Security nemen we mee vanaf het ontwerp, niet als checklist achteraf. En na livegang blijven we monitoren en doorontwikkelen, want software die blijft werken, is nooit “af”.

Die aanpak komt niet uit een boekje. We bespreken dit soort keuzes intern voortdurend, bijvoorbeeld tijdens onze eigen R&D-dagen, waar we tijd vrijmaken om juist buiten de waan van projecten na te denken over hoe we bouwen. De waarde daarvan zit precies in dat soort reflectie op fundament in plaats van alleen op snelheid.

Herken je je eigen Excel-lapmiddel?

De kans is groot dat er ergens in je bedrijf een tool ronddwaalt die precies zo is ontstaan: snel in elkaar gezet om een acute pijn weg te nemen, zonder dat iemand er ooit een tweede blik op heeft geworpen. Een Excel-sheet die inmiddels driehonderd regels macro’s bevat en waar niemand meer vanaf durft te blijven. Een intern portaaltje dat draait op een laptop van een oud-medewerker. Dat soort constructies werkt, tot het niet meer werkt.