FJAN Logo

Uw marketingteam vibe-codet al. Bereid u voor op de erfenis.

Publicatiedatum

Leestijd

3 minuten

Delen

Illustrating vibe coded apps on a desk
Profile photo of Funs Janssen

Geschreven door Funs Janssen

Software Consultant

I’m Funs Janssen. I build software and write about the decisions around it—architecture, development practices, AI tooling, and the business impact behind technical choices. This blog is a collection of practical notes from real projects: what scales, what breaks, and what’s usually glossed over in blog-friendly examples.

Vraag eens rond op kantoor wie er in de afgelopen maand iets gebouwd heeft met Lovable, Cursor of de app builder van ChatGPT. Het antwoord verbaast vrijwel iedere MKB-eigenaar die we deze vraag stellen. Uw marketingmanager bouwde een lead-scoring tool. Iemand bij operations maakte een dashboard dat al drie weken op de muur in de werkplaats hangt. De HR-stagiair zette een formulier op dat sollicitanten doorzet naar een Google Sheet. Niemand heeft IT gevraagd. Niemand vond dat hij dat moest doen.

Wat is "vibe-coden" eigenlijk

De term komt uit de ontwikkelaarswereld, maar het verschijnsel is breder. Vibe-coden is software bouwen door een AI-assistent in natuurlijke taal te beschrijven wat u wilt, en het resultaat te accepteren zonder dat u de code zelf doorgrondt. Tools als Lovable, v0 en de app builder van ChatGPT halen de drempel weg om met een werkend prototype boven water te komen. In een middag heeft uw operations-coördinator iets dat eruitziet als een echte applicatie — en in veel gevallen ook werkt.

Waarom dit u aangaat

Verbieden is zinloos en contraproductief. De productiviteitswinst is reëel: werk dat anders een aanvraag bij IT was geworden, of helemaal niet was gedaan, ligt nu binnen een week op tafel. Maar er is een keerzijde, en die heeft drie gezichten.

Datalek door onnadenkendheid. De marketingtool draait op een gratis tier, met klantdata in een database waarvan niemand precies weet wie meekijkt. Een API-key staat in de code. Niemand heeft dat met opzet gedaan; het was gewoon de snelste weg.

Sleutelpersoonafhankelijkheid. De tool werkt prima — totdat de bouwer het bedrijf verlaat. Niemand anders weet hoe hij draait, waar hij staat, of welke account hem in de lucht houdt. Wat begon als een handigheid wordt stilletjes een continuïteitsrisico.

Stille uitval. Het script draait elke nacht om drie uur. Maandenlang gaat het goed. Tot een externe API verandert, en niemand merkt dat de cijfers in het maandrapport niet meer kloppen.

De middenweg

Tussen "alles via IT" en "iedereen bouwt wat hij wil" zit een werkbare aanpak. Hij hoeft niet zwaar te zijn.

Een lichte intake — achteraf. Vraag mensen één keer per kwartaal welke tools ze gebouwd of in gebruik genomen hebben. Drie velden: wat doet hij, wie raakt hij aan, welke data zit erin. De meeste tools blijken iets onschuldigs te zijn. De paar uitzonderingen vindt u nu wél.

Graduatiecriteria. Sommige tools groeien door tot bedrijfskritisch. Spreek vooraf af wanneer dat moment is — bijvoorbeeld zodra meer dan vijf mensen ervan afhankelijk zijn, of zodra er klantdata in zit. Vanaf dat punt verhuist de tool naar een ondersteund spoor: een gedeelde account, een gedocumenteerde eigenaar, vervangbare hosting.

Sandboxdata en gedeelde accounts. Geef bouwers een veilige omgeving met testdata, een sjabloon voor een gedeelde projectaccount, en een korte lijst tools die niet aan productiedata mogen. Dat is geen restrictief beleid; dat is fundament dat snelheid mogelijk maakt.

Wat u deze week kunt doen

Houd een gesprek van twintig minuten met uw managementteam. Vraag wie er in de afgelopen drie maanden iets met een AI-tool heeft gebouwd dat collega's nu gebruiken. U krijgt een lijst die langer is dan u verwacht. Behandel hem niet als probleem, maar als inventaris. Daarna kunt u nadenken over de twee of drie tools die ondersteuning verdienen — en de rest met rust laten.

Loopt u tegen iets soortgelijks aan in uw bedrijf? Plan een vrijblijvend kennismakingsgesprek met FJAN.

Reacties

Nog geen reacties. Wees de eerste om te reageren.

Plaats een reactie

Profile photo of Funs Janssen

Geschreven door Funs Janssen

Software Consultant

I’m Funs Janssen. I build software and write about the decisions around it—architecture, development practices, AI tooling, and the business impact behind technical choices. This blog is a collection of practical notes from real projects: what scales, what breaks, and what’s usually glossed over in blog-friendly examples.

Inhoud