Fart er nyttig — ukontrollert fart er dyr

Begrepet «vibe coding» ble lansert av Andrej Karpathy i februar 2025. Det beskriver en arbeidsmåte der du forklarer hva du vil med vanlige ord, og kunstig intelligens skriver koden. I sin reneste form betyr det å stole helt på det AI-verktøyet lager uten å lese eller forstå koden. I praksis bruker de fleste en mellomvariant: AI skriver, mennesker sjekker.

Det er den reneste formen som skaper problemer for bedrifter. Når ingen leser koden, akkumuleres feil, sikkerhetshull og dårlige valg som blir stadig dyrere å rette.

Dokumenterte konsekvenser:

• En undersøkelse blant 18 ingeniørledere viste at 16 av dem opplevde alvorlige kvalitetshendelser innen 90 dager etter at teamene begynte med vibe coding uten tydelige regler.
• AI-assistert kode inneholder ifølge forskning 1,7 ganger flere alvorlige feil enn kode skrevet manuelt.
• Team som tar i bruk AI-koding uten styringsregler, opplever typisk at antall feil dobles i løpet av 4–12 uker.

Det betyr ikke at vibe coding er farlig i seg selv. Det betyr at bedrifter trenger tydelige regler for hva som er lov å gjøre uten menneskelig sjekk, og hva som alltid krever gjennomgang.

Forskning fra 2026 viser at 45 prosent av AI-generert kode inneholder sikkerhetshull som kan utnyttes. De vanligste problemene er:

1. Hemmelige nøkler i synlig kode AI-verktøy legger ofte hemmelige nøkler, passord og tilgangstokens direkte i koden i stedet for å bruke sikre miljøvariabler. Hvis koden deles eller publiseres, er nøklene åpne for alle.

2. Databasespørringer uten tilgangskontroll En dokumentert hendelse fra 2025–2026 involverte en app bygget med en AI-appbygger der 18 000 brukeres data ble eksponert. Årsaken var at databasespørringene kjørte direkte i nettleseren uten å sjekke hvem som ba om data. Brukeren kunne se andre brukeres informasjon bare ved å endre en verdi i nettadressen.

3. Manglende validering av brukerdata AI-generert kode sjekker sjelden at det brukeren sender inn er trygt. Det åpner for angrep der en bruker kan sende skadelig kode gjennom et vanlig skjemafelt.

4. Svak eller manglende innlogging Kunstig intelligens lager ofte forenklede innloggingsløsninger som mangler krav til sterke passord, tidsbegrensning av økter, eller beskyttelse mot gjentatte innloggingsforsøk.

Disse problemene oppstår ikke fordi verktøyene er dårlige, men fordi de prioriterer å gi deg et raskt resultat. Sikkerhet er sjelden en del av det raske resultatet.

Du trenger ikke en tung prosess for å bruke vibe coding trygt. Men du trenger fire tydelige regler som hele teamet følger.

1. Alt som påvirker data eller brukere, sjekkes av en person Bestem hvem som er ansvarlig for å godkjenne endringer før de publiseres. Skriv navnet ned. Hvis det ikke er tydelig hvem som godkjenner, er ingen ansvarlig — og da skjer det feil.

2. Test før publisering, hver gang En test trenger ikke være avansert. Minimum er å sjekke at innlogging fungerer, at brukere bare ser sine egne data, at skjemaer validerer innholdet, og at feilsituasjoner håndteres uten å vise teknisk informasjon til brukeren.

3. Hold en sikkerhetsjekkliste Bruk en fast sjekkliste med minst disse punktene:

• Ingen hemmelige nøkler i kildekoden
• All datatilgang krever innlogging
• Brukerdata valideres på serversiden, ikke bare i nettleseren
• Forbindelsen er kryptert
• Feilmeldinger avslører ikke tekniske detaljer

4. Begrens hva AI-verktøyet kan gjøre uten godkjenning Ikke alle endringer trenger manuell gjennomgang. Definer hva som er lavrisiko (for eksempel endring av tekst eller farger) og hva som alltid krever menneskelig godkjenning (for eksempel endringer i tilgangsstyring, betalingslogikk eller databehandling).

Små team trenger ikke tunge prosesser, men de trenger faste tidspunkter for kvalitetsarbeid. Uten det bygger risikoen seg opp uke for uke.

En enkel rytme som fungerer for team med 2–6 personer:

Mandag: Planlegg ukens endringer og vurder risiko Hvilke endringer skal gjøres denne uken? Hvilke er lavrisiko og kan gjøres fritt? Hvilke berører data, sikkerhet eller brukeropplevelse og krever ekstra sjekk?

Onsdag: Kort kvalitetsgjennomgang Bruk 30 minutter på å sjekke det som er bygget så langt. Kjør sikkerhetsjekklisten på alle nye endringer. Fang problemer mens de er billige å rette.

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

Eksempel fra praksis: Et norsk teknologiselskap med fem utviklere innførte denne ukerytmen etter at de oppdaget tre sikkerhetshull i løpet av to uker med ustrukturert vibe coding. Etter innføringen gikk antall feil som nådde produksjon ned med over halvparten i løpet av den første måneden. Den viktigste endringen var ikke prosessen i seg selv, men at noen faktisk hadde ansvar for å sjekke endringene før de ble publisert.

En vanlig misforståelse er at AI-verktøyet har en form for ansvar for koden det genererer. Det har det ikke. Ansvaret ligger alltid hos bedriften og teamet som tar koden i bruk.

Det betyr:

• Hvis AI-generert kode eksponerer kundedata, er det bedriftens ansvar — ikke verktøyleverandørens.
• Hvis en feil i AI-skrevet kode fører til nedetid eller tap, er det teamet som valgte å publisere den som er ansvarlig.
• Lisensvilkårene til de fleste AI-kodeverktøy fraskriver eksplisitt ansvar for kvaliteten på generert kode.

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

Når dere har tydelige regler for kvalitet, blir verktøyvalget enklere. Mange team får en god kombinasjon ved å bruke ett verktøy til daglige endringer og ett verktøy til større oppgaver som krever mer strukturert gjennomgang.