Zelf software bouwen met AI: hoe houd je controle als organisatie?

Deel 1 van 2. In dit deel: wat vibecoden is, wat er in de praktijk misgaat, en welke afspraken je als directie maakt. In deel 2 staat de praktische werkwijze voor de collega die zelf bouwt.

Ergens in je organisatie zit een collega die iets heeft gebouwd. Misschien een tooltje dat offertes automatisch nummert. Misschien een dashboard dat cijfers uit twee systemen naast elkaar zet. Hij of zij heeft geen regel code geschreven, maar heeft het in gewone taal aan een AI-assistent gevraagd, een middag lang bijgestuurd, en er stond iets dat werkt.

Dat heet vibecoden. En de kans is groot dat het bij jou al gebeurt, of je het nu weet of niet.

Wat is vibecoden?

Vibecoden is het bouwen van software met behulp van AI. In plaats van zelf code te schrijven, beschrijf je in gewone taal wat een applicatie moet doen en laat je een AI-assistent het technische werk uitvoeren.

Wil je meer weten over wat vibecoden precies is en hoe het werkt? Lees dan onze FAQ: Wat is vibecoden?.

Het verschil met no-code is belangrijk, want dat wordt vaak door elkaar gehaald. Bij no-code werk je binnen een afgesloten omgeving met vaste bouwblokken, waar inloggen, rechten en backups al zijn ingeregeld door de leverancier. Bij vibecoden ontstaat er echte, eigen software die ergens moet draaien, waar niemand die dingen voor je heeft geregeld. Dat is precies waarom vibecoden veel meer mogelijk maakt en tegelijk veel meer risico geeft.

En het is geen speelgoed. Wat er uitkomt is doorgaans functionerende software die er professioneel uitziet. Dat is een groot deel van het probleem, want aan de buitenkant kun je niet zien of het van binnen deugt.

Wat er echt is veranderd

Software ontwikkelen was jarenlang duur, tijdrovend en voorbehouden aan specialisten. Dat is fundamenteel veranderd. Met AI-tools en vibecoding kunnen medewerkers tegenwoordig zelf oplossingen bouwen voor problemen die zij dagelijks ervaren in hun werk.

Dat biedt organisaties grote kansen. Processen kunnen sneller worden geautomatiseerd, ideeën kunnen direct worden getest en afdelingen zijn minder afhankelijk van externe ontwikkelaars of wachtlijsten bij de IT-afdeling. Innovatie verschuift hierdoor van een centraal team naar de hele organisatie. Juist daar zit ook de kracht. De mensen die het werk uitvoeren weten vaak als geen ander waar processen vastlopen. Wanneer zij zelf oplossingen kunnen bouwen, ontstaat er ruimte voor sneller verbeteren, experimenteren en innoveren.

Wat niet is veranderd, is alles wat daarna komt. Een applicatie moet worden beheerd, beveiligd, bijgewerkt en gedocumenteerd. Ook moet duidelijk zijn wie verantwoordelijk is wanneer de maker uit dienst gaat of een andere functie krijgt. Die verantwoordelijkheden zijn niet verdwenen doordat software ontwikkelen eenvoudiger is geworden. In veel gevallen vormen de ontwikkelkosten zelfs maar een klein deel van de totale levensduurkosten van een applicatie. Het grootste deel zit in beheer, onderhoud, beveiliging en continuïteit.

Daar ontstaat een nieuw risico voor organisaties. Omdat de drempel om software te bouwen vrijwel is verdwenen, kunnen toepassingen ontstaan zonder dat daar ooit een formeel besluit over is genomen. Wat begint als een handige oplossing van één medewerker, kan binnen enkele maanden uitgroeien tot een bedrijfskritische applicatie waar meerdere collega’s dagelijks van afhankelijk zijn.

De uitdaging voor directies is daarom niet om vibecoding tegen te houden, maar om de voordelen ervan te benutten binnen duidelijke kaders voor beheer, beveiliging en continuïteit.

Verbieden remt innovatie

De reflex om vibecoden dan maar te verbieden is begrijpelijk en tegelijk de slechtste van de beschikbare opties. Het eerste probleem is dat het niet lukt. De tools zijn gratis of kosten twintig euro per maand, ze draaien in een browser, en er is geen installatie voor nodig waar IT iets van merkt. Een verbod verplaatst het naar de privélaptop en de privé-account. Dan gebeurt het nog steeds, maar je ziet het niet meer.

Het tweede probleem is dat je iets waardevols weggooit. De collega’s die dit doen zijn vaak precies de mensen die het werk het beste kennen. Zij zien welke handeling elke week een uur kost. Die kennis zit niet bij je IT-leverancier en niet bij een softwareleverancier. Het alternatief is niet verbieden en ook niet vrijlaten. Het is kaders geven.

Juist daar komt een AI-beleid om de hoek kijken. Daarmee leg je vast welke AI-tools gebruikt mogen worden, welke gegevens verwerkt mogen worden en wanneer extra controle nodig is. Zo geef je medewerkers de ruimte om te innoveren, zonder de grip op beveiliging, compliance en bedrijfsinformatie te verliezen.

In ons artikel over AI-beleid opstellen leggen we uit wat een AI-beleid is en hoe je er zelf mee aan de slag kunt.

Wat er in de praktijk misgaat

Om die kaders te kunnen bepalen, helpt het om te weten wat er daadwerkelijk fout gaat. Niet in theorie, maar in de gevallen die wij tegenkomen.

De app werkt, maar iedereen kan bij alles

Dit is veruit de meest voorkomende fout, en de meest onzichtbare. Functioneel doet de applicatie precies wat hij moet doen. Maar de controle die bepaalt of jij de gegevens van een ander mag zien, ontbreekt. In de praktijk betekent dat: een medewerker past één getal in de webadresbalk aan en kijkt mee in het dossier van een collega. Je merkt dit nooit tijdens het testen, want tijdens het testen kijkt iedereen naar zijn eigen scherm.

De data staat op een plek waar je geen afspraken mee hebt

Vraag je een AI-assistent waar hij de applicatie zal plaatsen, dan komt er standaard een gratis hostingpartij uit. Die partijen zijn niet per definitie onbetrouwbaar, maar je hebt er geen verwerkersovereenkomst mee, je weet niet in welk land de gegevens staan, en je kunt bij een datalek niet uitleggen hoe het zit. Zodra er persoonsgegevens in die applicatie staan, is dat een AVG-probleem dat als directie op jouw bord ligt en niet op dat van de bouwer.

Niemand snapt het behalve de maker

Bij traditioneel maatwerk is er meestal nog documentatie, een leverancier en een contract. Bij een vibecoded applicatie is er een collega die het weet. Zolang die er is, gaat het goed.

Het is bedrijfskritisch geworden zonder dat iemand daartoe heeft besloten

Dit is het patroon dat ons het meeste zorgen baart. Een tooltje voor één afdeling wordt gedeeld met een tweede afdeling. Na een jaar loopt de facturatie erlangs. Er is nooit een moment geweest waarop iemand heeft gezegd: dit is nu een kernsysteem en moet dus aan andere eisen voldoen. Het is er gewoon ingegroeid.

De kosten lopen door

Cloudresources en AI-verbruik worden per gebruik afgerekend. Een applicatie die verkeerd is ingericht kan maandenlang een paar tientjes per dag kosten zonder dat iemand kijkt.

De afspraken die je als directie maakt

Je hoeft dit niet technisch te begrijpen om het te sturen. Zes afspraken zijn voldoende, en ze zijn allemaal in gewone taal te maken.

Veel organisaties leggen dit soort afspraken vast in een AI-beleid. Daarmee is voor medewerkers duidelijk welke AI-tools gebruikt mogen worden, welke gegevens verwerkt mogen worden en wanneer extra controle nodig is. Lees ook ons artikel over AI-beleid opstellen.

1. Meld wat je bouwt

Eén simpele lijst waarop staat wie wat heeft gebouwd, waarvoor het dient en wie het gebruikt. Geen goedkeuringsprocedure, alleen zichtbaarheid. Je kunt niet sturen op wat je niet weet.

2. Spreek vooraf af welke gegevens erin mogen

Dit is de belangrijkste knop die je hebt. Een applicatie zonder persoonsgegevens is een experiment en mag licht behandeld worden. Zodra er klantgegevens, personeelsgegevens of financiële gegevens in komen, gelden andere regels en moet er iemand met verstand van zaken naar kijken. Maak dat onderscheid expliciet, dan hoeft niet alles door dezelfde molen.

3. Bepaal één plek waar het draait

Niet de bouwer kiest het platform, de organisatie kiest het. Eén omgeving, met afspraken over waar data staat, één centrale voordeur en één manier van inloggen. Dat is ook meteen het verschil tussen tien applicaties die je kunt beheren en tien applicaties die je alleen kunt hopen.

4. Vier ogen voordat het live gaat

Iemand anders dan de bouwer kijkt ernaar. Bij een intern hulpmiddel is dat een collega. Zodra er gevoelige gegevens in zitten, is dat iemand met securitykennis. Dit is het moment waarop de fout uit de eerste categorie hierboven wordt gevonden.

5. Elke applicatie heeft een eigenaar en een einddatum

Een naam van iemand die verantwoordelijk is, en een datum waarop je opnieuw kijkt of het nog gebruikt wordt. Zonder einddatum bouwt zich in twee jaar een verzameling op waarvan niemand meer weet of hij uit mag.

6. Kritisch betekent opnieuw beoordelen

Spreek af wanneer iets over de streep gaat. Meer dan een handvol gebruikers, of een proces dat stilvalt als de applicatie eruit ligt. Op dat moment gaat het opnieuw langs de meetlat, en soms is de uitkomst dat het professioneel herbouwd of vervangen moet worden. Dat is geen straf en geen verspilling. Het prototype heeft dan al bewezen dat het probleem echt bestaat, en dat is precies waar het voor bedoeld was.

De vraag die je stelt voordat er gebouwd wordt

Tot slot een afweging die veel geld scheelt en die door het gemak van vibecoden vaak wordt overgeslagen: moet dit eigenlijk wel gebouwd worden?

AI maakt bouwen makkelijker dan ooit. Juist daardoor wordt deze vraag belangrijker. Dat iets gebouwd kan worden, betekent niet automatisch dat het gebouwd moet worden.

Drie vragen zijn meestal genoeg. Zit het al in software die je hebt? Veel organisaties met Microsoft 365 en een ERP pakket hebben mogelijkheden in licentie die precies dit soort vraagstukken oplossen, mét beheer en beveiliging al ingeregeld. Is het probleem generiek of specifiek voor jou? Voor urenregistratie, CRM en ticketing bestaan uitstekende producten en is zelfbouw zelden verstandig. En: wie beheert dit over twee jaar? Als daar geen naam op past, is de uitkomst kopen.

De vuistregel die overblijft:

Bouw wat je onderscheidt, koop wat je alleen ondersteunt.

Tot slot

Vibecoden is geen bedreiging en ook geen wondermiddel. Het is een verschuiving in wie er software kan maken, en die verschuiving is niet meer terug te draaien. De organisaties die er het meeste uithalen zijn niet de organisaties die het hardst remmen of het hardst gas geven, maar de organisaties die vooraf een paar duidelijke afspraken hebben gemaakt. Wil je collega weten hoe dat er in de praktijk uitziet? In deel 2 staat de werkwijze voor wie zelf bouwt: van plan van aanpak tot de controle vlak voordat het live gaat.

Denk je na over hoe je dit binnen jouw organisatie inricht? Neem gerust contact op met BK IT Solutions.