KI og produktutvikling14 Aug 2026 · 9 min

Vibbekoding: fra prototype til produksjon

Vibbekoding gjør det mulig å gå fra idé til en fungerende prototype ved å beskrive hva du vil ha, la et KI-verktøy skrive koden og korrigere resultatet i korte runder. Det kan være en svært god måte å utforske et problem på.

Men en prototype som virker på din maskin, er ikke automatisk klar for kunder, persondata eller daglig drift. Veien videre krever et skifte: fra å styre etter det du ser på skjermen til å styre etter tydelige krav, tester og ansvar.

Denne guiden forklarer hva vibbekoding er, når metoden passer, og hvordan en KI-generert prototype kan vurderes før den settes i produksjon.

Hva er vibbekoding?

Vibbekoding, fra det engelske «vibe coding», er en arbeidsform der du beskriver ønsket funksjon i vanlig språk og lar en generativ KI opprette eller endre koden. Når noe feiler, gir du verktøyet feilmeldingen eller beskriver hva som er galt. Deretter prøver dere igjen.

Arbeidsformen kjennetegnes gjerne av:

• korte runder mellom instruksjon og synlig resultat
• mye KI-generert kode
• fokus på om løsningen virker, fremfor hvordan koden er bygget
• begrenset manuell gjennomgang underveis

Det siste punktet skiller vibbekoding fra mer kontrollert KI-assistert utvikling. En utvikler kan bruke samme type verktøy til autoutfylling, testskriving eller avgrensede kodeendringer, men fortsatt lese, forstå og godkjenne hver endring. Da fungerer KI-en mer som en parprogrammerer enn som fører.

Når fungerer vibbekoding godt?

Vibbekoding er særlig nyttig når målet er å lære raskt. Du kan prøve en brukerflyt, visualisere en idé eller lage et internt verktøy med lav konsekvens dersom det feiler.

Gode kandidater er ofte:

• klikkbare prototyper og konsepttester
• små engangsverktøy uten sensitive data
• utforsking av et API eller en ny arbeidsflyt
• enkle interne hjelpemidler med få brukere
• tidlige eksperimenter som skal kastes eller bygges om

Metoden er mindre egnet når løsningen skal håndtere betaling, personopplysninger, tilgangskontroll eller andre oppgaver der feil får reelle konsekvenser. Det samme gjelder systemer som flere utviklere skal vedlikeholde over tid.

Det betyr ikke at prototypen er verdiløs. Den kan ha avklart behovet og gitt teamet noe konkret å diskutere. Men den bør behandles som et utgangspunkt, ikke som bevis på at resten av produktet er ferdig.

Hvorfor stopper mange prototyper før produksjon?

En skjerm kan se ferdig ut selv om systemet bak mangler viktige egenskaper. KI-verktøy er ofte gode til å oppfylle det funksjonelle ønsket i en instruksjon: «lag innlogging», «vis disse radene» eller «send dette skjemaet».

Produksjonskravene ligger ofte mellom linjene. Hvem skal få tilgang? Hva skjer når en tjeneste er nede? Hvordan ruller vi tilbake en feil? Hvor lagres hemmeligheter? Hvem oppdager at jobben har stoppet?

Hvis disse kravene ikke er skrevet ned, kan den genererte koden likevel se overbevisende ut. Vanlige problemer er:

• duplisert eller tett koblet kode som er vanskelig å endre
• manglende validering av data fra brukere og eksterne tjenester
• nøkler eller passord lagret på feil sted
• avhengigheter som ikke er vurdert eller låst til en versjon
• tester som bare dekker den vellykkede hovedflyten
• svak logging og utydelig feilhåndtering
• ingen dokumentert plan for utrulling, gjenoppretting eller eierskap

Mer prompting alene løser ikke dette. På et tidspunkt må teamet stoppe den frie utforskingen og etablere en teknisk grunnmur.

Fra vibe-kodet prototype til produksjon

1. Bestem hva prototypen faktisk har bevist

Start med produktet, ikke kodebasen. Skriv ned hvilket problem prototypen undersøkte, hvem den er for, og hva dere har lært.

Skill mellom tre ting:

1. En bruker klarte å forstå flyten.
2. En teknisk integrasjon fungerte i et kontrollert forsøk.
3. Løsningen tåler vanlig drift over tid.

En prototype beviser ofte det første, noen ganger det andre, og sjelden det tredje. Denne avklaringen hindrer at teamet bruker tid på å polere kode for en idé som ennå ikke er validert.

2. Kartlegg data, brukere og konsekvenser

Lag en enkel oversikt over data som kommer inn, hvor de lagres, hvem som kan lese dem, og hvilke eksterne tjenester som mottar dem. Marker personopplysninger, forretningskritiske data og handlinger som ikke enkelt kan reverseres.

Definer også hva en feil betyr. En ødelagt fargevelger er noe annet enn en feil tilgangskontroll. Konsekvensen bestemmer hvor mye kontroll, testing og menneskelig godkjenning løsningen trenger.

3. Les koden før dere beholder den

Et team må kunne forklare strukturen i systemet før det tar ansvar for drift. Gå gjennom sentrale dataflyter, tilgangskontroll, avhengigheter og grensene mellom komponenter.

Se spesielt etter kode som:

• gjør flere ulike jobber i samme modul
• gjentar samme logikk flere steder
• skjuler feil eller fortsetter etter at noe har gått galt
• bygger SQL, filstier eller kommandoer direkte fra brukerdata
• stoler på data fra nettleseren uten kontroll på serveren
• mangler tydelige typer, kontrakter eller valideringsregler

Dere trenger ikke gjøre alt om til mikrotjenester. En ryddig, modulær applikasjon er ofte enklere å forstå og drifte enn mange små tjenester. Velg arkitektur etter behov, ikke etter hva KI-verktøyet foreslo i siste runde.

4. Refaktorer mot en avtalt arkitektur

Når teamet forstår dagens kode, kan dere bestemme hva som skal beholdes, skrives om eller fjernes. Dokumenter noen få føringer: mappestruktur, datamodell, autentisering, autorisasjon, integrasjoner og hvordan feil håndteres.

Gi KI-verktøyet små, avgrensede oppgaver innenfor disse rammene. Be om en plan og en diff som kan gjennomgås. Unngå store instruksjoner som endrer hele kodebasen på én gang.

Lagre arbeidet i versjonskontroll og gjør små endringer. Da kan teamet se hva som skjedde, vurdere hver endring og gå tilbake dersom noe ble dårligere.

5. Bygg tester som kan si nei

Tester er kontrollsystemet som gjør rask iterasjon tryggere. Start med den atferden som ikke kan svikte, og skriv testene ut fra kravene, ikke ut fra dagens implementasjon.

Et fornuftig minimum kan omfatte:

• enhetstester for kritiske regler og beregninger
• integrasjonstester for database og eksterne tjenester
• ende-til-ende-tester for de viktigste brukerreisene
• tester for ugyldige data, manglende tilgang og avbrutte tjenester

Vær varsom når samme KI-agent både endrer funksjonen og testen som skal kontrollere den. En test kan bli gjort grønn ved å svekke forventningen. Kritiske tester bør gjennomgås separat, og endringer i dem bør være tydelige i kodegjennomgangen.

6. Gjennomfør en sikkerhets- og personverngjennomgang

Sikkerhet kan ikke vurderes bare ved å prøve om innloggingen «ser ut til å virke». Kontroller identitet, sesjoner og tilgang på serversiden. Valider alle eksterne input. Begrens hvilke data og handlinger hver bruker eller tjeneste får tilgang til.

Gå også gjennom:

• hemmeligheter, API-nøkler og miljøvariabler
• tredjepartsavhengigheter og kjente sårbarheter
• logging som kan inneholde personopplysninger eller nøkler
• opplasting og behandling av filer
• hastighetsbegrensning og beskyttelse mot misbruk
• sletting, lagringstid og tilgang til data

Kravene vil variere med løsningen. Poenget er at noen navngitte personer må gjøre vurderingen og dokumentere beslutningene.

7. Gjør løsningen observerbar

I produksjon kan dere ikke sitte og se på hver brukerflyt. Systemet må selv gi signaler når noe går galt.

Legg inn strukturert logging, målinger for kritiske jobber og varsling for feil som krever handling. Definer hva teamet trenger å vite: om en integrasjon svarer, om en bakgrunnsjobb har stoppet, eller om feilraten endrer seg.

Logg nok til å feilsøke, men ikke mer data enn dere har grunn til å lagre. Test også at varslene faktisk når en person som kan følge opp.

8. Planlegg utrulling og tilbakerulling

En produksjonssetting bør være repeterbar. Miljøvariabler, databaseendringer og byggesteg må være dokumentert eller automatisert. Kjør testene i leveranseløpet, ikke bare på utviklerens maskin.

Før lansering bør teamet vite:

• hvem som godkjenner utrullingen
• hvordan data migreres og sikkerhetskopieres
• hvordan en feil versjon rulles tilbake
• hvem som følger med etter lansering
• hvordan brukere får hjelp dersom noe stopper

En begrenset lansering til få brukere kan redusere konsekvensen av ukjente feil. Den erstatter ikke testing, men gjør det mulig å lære under kontrollerte forhold.

9. Avtal eierskap og vedlikehold

Produksjonsklar kode må kunne overtas av mennesker som ikke satt i den opprinnelige KI-samtalen. Legg ved en kort arkitekturbeskrivelse, oppsettsinstruksjoner og en oversikt over viktige beslutninger.

Avklar hvem som eier produktet, kodebasen, driften og sikkerhetsoppfølgingen. Bestem også hvordan avhengigheter oppdateres, feil prioriteres og tilgang fjernes når roller endres.

Hvis ingen kan forklare eller vedlikeholde løsningen uten å be KI-verktøyet gjette, er den ikke klar for produksjon.

Skal dere herde prototypen eller bygge på nytt?

Det er ikke alltid riktig å redde den genererte kodebasen. Bruk denne vurderingen som startpunkt:

| Situasjon | Mest sannsynlige neste steg | | --- | --- | | Liten løsning, tydelig struktur, lav risiko og relevante tester | Herd og videreutvikle trinnvis | | God brukerflyt, men uklar arkitektur og lite testdekning | Behold design og læring, vurder å skrive om kjernen | | Sensitive data, svak tilgangskontroll eller ukjente avhengigheter | Stopp utrulling og gjennomfør teknisk og sikkerhetsmessig vurdering | | Koden er vanskelig å forklare, endringer bryter tilfeldige deler, og ingen eier den | Bygg på nytt fra dokumenterte krav | | Idéen er ikke validert hos faktiske brukere | Test behovet før dere investerer i produksjonsarbeid |

En omskriving er ikke nødvendigvis et nederlag. Prototypen kan ha gjort jobben sin ved å avklare produktet raskt.

Sjekkliste før produksjon

Bruk listen som en stoppkontroll, ikke som pynt i en lanseringsplan:

• [ ] Vi kan forklare arkitekturen og de viktigste dataflytene.
• [ ] Funksjonelle og ikke-funksjonelle krav er skrevet ned.
• [ ] Tilgang kontrolleres på serveren og følger minste nødvendige tilgang.
• [ ] Input, feiltilfeller og eksterne avbrudd er testet.
• [ ] Kritiske tester kan ikke endres ubemerket sammen med funksjonen.
• [ ] Hemmeligheter ligger utenfor kodebasen.
• [ ] Avhengigheter er gjennomgått og kan oppdateres.
• [ ] Logger og varsler gjør det mulig å oppdage og undersøke feil.
• [ ] Utrulling, sikkerhetskopi og tilbakerulling er prøvd.
• [ ] En navngitt person eller et team eier drift og vedlikehold.
• [ ] Dokumentasjonen er tilstrekkelig for en ny utvikler.
• [ ] En menneskelig kodegjennomgang er gjennomført.

Verktøyet er mindre viktig enn kontrollene

Verktøy for vibbekoding endrer seg raskt. Noen har visuell bygging i nettleseren, mens andre arbeider direkte i editor og terminal. Det viktigste valget er ikke hvilket verktøy som genererer flest linjer kode. Det er hvilke kontrollmekanismer dere har rundt arbeidet.

For en prototype kan rask tilbakemelding være hovedmålet. For et produkt i drift teller også forståelig kode, tydelig ansvar, sikker databehandling og muligheten til å rette feil uten å skape nye.

Vibbekoding kan korte ned veien til noe dere kan se og prøve. Produksjonsarbeidet begynner når teamet tar ansvar for alt brukeren ikke ser.

Har dere en KI-generert prototype og trenger en nøktern vurdering av veien videre? Start en samtale.