Vibecoderen en beveiliging: wat leiders moeten weten over teams die met AI bouwen
Verschil in AI-kennis: Leiders staan voor uitdagingen wanneer teamleden hen voorbijstreven in AI-tools en -mogelijkheden.
Vibecoderen uitgelegd: Niet-technische medewerkers maken functionele hulpmiddelen door middel van prompts, waardoor de kloof tussen ideeën en uitvoering kleiner wordt.
Beveiligingszorgen: Onbeheerde hulpmiddelen die met vibecoderen zijn gemaakt brengen risico's met zich mee op het gebied van gegevensverwerking en blootstelling, vooral kwetsbaarheden rond persoonlijk identificeerbare informatie.
Kostenimplicaties: Niet-geoptimaliseerd gebruik van AI-tools kan leiden tot onverwachte uitgaven en financiële risico's.
Schaalbaarheidsproblemen: Succesvolle hulpmiddelen die met vibecoderen zijn gemaakt hebben professioneel toezicht nodig om schaalbaarheid en betrouwbaarheid te waarborgen.
Laten we eerlijk zijn: we bevinden ons allemaal op verschillende punten als het om AI gaat. En voor leiders kan dat verontrustend zijn — vaker dan ooit overtreffen directe medewerkers hun managers in kennis van en mogelijkheden met AI, bewegen ze snel en maken ze daarbij vaak dingen stuk.
Hoewel veel organisaties open verkenning van AI-tools aanmoedigen, is vibe-coderen — voor veel niet-technische medewerkers de volgende fase van AI-mogelijkheden — een avontuur dat verschillende risico's met zich meebrengt, afhankelijk van wat je bouwt, voor wie je het bouwt en welke gegevens worden opgeslagen en gebruikt.
Dit wordt vooral zichtbaar binnen projectmanagement- en operationele teams, waar het bouwen van bedrijfseigen tools vaak het voor de hand liggende antwoord is op procesbehoeften — en met AI-codeeragenten is het nog nooit zo eenvoudig geweest om hiervoor groen licht te geven.
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Om ons te helpen begrijpen waar we op moeten letten wanneer teams beginnen te bouwen, heb ik Tim Fisher, DPM's VP van AI, erbij gehaald om ons bij te praten. Dit artikel is bedoeld voor iedereen die ooit het bericht heeft gekregen: "Hé baas, kijk eens naar dit geweldige ding dat ik met Claude heb gebouwd!" — we hopen dat het helpt.
Om te beginnen: wat is vibe-coderen? En waarom is het eigenlijk waardevol?
Voor dit artikel betekent vibe-coderen programmeren door middel van prompts — specifiek door iemand die niet-technisch is. Dit verschilt van een softwareontwikkelaar die een tool als GitHub Copilot gebruikt, waarbij de mens nog steeds betekenisvolle technische kennis inbrengt. We hebben het over de financieel directeur, de operationeel coördinator of de projectmanager die nog nooit een regel code heeft geschreven en nu functionele tools oplevert met niets meer dan prompts in natuurlijke taal.
En Fishers eerste indruk zal je misschien verrassen: hij is er oprecht enthousiast over. "Ik vind het geweldig dat mensen die niet kunnen programmeren nu een manier hebben om datgene wat ze in hun hoofd hebben, in een vorm te krijgen die iedereen kan zien, ermee kan spelen en die iedereen kan gebruiken," zegt hij. "Het is een manier van communiceren die er eerder niet was." Hij beschouwt het minder als een technische mogelijkheid en meer als een nieuw communicatiemedium — een medium dat de kloof tussen visie en uitvoering verkleint voor mensen die altijd ideeën hebben gehad, maar niet over de technische woordenschat beschikten om die uit te drukken.
Vibe-coderen is een manier van communiceren die er eerder niet was.
"Het lijkt een beetje op de uitdagingen die mensen ervaren wanneer ze met ontwerpteams werken," legt Fisher uit. "Ik kan geen stokfiguurtje tekenen. Dus wanneer ik aan iemand iets visueels wil overbrengen, ben ik zo blij dat er nu tools zijn waarmee ik iets kan uitleggen in allerlei goed doordachte woorden, waar ik goed in ben, en aan de andere kant iets krijg waarvan iemand die wel weet hoe je moet ontwerpen zegt: 'O, nu begrijp ik wat je bedoelt.'"
Voor leiders is deze andere kijk belangrijk. De neiging om het volledig stop te zetten gaat voorbij aan wat hier daadwerkelijk nuttig aan is: vibe-coderen kan afstemming versnellen, ideeën sneller zichtbaar maken en niet-technische teamleden een nieuwe manier bieden om bij te dragen. De vraag is niet of je het moet toestaan. De vraag is of je begrijpt wat er gebeurt nadat de tool is gebouwd.
Waar de waarde ophoudt — en het risico begint
Fisher maakt zorgvuldig onderscheid tussen de fase van "communicatie" bij vibe-coderen en wat er doorgaans op volgt — en daar verandert zijn toon. "Ik denk dat de waarde ervan meestal daar ophoudt," zegt hij. "Het is een veel betere manier om ideeën en richting te communiceren. Maar we zien dat er daarna dingen kunnen gebeuren die verder gaan dan: 'Hé, kijk, ik heb een idee aan je overgebracht en we spreken nu dezelfde taal.' En daar wordt het beangstigend."
Het probleem zit niet in de prompts. Het zit in de implementatie. Het gaat om het moment waarop een prototype een tool wordt die door echte mensen wordt gebruikt, echte gegevens opslaat en op de achtergrond op echte infrastructuur draait — terwijl de persoon die de tool heeft gebouwd nog steeds niet weet wat er onder de motorkap gebeurt.
De beveiligingskwetsbaarheden waar leiders van op de hoogte moeten zijn
PII en gegevensverwerking
Voor de meeste leiders ligt het meest intuïtieve risico bij persoonlijk identificeerbare informatie (PII). Fisher gebruikt een concreet voorbeeld om aan te geven waar de grens ligt: "Ik denk dat de grens qua complexiteit net ligt vóór het invoeren van gegevens van medewerkers of klanten in een systeem dat die gegevens aan andere mensen teruggeeft. Dan krijg je te maken met PII-problemen."
Ik denk dat de bovengrens qua complexiteit ligt vlak vóór het invoeren van werknemers- of klantgegevens in een systeem dat die gegevens opnieuw aan andere mensen verstrekt.
Het risico neemt toe naarmate de gegevens gevoeliger zijn en het publiek dat er toegang toe heeft groter is — en binnen operationele en projectmanagementteams omvatten die gegevens vaak klantinformatie, personeelsgegevens, beloningsgegevens of contactgegevens die aanzienlijke juridische risico's met zich meebrengen.
Onbeheersbare kosten en tokengebruik
Een risico dat veel leidinggevenden overvalt, heeft niets met gegevens te maken en alles met geld. Fisher beschrijft een scenario dat vaker voorkomt dan de meeste mensen beseffen: "Stel dat iemand een agentprogrammeur per ongeluk in de verkeerde richting stuurt, waardoor die een lus creëert die voortdurend blijft draaien en steeds hogere kosten veroorzaakt. En voordat je het weet, kost een project dat $5,000 zou moeten kosten $50,000, omdat ze niet wisten wat er onder de motorkap gebeurde en ervan uitgingen dat de agentprogrammeur dat zou opmerken."
Niet-technische makers optimaliseren over het algemeen ook minder vaak voor tokengebruik, waardoor kosten zich stilletjes en snel kunnen opstapelen. Zonder inzicht in de infrastructuur waarop hun tools draaien, realiseren je teamleden zich mogelijk pas dat er een probleem is wanneer de rekening binnenkomt.
API-sleutels en informatiebeveiliging
Hier komt Fisher op het terrein terecht dat beveiligingsteams 's nachts wakker houdt. Het scenario dat hij beschrijft, is een schoolvoorbeeld van wat er misgaat wanneer iemand net genoeg weet om gevaarlijk te zijn: "Een veelgemaakte fout ontstaat wanneer iemand net genoeg weet om te begrijpen en uit te leggen dat er een API-sleutel nodig is om iets te laten gebeuren. Ze geven de sleutel op in een prompt en die wordt niet op een geheime locatie opgeslagen – hij wordt gewoon in een bestand geplaatst of rechtstreeks in het script geschreven. Vervolgens plaatst iemand de code op GitHub, misschien vergeten ze de code privé te maken, en nu kan die API-sleutel worden misbruikt door iedereen die iets kwaadwilligs wil doen, zoals een tokenrekening van $100K opbouwen.”
Het is gemakkelijk om dat scenario te lezen en te denken dat er een lange keten van fouten voor nodig is. Fisher spreekt die reflex tegen: "Het klinkt alsof er een lange reeks onwaarschijnlijke gebeurtenissen moet plaatsvinden, maar dat is helemaal niet onwaarschijnlijk. Het komt juist buitengewoon vaak voor, vooral bij niet-technische mensen.”
Misschien wel het meest alarmerende risico dat Fisher noemt, is een risico waar zelfs ervaren ontwikkelaars in zijn getrapt. "Ik heb horrorverhalen gehoord over ervaren ontwikkelaars die de volledige codebase van een bedrijf in een agentprogrammeur stopten en iets aanpasten, waarna de volledige codebase van een ander bedrijf terechtkwam, volledig binnen de grenzen van de wet." Als ervaren ontwikkelaars deze fout kunnen maken, is het risicoprofiel voor een niet-technische medewerker die snel en zonder toezicht iets bouwt aanzienlijk hoger.
Het schaalbaarheidsprobleem — wat gebeurt er wanneer het echt werkt
Een van de lastigere gesprekken voor leidinggevenden gaat over wat ze moeten doen wanneer een met behulp van vibes gecodeerde tool daadwerkelijk een probleem oplost en mensen erop beginnen te vertrouwen. Het succes kan ongemerkt een risico worden. Fisher is duidelijk over het structurele probleem: "Over het algemeen zijn alle met behulp van vibes gecodeerde projecten niet schaalbaar, voornamelijk omdat je de agent niet vraagt om rekening te houden met schaling. Niet-ontwikkelaars vragen waarschijnlijk niet eens om zaken als foutafhandeling. Als je niet begrijpt op welke plekken fouten daadwerkelijk optreden, weet je niet genoeg om ervoor te zorgen dat de agent die fouten opvangt en er op de juiste manier mee omgaat."
Over het algemeen zijn alle projecten die via AI-gestuurd coderen zijn ontwikkeld niet schaalbaar, vooral omdat je de agent niet vraagt om rekening te houden met schaalbaarheid.
De verantwoordingskloof wordt het duidelijkst zichtbaar onder druk. "Wat er meestal gebeurt, is dat iemand iets met AI codeert en dat het vervolgens werkt, maar is die persoon dan 24/7 de technische ondersteuning voor dit product?" Voor leiders op het gebied van oplevering en bedrijfsvoering is dit het moment waarop een goedbedoelde interne tool een organisatorisch risico wordt — want hoe meer teams ervan afhankelijk zijn, hoe groter de kans dat de tool uitvalt of voortdurend technische ondersteuning nodig heeft.
Fishers aanbeveling voor hulpmiddelen die aan populariteit winnen, is een goede overdracht: "Als je iets bouwt waar mensen op vertrouwen, moet het meer worden dan alleen een project dat met AI is gecodeerd; het moet worden overgenomen door de mensen die dit professioneel doen en dingen weten waarvan jij niet eens weet dat je ernaar moet vragen."
Wat leiders kunnen doen — praktische richtlijnen
Dit betekent niet dat het antwoord een algeheel verbod is. Fisher is op dit punt consequent — de waarde van AI-gestuurd coderen voor niet-technische mensen is reëel, maar het heeft een specifieke toepassing. "De waarde van deze hulpmiddelen voor mensen die niet kunnen coderen, is dat ze zaken zoals overeenstemming over een idee kunnen versnellen en voorbij de fase van 'gaat dit werken?' kunnen komen," zegt hij. De prototypefase, de communicatiefase, de fase van "is dit überhaupt de moeite waard om te bouwen?" — daar komt AI-gestuurd coderen het best tot zijn recht en blijft het risico beheersbaar.
Voor leiders ziet het praktische stappenplan er ongeveer zo uit: moedig AI-gestuurd coderen aan als hulpmiddel voor het maken van prototypes en communicatie, en stel een duidelijke drempel in waarop een hulpmiddel wordt beoordeeld door iemand met technische expertise voordat deze breder wordt ingezet. Deze gesprekken voeren met je team — zodat ze de risico's begrijpen en hun opties kennen — is wat een cultuur van slimme AI-verkenning onderscheidt van een cultuur die gewoon snel beweegt en op het beste hoopt.
Het doel is niet om de leider te zijn die nee zegt. Het doel is de leider te zijn die ervoor zorgt dat het team weet waar het aan begint — zodat iets geweldigs dat iemand bouwt daadwerkelijk verder kan komen.
Wil je meer van dit soort inzichten? Meld je aan voor een gratis DPM-account om meer experts zoals deze te horen.
