KI og produktutviklingHafsteinn Runarsson · AI Konsulent14 Aug 2026 · 8 min

Vibbekoding i produksjon: fra prototype til robust løsning

En vibbekodet prototype er klar for produksjonsarbeid først når teamet kan forklare hvordan den virker, kontrollere risikoen og drifte den uten å være avhengig av den opprinnelige KI-samtalen. Det krever en systematisk vurdering av arkitektur, tester, sikkerhet, personvern, observabilitet, utrulling og eierskap.

Er du ute etter en introduksjon til arbeidsformen, kan du først lese hva vibe coding og vibbekoding betyr. Her tar vi utgangspunkt i at prototypen allerede finnes, og konsentrerer oss om arbeidet som må gjøres før reelle brukere og data slippes til.

Start med en produksjonsvurdering, ikke en lanseringsdato

Det første spørsmålet er ikke «Når kan vi lansere?», men «Hva har prototypen faktisk bevist?». En fungerende brukerflyt viser at ideen kan visualiseres og prøves. Den viser ikke automatisk at løsningen tåler feil, flere brukere, sensitive data eller endringer over tid.

Avklar derfor tre nivåer hver for seg:

1. Behovet: Har faktiske brukere bekreftet at løsningen hjelper dem med riktig problem?
2. Funksjonen: Virker de viktigste brukerreisene med realistiske data og feiltilfeller?
3. Driften: Kan teamet overvåke, oppdatere og gjenopprette løsningen på en kontrollert måte?

Hvis behovet fortsatt er uklart, bør dere fortsette valideringen før dere investerer i teknisk herding. En MVP avgrenser hva som må læres før neste investering, mens en produksjonsvurdering avgjør hva som må kontrolleres før løsningen tas i varig bruk.

Lag deretter en enkel risikoprofil. Kartlegg hvem som skal bruke løsningen, hvilke data som behandles, hvilke handlinger som ikke lett kan reverseres, og hva en feil vil bety. Risikoen bestemmer hvor omfattende gjennomgangen må være.

Velg hva som skal beholdes, skrives om eller fjernes

Produksjonsarbeidet blir enklere når teamet tar en eksplisitt beslutning om kodebasen. Ikke behold kode bare fordi den allerede finnes, og ikke skriv alt på nytt bare fordi KI har generert det.

Gå gjennom de viktigste dataflytene og komponentene. Teamet bør kunne svare på:

• Hvor kommer data inn, og hvor lagres de?
• Hvor kontrolleres identitet og tilgang?
• Hvilke eksterne tjenester er løsningen avhengig av?
• Hvordan håndteres feil, tidsavbrudd og delvise resultater?
• Hvilke moduler inneholder kritisk forretningslogikk?
• Hvilke deler kan ingen i teamet forklare eller teste?

Bruk svarene til å dele koden i tre grupper:

• Behold: Koden er forståelig, avgrenset og dekket av relevante tester.
• Refaktorer: Funksjonen er riktig, men ansvar, grensesnitt eller feilhåndtering er uklare.
• Skriv om eller fjern: Koden kan ikke forklares, er tett koblet eller skaper uakseptabel risiko.

Målet er ikke en bestemt arkitekturstil. Målet er en struktur som teamet kan forstå, teste og endre. For mange små tjenester kan være like vanskelig å drifte som én uoversiktlig applikasjon. Velg grenser ut fra data, ansvar og driftsbehov.

Etabler en arkitektur teamet kan forklare

En produksjonsklar arkitektur gjør viktige beslutninger synlige. Dokumenter noen få føringer før KI-verktøyet får gjøre flere endringer: komponentansvar, datamodell, autentisering, autorisasjon, integrasjoner og prinsipper for feilhåndtering.

Kontroller særlig om koden:

• blander presentasjon, datatilgang og forretningsregler i samme modul
• gjentar kritisk logikk flere steder
• stoler på data fra nettleseren uten kontroll på serveren
• bygger spørringer, filstier eller kommandoer direkte fra brukerdata
• skjuler feil eller fortsetter etter et ufullstendig resultat
• mangler tydelige kontrakter mellom egne komponenter og eksterne tjenester

Når rammene er satt, kan KI fortsatt brukes til avgrensede endringer. Be om små differ, en forklaring av antakelsene og en testplan. Lagre endringene i versjonskontroll og gjennomgå dem i håndterbare porsjoner. Da kan teamet forstå konsekvensene og gå tilbake hvis en endring gjør løsningen dårligere.

Bygg tester som kan stoppe en dårlig endring

Tester skal fungere som en port, ikke bare som dokumentasjon. Start med atferden som ikke kan svikte, og skriv forventningene ut fra kravene fremfor dagens implementasjon.

En målrettet testpakke bør dekke:

• enhetstester for kritiske regler og beregninger
• integrasjonstester for database, køer og eksterne tjenester
• ende-til-ende-tester for de viktigste brukerreisene
• ugyldige data, manglende tilgang og avbrutte avhengigheter
• migreringer og annen logikk som endrer lagrede data

Prioriter etter konsekvens. En feil som gir feil person tilgang til data, krever sterkere kontroll enn en kosmetisk feil. For AI-baserte funksjoner må dere også teste kvaliteten på selve resultatet og hva som skjer når modellen gir et uventet svar. Se den praktiske veiledningen til testing av programvare og AI-systemer for en mer detaljert teststrategi.

Vær ekstra varsom når samme KI-agent endrer både funksjonen og testen som skal kontrollere den. En grønn test er verdiløs hvis forventningen er svekket for å passe implementasjonen. Kritiske testendringer bør vises tydelig og vurderes separat i kodegjennomgangen.

Gjennomgå sikkerhet og personvern før ekte data brukes

Sikkerhet og personvern må vurderes før prototypen kobles til reelle brukere og datasett. En innlogging som ser riktig ut på skjermen, forteller ikke om tilgangskontrollen faktisk håndheves på serveren.

Kartlegg hele datareisen:

1. Hvilke data samles inn?
2. Hvor sendes og lagres de?
3. Hvem og hvilke tjenester kan lese eller endre dem?
4. Hvor lenge beholdes de?
5. Hvordan rettes eller slettes de?

Gå deretter gjennom kontrollene rundt:

• identitet, sesjoner og autorisasjon på serveren
• validering av alle eksterne input
• hemmeligheter, API-nøkler og miljøvariabler
• tredjepartsavhengigheter og oppdateringsrutiner
• filopplasting og behandling av uventede filtyper
• hastighetsbegrensning og beskyttelse mot misbruk
• logger som kan inneholde personopplysninger eller hemmeligheter
• sletting, lagringstid og tilgang til sikkerhetskopier

Vurderingen må ha en navngitt eier og dokumenterte beslutninger. Hvis teamet ikke vet hvilke data som går til en ekstern tjeneste, er løsningen ikke klar til å behandle reelle data.

Gjør feil synlige med observabilitet

En løsning er ikke driftbar før teamet kan oppdage at den svikter. Logging alene er ikke nok; dere trenger signaler som viser om kritiske brukerreiser og bakgrunnsjobber faktisk fungerer.

Definer først hva dere må vite:

• Svarer de viktigste endepunktene som forventet?
• Fullføres kritiske jobber innen rimelig tid?
• Øker feilraten etter en utrulling?
• Feiler en ekstern integrasjon helt eller delvis?
• Når nærmer kapasitet eller kostnad seg en avtalt grense?

Legg inn strukturert logging, relevante målinger og varsler som peker til en konkret handling. Logg nok til å feilsøke, men unngå data dere ikke trenger å lagre. Test også varslingskjeden: Et varsel har liten verdi hvis det ikke når en person som kan undersøke og handle.

Dokumenter en enkel respons for de mest sannsynlige hendelsene. Den bør forklare hvordan teamet avgrenser feilen, reduserer konsekvensen og gjenoppretter tjenesten.

Planlegg utrulling og tilbakerulling sammen

En utrulling er først trygg når teamet også vet hvordan den kan stanses eller reverseres. Produksjonssettingen bør være repeterbar, og kritiske kontroller bør kjøres i leveranseløpet fremfor bare på en utviklers maskin.

Før lansering må dere avklare:

• hvem som godkjenner produksjonssettingen
• hvordan konfigurasjon og hemmeligheter håndteres
• hvordan databaseendringer gjennomføres og reverseres
• hvordan data sikkerhetskopieres og gjenopprettes
• hvilke automatiske tester som må være grønne
• hvilke målinger som følges under og etter utrullingen
• når utrullingen skal stoppes eller rulles tilbake

Start gjerne med en begrenset gruppe brukere eller gradvis aktivering. Det reduserer konsekvensen av ukjente feil, men erstatter ikke testing. En strukturert produktutviklingsprosess fra idé til lansering kan hjelpe med beslutningspunkter rundt pilot, lansering og videre forbedring.

Øv på tilbakerulling før den trengs. Hvis planen bare finnes som en antakelse, er den ikke en reell sikkerhetsmekanisme.

Avtal eierskap før overlevering

Produksjonsklar programvare må kunne overtas av mennesker som ikke var med i den opprinnelige KI-samtalen. Kunnskap som bare finnes i prompt-historikken, er ikke tilstrekkelig dokumentasjon.

Sørg for at en ny utvikler kan finne:

• en kort arkitekturbeskrivelse og de viktigste dataflytene
• oppsetts- og leveranseinstruksjoner
• sentrale tekniske beslutninger og kjente begrensninger
• oversikt over avhengigheter og integrasjoner
• prosedyrer for varsler, feilretting og gjenoppretting
• ansvarlige personer for produkt, kode, drift og sikkerhet

Avklar også hvordan avhengigheter oppdateres, feil prioriteres og tilganger fjernes når roller endres. Arbeidet bør inngå i en varig forbedringsprosess, ikke bli et engangsløft rundt lanseringen. For større organisatoriske endringer kan en praktisk plan for digital transformasjon gi en ramme for eierskap, måling og innføring.

Hvis ingen kan vedlikeholde løsningen uten å be KI-en gjette hva som ble bygget, er den ikke klar for produksjon.

Skal prototypen herdes eller bygges på nytt?

Valget bør styres av forståelighet, risiko og kostnaden ved videre endring. Bruk denne vurderingen som et praktisk utgangspunkt:

• Herd trinnvis: Kodebasen er liten, forståelig og har tydelige grenser. Kritiske deler kan testes uten en omfattende omskriving.
• Behold brukerflyten, skriv om kjernen: Produktideen er validert, men dataflyt, tilgang eller arkitektur er uoversiktlig.
• Stopp og gjennomfør en egen sikkerhetsvurdering: Løsningen håndterer sensitive data, betaling, tilgangsstyring eller handlinger med stor konsekvens.
• Bygg på nytt fra dokumenterte krav: Ingen kan forklare koden, endringer bryter urelaterte funksjoner, eller grunnleggende valg står i veien for sikker drift.
• Gå tilbake til validering: Teamet har ennå ikke bekreftet at løsningen løser et reelt brukerbehov.

En omskriving betyr ikke at prototypen mislyktes. Prototypens verdi kan være at den avklarte behovet og gjorde kravene konkrete. Det avgjørende er å unngå å gjøre midlertidig kode permanent av vane.

Sjekkliste før produksjon

Produksjonssettingen bør stoppes hvis teamet ikke kan krysse av de kontrollene som er kritiske for løsningen:

• Vi kan forklare arkitekturen og de viktigste dataflytene.
• Vi har skilt mellom validerte behov, fungerende funksjoner og dokumenterte driftskrav.
• Kritisk kode er gjennomgått av et menneske og kan vedlikeholdes av teamet.
• Tilgang håndheves på serveren og følger minste nødvendige tilgang.
• Input, feiltilfeller og avbrutte avhengigheter er testet.
• Kritiske tester kan ikke svekkes ubemerket sammen med funksjonen.
• Hemmeligheter ligger utenfor kodebasen.
• Avhengigheter er gjennomgått og har en eier.
• Personopplysninger er kartlagt gjennom hele datareisen.
• Logger, målinger og varsler gjør kritiske feil synlige.
• Utrulling, sikkerhetskopi og tilbakerulling er prøvd.
• En navngitt person eller et team eier drift og vedlikehold.
• Dokumentasjonen er tilstrekkelig for en ny utvikler.

Vibbekoding kan forkorte veien til en prototype. Veien til produksjon handler derimot om å gjøre løsningen forståelig, testbar, sikker og driftbar. Det er kontrollene og eierskapet rundt koden som avgjør om den tåler reell bruk.

Har dere en KI-generert prototype som trenger en nøktern produksjonsvurdering? Start en samtale med Daia.