Vibekoding og sikkerhet: Dette må ledere vite om team som bygger med KI
Forskjeller i KI-kunnskap: Ledere møter utfordringer når teammedlemmer overgår dem når det gjelder KI-verktøy og -ferdigheter.
Vibekoding forklart: Ikke-tekniske medarbeidere lager funksjonelle verktøy ved hjelp av instruksjoner, noe som bygger bro over gapet mellom ideer og gjennomføring.
Sikkerhetsbekymringer: Uadministrerte vibekodingsverktøy medfører risiko for datahåndtering og dataeksponering, særlig sårbarheter knyttet til personopplysninger.
Kostnadskonsekvenser: Uoptimalisert bruk av KI-verktøy kan føre til uventede utgifter og økonomisk risiko.
Skaleringsutfordringer: Vellykkede vibekodede verktøy krever profesjonelt tilsyn for å sikre skalerbarhet og pålitelighet.
La oss være ærlige: Vi er alle på forskjellige steder når det gjelder KI. Og for ledere kan dette være urovekkende – mer enn noen gang overgår medarbeidere lederne sine når det gjelder KI-kunnskap og tilrettelegging, de beveger seg raskt og ødelegger ofte ting underveis.
Selv om mange organisasjoner oppmuntrer til åpen utforskning av KI-verktøy, er vibekoding – den neste fasen av KI-tilrettelegging for mange ikke-tekniske ansatte – et eventyr som innebærer varierende grad av risiko, avhengig av hva du bygger, hvem du bygger det for, og hvilke data som lagres og brukes.
Dette blir stadig mer utbredt i prosjektstyrings- og driftsteam, der det ofte er åpenbart å bygge egne verktøy for å løse prosessbehov – og med KI-kodeagenter har det aldri vært enklere å godkjenne slike initiativer.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
For å hjelpe oss med å forstå hva vi bør være oppmerksomme på når team begynner å bygge, tok jeg med Tim Fisher, DPMs KI-direktør, for å gi oss en gjennomgang. Denne artikkelen er for alle som har fått meldingen «Hei sjef, se på denne kule greia jeg bygde med Claude!» – vi håper den er til hjelp.
Først: Hva er vibekoding, og hvorfor er det egentlig verdifullt?
I denne artikkelen betyr vibekoding å kode gjennom instruksjoner – nærmere bestemt utført av noen som ikke er teknisk kyndig. Dette skiller seg fra en programvareutvikler som bruker et verktøy som GitHub Copilot, der mennesket fortsatt tilfører betydelig teknisk kunnskap til arbeidet. Vi snakker om økonomidirektøren, driftskoordinatoren eller prosjektlederen som aldri har skrevet en eneste kodelinje, og som nå leverer funksjonelle verktøy ved hjelp av bare instruksjoner i naturlig språk.
Og Fishers første vurdering vil kanskje overraske deg: Han er oppriktig begeistret for det. «Jeg elsker ideen om at mennesker som ikke kan kode, nå kan få en måte å få det de ønsker seg, ut av hodet og over i en form som alle kan se, leke med og bruke», sier han. «Det er en måte å kommunisere på som ikke fantes før.» Han fremstiller det mindre som en teknisk ferdighet og mer som et nytt kommunikasjonsmedium – et medium som bygger bro mellom visjon og gjennomføring for mennesker som alltid har hatt ideer, men manglet det tekniske vokabularet for å uttrykke dem.
Vibekoding er en måte å kommunisere på som ikke fantes før.
«Det minner litt om utfordringene folk opplever når de jobber med designteam», forklarer Fisher. «Jeg kan ikke tegne en strekmann engang. Og når jeg vil kommunisere noe visuelt til noen, er jeg så glad for at det nå finnes verktøy som lar meg forklare noe med mange gjennomtenkte ord, noe jeg er flink til, og få noe ut i den andre enden som en annen person, som faktisk kan designe, ser på og sier: «Å, nå forstår jeg hva du er ute etter.»»
For ledere er denne nye forståelsen viktig. Impulsen til å stanse det helt overser det som faktisk er nyttig her: Vibekoding kan fremskynde samkjøring, få ideer frem raskere og gi ikke-tekniske teammedlemmer en ny måte å bidra på. Spørsmålet er ikke om det skal tillates. Spørsmålet er om du forstår hva som skjer etter at verktøyet er bygget.
Der verdien stopper – og risikoen begynner
Fisher er nøye med å skille «kommunikasjonsfasen» i vibekoding fra det som vanligvis følger etter – og det er her tonen hans endrer seg. «Jeg tror verdien av det sannsynligvis stopper der, stort sett», sier han. «Det er en mye bedre måte å kommunisere ideer og retning på. Men det vi finner, er at enkelte ting kan skje etterpå som blir mer enn «Hei, se her, jeg har kommunisert en idé til deg, og nå deler vi et språk.» Og det er her det blir skremmende.»
Problemet er ikke instruksjonene. Det er utrullingen. Det er øyeblikket da en prototype blir til et verktøy som virkelige mennesker bruker, som lagrer virkelige data, som kjører i bakgrunnen på virkelig infrastruktur – mens personen som bygde det, fortsatt ikke vet hva som skjer under overflaten.
Sikkerhetssårbarhetene ledere bør kjenne til
PII og datahåndtering
Den mest intuitive risikoen for de fleste ledere vil være knyttet til personlig identifiserbar informasjon (PII). Fisher bruker et konkret eksempel for å illustrere hvor grensen går: «Jeg tror taket for kompleksitet ligger rett før innlemmingen av ansatt- eller kundedata i et system som gjengir disse dataene for andre mennesker. Det er da du støter på PII-problemer.»
Jeg tror taket for kompleksitet ville være rett før inntasting av ansatt- eller kundedata i et system som gjengir disse dataene til andre personer.
Risikoen øker i takt med hvor sensitive dataene er, og hvem som har tilgang til dem – og i drifts- og prosjektlederteam omfatter disse dataene ofte kundeinformasjon, ansattopplysninger, lønnsdata eller kontaktopplysninger som medfører reell juridisk risiko.
Ukontrollerte kostnader og tokenbruk
Én risiko som overrasker mange ledere, har ingenting med data å gjøre og alt med penger å gjøre. Fisher beskriver et scenario som er vanligere enn de fleste er klar over: "La oss si at noen ved et uhell leder en agentisk kodegenerator i feil retning, slik at den oppretter en løkke som kjører hele tiden og stadig påløper en høy kostnad. Og før du vet ordet av det, koster et prosjekt som skulle koste 5 000 dollar, 50 000 dollar fordi de ikke visste hva som foregikk under panseret og antok at den agentiske kodegeneratoren ville oppdage det."
Ikke-tekniske utviklere er også mindre tilbøyelige til å optimalisere for tokenbruk generelt, noe som betyr at kostnadene kan hope seg opp stille og raskt. Uten innsyn i infrastrukturen verktøyene deres kjører på, innser teammedlemmene kanskje ikke at det er et problem før regningen kommer.
API-nøkler og informasjonssikkerhet
Det er her Fisher beveger seg inn på området som holder sikkerhetsteam våkne om natten. Scenarioet han beskriver, er et skoleeksempel på hva som går galt når noen vet akkurat nok til å være farlige: "En vanlig feil er at noen vet akkurat nok til å vite og formulere at de trenger en API-nøkkel for å få noe til å skje. De oppgir nøkkelen i en instruksjon, og den lagres ikke på et hemmelig sted – den dumpes bare i en fil eller skrives direkte inn i skriptet. Så legger noen koden ut på GitHub, kanskje glemmer de å gjøre den privat, og nå kan API-nøkkelen misbrukes av hvem som helst som er villig til å gjøre noe ondsinnet, som å påføre en tokenregning på 100 000 dollar.”
Det er lett å lese dette scenarioet og tenke at det krever en lang rekke feil. Fisher avviser denne innskytelsen: "Det høres ut som om dette er en lang rekke usannsynlige ting som må skje, men det er slett ikke usannsynlig. Det er faktisk utrolig vanlig, særlig blant ikke-tekniske personer.”
Den kanskje mest alarmerende risikoen Fisher trekker frem, er en som selv erfarne utviklere har gått i. "Jeg har hørt skrekkhistorier om erfarne utviklere som legger hele kodebasen til en virksomhet inn i en agentisk kodegenerator og justerer noe, og deretter blir hele kodebasen eksponert for et annet selskap, helt innenfor lovens rammer." Hvis erfarne utviklere kan gjøre denne feilen, er risikobildet betydelig høyere for en ikke-teknisk ansatt som bygger raskt og uten tilsyn.
More Articles
- Fremveksten av vibekoding: Kan det være nyttig for prosjektledere?
- Ledende ingeniørleder sier at leveranseansvarlige må ta i bruk sanntidsbaserte, signalorienterte systemer
- Leveranseleder i Google deler hvordan agentbaserte arbeidsflyter endrer produktledermodeller
- Denne tidligere Google-produktsjefen endrer hvordan prosjektteam arbeider med et AI-verktøy for produktsjefer bygget på AI-agenter
- Slik bruker en erfaren prosjektleder KI til å effektivisere leveransen
Skaleringsproblemet – hva skjer når det faktisk fungerer?
En av de vanskeligere samtalene for ledere handler om hva de skal gjøre når et verktøy utviklet ved hjelp av KI uten tradisjonell koding faktisk løser et problem, og folk begynner å stole på det. Suksesshistorien kan i stillhet bli en belastning. Fisher er tydelig på det strukturelle problemet: "Generelt sett er alle prosjekter som er utviklet ved hjelp av KI uten tradisjonell koding, ikke skalerbare, hovedsakelig fordi du ikke ber agenten om å ta hensyn til skalering. Ikke-utviklere ber sannsynligvis ikke engang om ting som feilhåndtering. Hvis du ikke forstår hvor feil faktisk oppstår, vet du ikke nok til å sikre at agenten fanger opp disse feilene og håndterer dem på riktig måte."
Generelt sett er alle vibe-kodede prosjekter ikke skalerbare, hovedsakelig fordi du ikke ber agenten om å ta hensyn til skalering.
Ansvarlighetsgapet blir mest synlig under press. «Det som gjerne skjer, er at noen vibe-koder noe, og så fungerer det, men er denne personen teknisk support døgnet rundt for dette produktet?» For ledere innen leveranse og drift er dette øyeblikket da et velment internt verktøy blir en organisatorisk risiko – fordi jo flere team som er avhengige av det, desto større er sannsynligheten for at det slutter å fungere eller trenger kontinuerlig teknisk support.
Fishers anbefaling for verktøy som får fotfeste, er en ryddig overlevering: «Hvis du bygger noe folk er avhengige av, må det bli mer enn bare et vibekodet prosjekt; det må tas over av folk som jobber profesjonelt med dette, og som vet ting du ikke engang vet at du bør spørre om.»
Hva ledere kan gjøre – praktiske sikkerhetsnett
Dette betyr ikke at svaret er et generelt forbud. Fisher er konsekvent på dette punktet – verdien av vibekoding for ikke-tekniske personer er reell, men den hører hjemme i et bestemt område. «Verdien av disse verktøyene for ikke-kodere er at de kan hoppe over ting som samkjøring rundt en idé og komme forbi fasen med spørsmålet «kommer dette til å fungere?»», sier han. Prototypfasen, kommunikasjonsfasen, fasen med spørsmålet «er dette i det hele tatt verdt å bygge?» – det er her vibekoding virkelig kommer til sin rett, og der risikoen fortsatt er håndterbar.
For ledere ser den praktiske fremgangsmåten omtrent slik ut: Oppmuntre til vibekoding som et verktøy for prototyping og kommunikasjon, og etabler en tydelig terskel for når et verktøy skal vurderes av noen med teknisk ekspertise før det tas i bredere bruk. Det er disse samtalene med teamet – slik at de forstår risikoene og kjenner alternativene sine – som skiller en kultur for smart utforskning av kunstig intelligens fra en kultur som bare setter opp farten og håper på det beste.
Målet er ikke å være lederen som sier nei. Det er å være lederen som sørger for at teamet vet hva de begir seg ut på – slik at når noen faktisk bygger noe fantastisk, kan det virkelig utvikle seg videre.
Vil du ha flere innsikter som disse? Registrer deg for en gratis DPM-konto for å høre fra flere eksperter som disse.
