Vibe coding risico's voor bedrijven: leuk bouwen, riskant koppelen

Stel dat iemand op de administratie in een weekend een tool bouwt met AI. De tool pakt orders uit de webshop en zet ze in het boekhoudpakket. Die persoon heeft nog nooit een regel code geschreven en toch werkt het vanaf dag één. Bij Websignaal vinden we zulke projecten leuk. Maar de vibe coding risico's zitten niet in het bouwen. Ze zitten in alles wat die tool doet zonder dat iemand het ziet, zodra er echte klantgegevens doorheen lopen.

Weet je wat je AI precies heeft gebouwd?

Het scherm ziet er goed uit en de orders komen aan. Maar kan de bouwer uitleggen hoe de tool inlogt op het boekhoudpakket? Waar het wachtwoord staat? Wat er gebeurt als het boekhoudpakket een update krijgt, of als twee orders tegelijk binnenkomen? Dat zijn geen exotische vragen. Een koppeling bestaat uit niets anders dan dit soort details.

Een koppeling draait ook nog eens op de achtergrond en vraagt niet om aandacht. Een fout merk je daardoor vaak pas weken later, als de cijfers in de boekhouding niet kloppen.

Een ontwikkelaar stelt bij werkende code nog vijf vragen:

• Beveiliging: wie komt erbij, waar liggen wachtwoorden en sleutels en wat doet de tool met onverwachte invoer?
• Opbouw: zijn de juiste ontwerppatronen gebruikt, of staat alles in één bestand dat niemand meer durft aan te raken?
• Uitbreidbaarheid: past er straks een tweede webshop of een ander boekhoudpakket in zonder alles te herschrijven? Dat leg je vooraf vast in een functioneel ontwerp.
• Onderhoud: is dit over drie jaar nog aan te passen, als de pakketten eronder een nieuwe versie hebben?
• Klantgegevens: welke gegevens gaan waarheen en wat gebeurt er als dat een keer misgaat?

Wie nooit code las, kan deze vragen niet beantwoorden. Dat zegt niets over slimheid. Je leert ze pas stellen als je er zelf tegenaan bent gelopen.

Een kozijn maken zonder ooit timmerman te zijn geweest

Wij kunnen proberen een kozijn te maken. Met een goede handleiding en het juiste gereedschap komt er vast iets uit dat erop lijkt. Of het waterdicht is, of het over tien jaar nog sluit en of het de keuring haalt, kunnen we niet beoordelen. Een timmerman wel. Ieder zijn vak.

Een vogelhuisje timmeren? Doen, dat is gewoon leuk. Een kozijn in het huis van een klant zetten zonder dat de timmerman ernaar heeft gekeken, doe je niet. Met software is het precies zo. We moedigen iedereen aan om met AI te bouwen, het is de beste manier om te ontdekken wat er kan. Maar kijk goed waar je het voor gaat inzetten.

Welke vibe coding risico's loop je zodra klantgegevens meedoen?

Een prototype voor jezelf, met verzonnen gegevens, mag stuk. Dat risico is klein en je leert er veel van. Het ligt anders zodra de tool klanten, orders, facturen of betalingen aanraakt. Dan is een fout geen bug meer, maar een datalek, een verkeerde factuur of een boekhouding die niet meer klopt. Lekt er klantdata via zelfgebouwde software, dan kan jouw bedrijf een datalek moeten melden bij de Autoriteit Persoonsgegevens en dat aan klanten moeten uitleggen. Die verantwoordelijkheid verdwijnt niet omdat een AI de code schreef.

AI-code die werkt is niet hetzelfde als AI-code die veilig is en over drie jaar nog te onderhouden. Een Shopware-plugin die orders aan een boekhoudpakket koppelt, raakt klantgegevens en financiële administratie en hoort daarom altijd door een ontwikkelaar te worden beoordeeld.

Wat doet Websignaal anders met AI?

Wij gebruiken AI elke dag, onder meer met Claude Code in Shopware- en Symfony-projecten. Lees ook hoe AI het bouwproces van een webshop verandert. Het gereedschap is niet het verschil. Het verschil is wie het resultaat leest. Onze ontwikkelaars kunnen de code lezen en beoordelen. Ze zien waarom een oplossing zo is opgebouwd en waar hij kan breken. Bij Websignaal gaat geen enkele regel code naar een staging- of productieserver zonder dat een ontwikkelaar die heeft gelezen en beoordeeld.

Dat geldt voor een Shopware-plugin met een koppeling naar ERP, PIM of boekhouding. Het geldt ook voor maatwerk in Symfony en voor aanpassingen in Concrete CMS of Craft CMS. Op een testomgeving mag de assistent veel zelf doen. Of iets live gaat, beslist een mens.

Waar de grens ligt tussen zelf bouwen en laten beoordelen

Onze vuistregel: hoe dichter een tool bij klantgegevens en geld komt, hoe eerder een ontwikkelaar mee moet kijken. Bouwen voor jezelf met nepgegevens kan zonder toezicht. Een interne tool met testgegevens laat je één keer bekijken voordat er echte gegevens in gaan. Zit er klantdata in, dan beoordeelt een ontwikkelaar de code, de opbouw en de beveiliging. Een koppeling met je administratie, ERP of betalingen heeft ook tests en een akkoord nodig voordat hij naar staging en productie gaat.

Een eenvoudige WooCommerce-webshop of een WordPress-site op een bestaand template bevat weinig eigen code, dus daar valt minder te beoordelen. Zodra er maatwerk in Shopware, Concrete CMS, Craft CMS of Symfony in zit, wel.

Bouw gerust door. Wil je weten of wat je hebt gemaakt klaar is voor echte klantgegevens, laat het ons dan bekijken voordat het live gaat. Je kunt een gesprek met ons inplannen.