Vibekodning och säkerhet: Vad ledare behöver veta om team som bygger med AI
Skillnader i AI-kunskap: Ledare ställs inför utmaningar när teammedlemmar överträffar dem i användningen av AI-verktyg och AI-kompetens.
Vibekodning förklarad: Icke-tekniska medarbetare skapar fungerande verktyg genom att formulera instruktioner, vilket överbryggar gapet mellan idé och genomförande.
Säkerhetsproblem: Ohanterade vibekodningsverktyg medför risker för datahantering och dataexponering, särskilt sårbarheter kopplade till personuppgifter.
Kostnadskonsekvenser: Ooptimerad användning av AI-verktyg kan leda till oväntade utgifter och ekonomiska risker.
Skalbarhetsproblem: Framgångsrika vibekodade verktyg kräver professionell tillsyn för att säkerställa skalbarhet och tillförlitlighet.
Låt oss vara ärliga: vi befinner oss alla på olika platser när det gäller AI. Och för ledare kan detta kännas oroande — oftare än någonsin överträffar direktrapporterande medarbetare sina chefer när det gäller AI-kunskap och användning, de rör sig snabbt och orsakar ofta problem.
Medan många organisationer uppmuntrar till öppet utforskande av AI-verktyg är vibekodning — nästa fas av AI-användning för många icke-tekniska medarbetare — ett äventyr som medför varierande grad av risk, beroende på vad du bygger, vem du bygger det för och vilka data som lagras och används.
Detta blir särskilt vanligt i projektlednings- och verksamhetsteam, där det ofta är uppenbart att egenutvecklade verktyg är svaret på processrelaterade behov — och med AI-kodningsagenter har det aldrig varit enklare att ge klartecken.
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
För att hjälpa oss förstå vad vi bör vara uppmärksamma på när team börjar bygga tog jag in Tim Fisher, DPM:s VP för AI, för att ge oss en genomgång. Den här artikeln är till för alla som har fått höra: ”Hej chefen, titta på den här coola saken jag byggde med Claude!” — vi hoppas att den kan vara till hjälp.
Först: vad är vibekodning? Och varför är det faktiskt värdefullt?
I den här artikeln betyder vibekodning att koda genom att skriva instruktioner — specifikt utfört av någon som inte är tekniskt kunnig. Detta skiljer sig från när en mjukvaruutvecklare använder ett verktyg som GitHub Copilot, där människan fortfarande bidrar med betydande teknisk kunskap i arbetet. Vi talar om ekonomichefen, verksamhetssamordnaren eller projektledaren som aldrig har skrivit en enda kodrad och nu lanserar fungerande verktyg med inget annat än instruktioner på naturligt språk.
Och Fishers inledande synpunkt kanske överraskar dig: han är genuint entusiastisk över det. ”Jag älskar tanken på att människor som inte kan koda nu kan få ett sätt att ta det de vill ha ut ur huvudet och förvandla det till en form som alla kan se, leka med och använda”, säger han. ”Det är ett sätt att kommunicera som inte fanns tidigare.” Han beskriver det mindre som en teknisk förmåga och mer som ett nytt kommunikationsmedium — ett som överbryggar gapet mellan vision och genomförande för människor som alltid har haft idéer men saknat det tekniska ordförrådet för att uttrycka dem.
Vibekodning är ett sätt att kommunicera som inte fanns tidigare.
”Det liknar lite de utmaningar som människor upplever när de arbetar med designteam”, förklarar Fisher. ”Jag kan inte ens rita en streckgubbe. Och när jag vill kommunicera något visuellt till någon är jag så glad att det nu finns verktyg som låter mig förklara något med många genomtänkta ord, vilket jag är bra på, och få fram något i andra änden som någon annan, som faktiskt kan designa, tittar på och säger: ’Aha, nu förstår jag vad du är ute efter.’”
För ledare är denna omformulering viktig. Impulsen att stänga ner det helt missar det som verkligen är användbart här: vibekodning kan påskynda samsyn, lyfta fram idéer snabbare och ge icke-tekniska teammedlemmar ett nytt sätt att bidra. Frågan är inte om det ska tillåtas. Frågan är om du förstår vad som händer efter att verktyget har byggts.
Där värdet upphör — och risken börjar
Fisher är noga med att skilja ”kommunikationsfasen” i vibekodning från det som brukar följa — och det är där hans ton förändras. ”Jag tror att värdet av det förmodligen oftast upphör där”, säger han. ”Det är ett mycket bättre sätt att kommunicera idéer och riktning. Men vad vi upptäcker är att vissa saker kan hända efter det som blir mer än ’Hej, titta, jag har kommunicerat en idé till dig, vi delar nu ett språk.’ Och det är där det blir skrämmande.”
Problemet är inte instruktionerna. Det är driftsättningen. Det är ögonblicket när en prototyp blir ett verktyg som riktiga människor använder, som lagrar riktiga data och körs i bakgrunden på riktig infrastruktur — medan personen som byggde det fortfarande inte vet vad som händer under ytan.
Säkerhetsbrister som ledare bör känna till
Personuppgifter och datahantering
Den mest intuitiva risken för de flesta ledare handlar om personligt identifierbar information (PII). Fisher använder ett konkret exempel för att visa var gränsen går: ”Jag tror att komplexitetstaket ligger precis före inmatningen av medarbetar- eller kunddata i ett system som återger dessa data för andra människor. Det är då du stöter på PII-problem.”
Jag tror att taket för komplexitet skulle nås precis innan man matar in medarbetar- eller kunddata i ett system som återger dessa data för andra personer.
Risken ökar i takt med uppgifternas känslighet och vilka som kan få tillgång till dem – och i drift- och projektledningsteam omfattar dessa uppgifter ofta kundinformation, personalregister, ersättningsuppgifter eller kontaktuppgifter som medför en verklig juridisk exponering.
Skenande kostnader och tokenanvändning
En risk som överraskar många ledare har inget med data att göra, utan allt med pengar. Fisher beskriver ett scenario som är vanligare än de flesta inser: "Låt oss säga att någon av misstag styr en kodningsagent i fel riktning, vilket leder till att den skapar en loop som körs hela tiden och ständigt drar på sig en dyr avgift. Och innan man vet ordet av kostar ett projekt som ska kosta $5,000 $50,000, eftersom personen inte visste vad som pågick under huven och antog att kodningsagenten skulle upptäcka det."
Icke-tekniska utvecklare är också mindre benägna att generellt optimera tokenanvändningen, vilket innebär att kostnaderna kan ackumuleras tyst och snabbt. Utan insyn i den infrastruktur som deras verktyg körs på kanske dina teammedlemmar inte inser att det finns ett problem förrän räkningen kommer.
API-nycklar och informationssäkerhet
Det är här Fisher kommer in på det område som håller säkerhetsteamen vakna om nätterna. Scenariot han beskriver är ett skolboksexempel på vad som går fel när någon vet precis tillräckligt för att vara farlig: "Ett vanligt misstag är när någon vet precis tillräckligt för att förstå och uttrycka att de behöver en API-nyckel för att få något att hända. De anger nyckeln i en prompt, och den lagras inte på en hemlig plats – den dumpas bara i en fil eller skrivs direkt in i skriptet. Sedan lägger någon upp koden på GitHub, kanske glömmer de att göra den privat, och plötsligt kan API-nyckeln missbrukas av vem som helst som är beredd att göra något illvilligt, som att dra på sig en tokenräkning på $100K.”
Det är lätt att läsa det scenariot och tänka att det kräver en lång kedja av misstag. Fisher invänder mot den instinkten: "Det låter som om det krävs en lång rad osannolika händelser, men det är inte alls osannolikt. Det är faktiskt oerhört vanligt, särskilt bland icke-tekniska personer."
Den kanske mest alarmerande risken Fisher tar upp är en som även erfarna utvecklare har råkat ut för. "Jag har hört skräckhistorier om erfarna utvecklare som lägger in hela kodbasen för ett företag i en kodningsagent och justerar något, varefter hela kodbasen exponeras för ett annat företag helt inom lagens ramar." Om erfarna utvecklare kan göra det här misstaget är riskprofilen avsevärt högre för en icke-teknisk medarbetare som bygger snabbt och utan tillsyn.
Skalbarhetsproblemet – vad händer när det faktiskt fungerar?
Ett av de mer komplicerade samtalen för ledare handlar om vad man ska göra när ett vibe-kodat verktyg faktiskt löser ett problem och människor börjar förlita sig på det. Framgångsfallet kan i tysthet bli en belastning. Fisher är tydlig med det strukturella problemet: "Generellt sett är alla vibe-kodade projekt inte skalbara, främst eftersom du inte ber agenten att ta hänsyn till skalning. Icke-utvecklare ber förmodligen inte ens om sådant som felhantering. Om du inte förstår var fel faktiskt uppstår vet du inte tillräckligt för att säkerställa att agenten fångar upp dem och hanterar dem på rätt sätt."
Generellt sett är inga vibekodade projekt skalbara, främst eftersom du inte ber agenten att ta hänsyn till skalning.
Ansvarsglappet blir som tydligast under press. ”Det som brukar hända är att någon vibekodar något, och sedan fungerar det, men är den här personen teknisk support för produkten dygnet runt?” För ledare inom leverans och drift är detta ögonblicket då ett välmenande internt verktyg blir en organisatorisk risk – eftersom sannolikheten för att det går sönder eller behöver ständig teknisk support ökar ju fler team som förlitar sig på det.
Fishers rekommendation för verktyg som får genomslag är en tydlig överlämning: ”Om du bygger något som människor förlitar sig på måste det bli mer än bara ett vibekodat projekt; det måste tas över av personer som arbetar professionellt med detta och känner till sådant som du inte ens vet att du behöver fråga om.”
Vad ledare kan göra – praktiska skyddsräcken
Inget av detta innebär att svaret är ett generellt förbud. Fisher är konsekvent på den punkten – värdet av vibekodning för personer utan teknisk bakgrund är verkligt, men det hör hemma inom ett specifikt område. ”Värdet av de här verktygen för personer som inte kodar är att kunna ta genvägar för sådant som att skapa samsyn kring en idé och ta sig förbi fasen ’kommer det här att fungera?’”, säger han. Prototypfasen, kommunikationsfasen, fasen ”är det här ens värt att bygga?” – det är där vibekodning glänser och där risken fortfarande går att hantera.
För ledare ser den praktiska handlingsplanen ungefär ut så här: uppmuntra vibekodning som ett verktyg för prototyper och kommunikation, och fastställ en tydlig gräns vid vilken ett verktyg granskas av någon med teknisk expertis innan det börjar användas bredare. Att ha de här samtalen med teamet – så att de förstår riskerna och känner till sina alternativ – är det som skiljer en kultur av klok AI-utforskning från en kultur som bara rusar framåt och hoppas på det bästa.
Målet är inte att vara ledaren som säger nej. Det är att vara ledaren som ser till att teamet vet vad de ger sig in på – så att något fantastiskt som någon bygger faktiskt kan utvecklas vidare.
Vill du ha fler insikter som dessa? Skapa ett kostnadsfritt DPM-konto för att höra från fler experter som dessa.
