Vad är vibe coding? Fördelar och fallgropar för IT

Vibe coding är ett sätt att bygga programvara där du beskriver vad du vill ha med vanligt språk och en AI skriver koden åt dig. Du testar resultatet och ber om justeringar, ofta utan att granska varje rad kod. Begreppet myntades av Andrej Karpathy (medgrundare av OpenAI och tidigare AI-chef på Tesla) i ett inlägg på X i början av 2025. Han beskrev det som ett sätt att "fullt ut ge sig hän åt känslan" och låta AI:n göra det tunga arbetet, och menade det främst för engångsprojekt. Den mer granskade, professionella varianten kallas numera ofta agentic engineering.

För många IT-avdelningar har det gått från kuriosa till vardag på mycket kort tid. Affärsanvändare bygger egna verktyg på en eftermiddag, och utvecklare får fram prototyper på minuter. Men det som går snabbt att starta är inte alltid snabbt att förvalta. I den här artikeln går vi igenom hur vibe coding fungerar, vad som är bra med det och vad du som arbetar med IT behöver ha koll på.

Hur fungerar vibe coding?

Grundidén är enkel. Du skriver en beskrivning av vad du vill åstadkomma, till exempel "bygg ett formulär där medarbetare kan boka skrivbord, med en adminvy för att se beläggning". AI:n genererar kod, ofta både gränssnitt och logik, och du kör den direkt för att se resultatet. Är något fel, säger du till vad som ska ändras och AI:n justerar.

Det finns i dag tre huvudsakliga sätt att arbeta på:

1. AI-assistenter och agenter i utvecklingsmiljön, som GitHub Copilot och Cursor.
2. Kodagenter som arbetar mot hela kodbasen, ofta från terminalen, som Claude Code.
3. Webbaserade appbyggare där hela appen genereras, körs och hostas i webbläsaren, inklusive Microsofts lösningar i Power Platform.

Skillnaden mellan dem är hur mycket kontroll du har över koden, datan och hostingen, och hur mycket du som människa faktiskt granskar på vägen.

Inom Microsoft 365 och Power Platform finns flera vägar: Copilot i Power Apps, Power Apps Code Apps (React/TypeScript som körs i Power Platform-miljön med DLP och miljöstyrning) samt agent- och appbyggande i Copilot Studio och Microsoft 365 Copilot. Microsofts verktyg inom området byter namn och ersätts snabbt, så kontrollera status i Message Center innan ni standardiserar på ett enskilt verktyg.

Det viktiga att förstå är att steg fyra kan upprepas många gånger, och att varje varv gör koden lite större och lite svårare att överblicka. Det är där både styrkan och riskerna börjar.

Info: Vibe coding är ett spektrum. I ena änden sitter någon som aldrig tittar på koden. I andra änden sitter en erfaren utvecklare som använder AI som snabbt hjälpmedel men granskar allt. Det som är mest relevant för IT finns någonstans där emellan.

Varför är vibe coding viktigt?

Vibe coding förändrar vem som kan bygga digitala lösningar. Tidigare krävde det en utvecklare, en backlogg och ofta flera veckors väntan. Nu kan en controller bygga sitt eget rapportverktyg eller en projektledare sin egen planeringsapp. Det flyttar kraft ut i verksamheten, men det flyttar också ansvar och risk.

Det som är bra med vibe coding

Det finns goda skäl till att tekniken fått så stort genomslag:

1. Hastighet. En idé kan bli en fungerande prototyp på en timme i stället för på veckor. Det gör det billigt att testa om något över huvud taget är värt att bygga.
2. Lägre tröskel. Personer utan programmeringsbakgrund kan skapa egna lösningar och visualisera behov, vilket ofta ger bättre beställningar till IT.
3. Bättre kravdialog. Att visa en körbar prototyp är ofta mer träffsäkert än att skriva en kravspecifikation. Alla ser direkt vad som menas.
4. Avlastning för utvecklare. Rutinmässig kod, enkla integrationer och tester kan delegeras till AI så att utvecklarna kan fokusera på arkitektur och svåra problem.

Vilka risker finns med vibe coding? Säkerhet, förvaltning och teknisk skuld

Prototypen är sällan problemet. Problemet uppstår när den börjar användas på riktigt.

1. Man underskattar tiden att bygga vidare. De första 80 procenten går förbluffande fort, vilket skapar en felaktig bild av hur lång tid resten tar. Den sista delen, alltså felhantering, behörigheter, prestanda, integrationer och dokumentation, tar ofta minst lika lång tid som själva prototypen. Exakta proportioner varierar kraftigt mellan projekt, men mönstret återkommer. När koden dessutom inte är skriven med en tydlig struktur blir varje ny funktion svårare att lägga till. AI:n kan ibland ändra saker som redan fungerade och skapa regressioner. Motmedlet är versionshantering (Git) med små, granskningsbara commits, automatiska tester som körs i CI innan varje ändring accepteras, och att man ger AI-agenten tydliga ramar, till exempel instruktionsfiler för projektet, i stället för att låta den ändra fritt.

2. Säkerheten blir lätt eftersatt. AI-genererad kod fungerar ofta, men fungerar är inte samma sak som säker. Flera oberoende studier har visat att en betydande andel AI-genererad kod innehåller säkerhetsbrister, och i våra uppdrag ser vi regelbundet hårdkodade nycklar och för generösa behörigheter i interna appar som skapats utan granskning. Vanliga problem är:

1. hårdkodade hemligheter, som nycklar och lösenord
2. bristande indatavalidering (XSS, injection)
3. brutna åtkomstkontroller och saknade CSRF-skydd
4. beroenden till paket som ingen granskat, eller som inte ens finns. AI-modeller kan hallucinera paketnamn som angripare sedan registrerar med skadlig kod, så kallad slopsquatting

Minimikrav är secret scanning och push protection, SAST och beroendeskanning (till exempel GitHub Advanced Security eller Dependabot) i CI, hemligheter i Azure Key Vault, managed identities i stället för nycklar, samt obligatorisk pull request-granskning för kod som går mot produktion. Den som inte läser koden ser inte heller riskerna.

3. Förvaltningen saknar ägare. Vem ansvarar när appen går ner, när ett beroende får en sårbarhet eller när personen som byggde den byter jobb? Utan dokumentation, tester och en tydlig förvaltningsmodell blir en snabbt hopkommen app ett nytt hörn av skuggIT, alltså system och appar som används i verksamheten utan IT:s vetskap eller kontroll, och som ingen riktigt äger.

4. Teknisk skuld växer i det tysta. Kod som ingen förstår är svår att felsöka. Det som sparades i utvecklingstid betalas tillbaka med ränta i underhållstid.

OBS: Lägg aldrig in känsliga uppgifter, som kunddata, personuppgifter eller nycklar, i verktyg som inte är godkända av er organisation. Kontrollera också hur verktyget hanterar den kod och de data du skickar in.

Vibe coding i praktiken: tre exempel från verksamheter

Låt oss titta på tre situationer som många IT-avdelningar känner igen.

Exemplet som fungerar bra: prototypen. En produktägare vill visa hur en ny kundportal kan se ut. Hen bygger en klickbar version på två timmar, visar den för intressenterna och får tydlig feedback innan en enda utvecklingstimme lagts. Prototypen kastas sedan och byggs om ordentligt. Här är vibe coding precis rätt verktyg: snabbt, billigt och utan risk, eftersom prototypen ändå kastas.

Exemplet som blir riskabelt: det interna verktyget. En medarbetare bygger en app som sammanställer försäljningsdata från ett Excel-ark och delar den med teamet. Den blir populär och tre månader senare använder femtio personer den dagligen. Ingen har granskat var datan lagras, vem som kommer åt den eller vad som händer om skaparen slutar. Det som började som ett smart hjälpmedel har blivit verksamhetskritiskt utan att någon bestämt det. Samma mönster ser vi i digitala arbetsplatser på Microsoft 365, där Copilot, Power Platform och andra low-code-verktyg gör det lätt för medarbetare att bygga egna lösningar utanför IT:s överblick.

Exemplet med erfaren utvecklare: AI som medarbetare. Ett utvecklingsteam använder en AI-assistent för att skriva tester, generera standardkod och föreslå refaktoreringar. Allt går genom kodgranskning, och riktlinjerna för säkerhet gäller som vanligt. Resultatet är snabbare leverans utan att kvaliteten tappas. Det här är ofta det mest hållbara sättet att använda tekniken.

Vanliga frågor om vibe coding

Kom igång med vibe coding

Det bästa sättet att börja är att ta fram tydliga spelregler innan någon byggt något. Då slipper ni jaga efter appar i efterhand.

1. Bestäm var det är okej och gör det tekniskt styrbart. Tillåt vibe coding fritt för prototyper och personliga verktyg, men kräv granskning för allt som rör kunddata eller används av många. Ge makers en avgränsad sandbox-miljö med DLP-policyer, tillåt inte produktionsdata där, och kräv att appar som delas till fler än ett definierat antal användare flyttas till en styrd miljö. Använd inventering och rapportering i Power Platform admin center samt Microsoft Purview för att hitta appar och agenter som skapats utan att IT känner till dem.
2. Godkänn verktygen. Välj ut ett par verktyg som passar er säkerhetsnivå och dataskyddskrav, så att medarbetarna inte tar till egna lösningar. Komplettera med miljöstrategi (dev/test/prod), Managed Environments, Entra ID-baserad åtkomst och sensitivity labels.
3. Definiera en väg till produktion. Ha en enkel process för hur en prototyp som blivit värdefull tas över av IT eller utvecklingsteamet och byggs på ordentligt, med källkodshantering, CI/CD, automatiska tester, miljöseparering och övervakning.
4. Utse ägare. Varje app ska ha en ansvarig person för drift, uppdateringar och avveckling.
5. Budgetera för resten. Räkna med att resan från fungerande prototyp till stabil lösning tar betydligt längre tid än själva prototypen.

Tips: Använd vibe coding för att lära er vad ni behöver, inte för att slippa bygga det ordentligt. Prototypen är ett utmärkt underlag för beställning, men sällan det färdiga svaret.

Sammanfattningsvis: Vibe coding är ett kraftfullt sätt att snabbt förvandla idéer till något man kan klicka på. Fördelarna är påtagliga, men det är riskerna också. Den som bygger in säkerhet, ägarskap och en realistisk bild av tiden för att bygga vidare får ut det bästa av tekniken.

Vill ni ha hjälp att sätta riktlinjer för AI-byggda lösningar och en trygg väg från prototyp till produktion? Som konsulter inom digital verksamhetsutveckling och Microsoft 365 hjälper vi på Boostly er med styrning, förändringsledning och Copilot-implementation, oavsett om ni bygger på Microsoft 365 eller kombinerar med andra verktyg.