Vibe coding i bedrift: Risiko, kvalitet og ansvar

Vibe coding er et begrep som ble lansert i 2025. Det beskriver en måte å jobbe på der du forklarer hva du vil med vanlige ord, og kunstig intelligens skriver koden for deg.

I sin enkleste form betyr det å stole helt på det verktøyet lager — uten å lese eller forstå koden. De fleste bruker en mellomvariant: Kunstig intelligens skriver, mennesker sjekker.

Det er den ukontrollerte formen som skaper problemer. Når ingen leser koden, samles det opp feil som blir dyrere å fikse jo lenger de får stå.

Tall fra 2026 gir et tydelig bilde:

• I en undersøkelse blant 18 ledere for utviklingsteam oppga 16 at de hadde opplevd alvorlige kvalitetsproblemer innen 90 dager etter at teamene begynte med vibe coding uten regler.

• Kode skrevet med hjelp av kunstig intelligens har nesten dobbelt så mange alvorlige feil som kode skrevet for hånd.

• Team som starter med vibe coding uten tydelige regler, opplever at antall feil dobles i løpet av 4–12 uker.

Det betyr ikke at vibe coding er farlig. Det betyr at du trenger regler for hva som alltid skal sjekkes av et menneske.

Forskning viser at nesten halvparten av AI-skrevet kode har sikkerhetshull. Her er de vanligste:

Passord og nøkler i synlig kode. Kunstig intelligens legger ofte passord og hemmelige nøkler rett i koden. Hvis koden deles eller publiseres, kan hvem som helst se dem.

Data vises til feil person. I en kjent hendelse fra 2025–2026 ble 18 000 brukeres data eksponert fordi appen ikke sjekket hvem som ba om informasjonen. Brukeren kunne se andre brukeres opplysninger bare ved å endre en verdi i nettadressen.

Appen stoler på alt brukeren sender inn. AI-skrevet kode sjekker sjelden om det brukeren sender inn er trygt. Det betyr at noen kan sende skadelig innhold gjennom et vanlig skjemafelt.

Svak innlogging. Kunstig intelligens lager ofte forenklede innloggingsløsninger uten krav til sterke passord eller beskyttelse mot gjentatte forsøk.

Du trenger ikke en tung prosess. Fire enkle regler er nok.

1. Én person godkjenner alt som berører data eller brukere. Skriv ned hvem det er. Hvis ingen har ansvaret, er ingen ansvarlig — og da skjer det feil.

2. Test før publisering, hver gang. Minimum: Sjekk at innlogging fungerer, at brukere bare ser sine egne data, og at skjemaer ikke aksepterer hva som helst.

3. Bruk en fast sjekkliste.

• Ingen passord eller nøkler i synlig kode
• All data krever innlogging
• Alt brukeren sender inn valideres
• Forbindelsen er kryptert
• Feilmeldinger viser ikke tekniske detaljer

4. Skill mellom lav og høy risiko. Endring av tekst eller farger kan gjøres fritt. Endringer i innlogging, betaling eller databehandling krever alltid menneskelig godkjenning.

Med tydelige regler blir verktøyvalget enklere. De fleste team har nytte av to verktøy: Ett for daglige endringer og ett for større oppgaver.

Cursor gir deg forslag mens du koder og passer best til løpende endringer. Verktøyet har over 2 millioner brukere og er det mest brukte AI-kodeverktøyet i 2026.

Claude Code fungerer mer selvstendig — du beskriver oppgaven og lar verktøyet jobbe på egenhånd. Sammen dekker de to ulike arbeidsmåter som utfyller hverandre godt.

For større oppgaver — som å rydde opp i sikkerhet på tvers av mange filer, eller refaktorere en hel modul — fungerer Claude Code bedre enn sanntidsforslag. Du beskriver hva som skal gjøres, og verktøyet leser gjennom prosjektet, gjør endringene, kjører tester og retter feil selvstendig.

Denne arbeidsmåten passer godt sammen med sjekklisten over: Teamet delegerer oppgaven, og den ansvarlige sjekker resultatet mot de faste punktene før noe publiseres.

Små team trenger ikke tunge prosesser. Men de trenger faste tidspunkter for å sjekke kvalitet.

Mandag: Hvilke endringer skal gjøres denne uken? Hvilke er lavrisiko, hvilke krever ekstra sjekk?

Onsdag: Bruk 30 minutter på å gå gjennom det som er bygget. Kjør sjekklisten på alle nye endringer.

Fredag: Bare endringer som er sjekket og testet publiseres. Alt annet venter til neste uke.

Eksempel: Et teknologiselskap med fem utviklere oppdaget tre sikkerhetshull i løpet av to uker med ustrukturert vibe coding. De innførte ukerytmen over, og antall feil som nådde produksjon gikk ned med over halvparten i løpet av første måned. Den viktigste endringen var at noen faktisk hadde ansvar for å sjekke.

En vanlig misforståelse er at AI-verktøyet har ansvar for koden det lager. Det har det ikke.

Hvis AI-kode eksponerer kundedata, er det bedriftens ansvar. Hvis en feil fører til nedetid, er det teamet som publiserte koden som er ansvarlig.

Dette er ikke et argument mot vibe coding. Det er et argument for å behandle AI-kode som kode fra en ny kollega: Du sjekker den, tester den og godkjenner den før den brukes.