Vibe-koding: kan dere bygge systemet selv nå?

Vibe-koding: kan dere bygge systemet selv nå?

Det er blitt en reell samtale på en måte det ikke var for to år siden: "kan vi bare bygge dette selv?" Med AI-verktøy som Claude, Cursor eller Replit kan noen uten programmeringsbakgrunn i dag beskrive hva de vil ha, og få en fungerende nettside eller et enkelt bookingskjema opp å stå på en ettermiddag. Det kalles gjerne «vibe-koding» — du beskriver følelsen av hva du vil ha, AI-en skriver koden, og du justerer underveis ved å be om endringer i vanlig språk, ikke ved å skrive kode selv.

Det er ikke hype uten grunnlag. Det fungerer faktisk, og det fungerer overraskende godt for visse ting. Spørsmålet vi oftere får nå, som vi vil svare ærlig på, er: betyr dette at et konferansehotell eller en event-venue kan bygge sitt eget PMS eller eventsystem selv, og droppe leverandøren helt?

Kort svar: for noen ting, ja, absolutt, og dere bør gjøre det. For det systemet som håndterer gjestedata, betaling og drift, er svaret nesten alltid nei — og grunnen har lite å gjøre med om koden er god nok den første dagen.

Der vibe-koding faktisk er genialt

La oss være tydelige på dette, for det er lett å bli enten helt avfeiende eller helt ukritisk begeistret, og ingen av delene er ærlige. Vibe-koding er et reelt, nyttig verktøy for en bestemt kategori oppgaver:

Interne verktøy uten sensitive data — en enkel oversikt over hvem som har ferie når, en kalkulator for å beregne cateringmengder ut fra gjestetall, et dashbord som viser dagens ankomster hentet fra et regneark. Engangsbehov — noe dere trenger denne måneden for et spesifikt arrangement, og som ikke trenger å leve videre etterpå. Prototyper — for å teste en idé raskt før dere eventuelt ber en leverandør bygge noe skikkelig. Automatisering av en irriterende manuell oppgave — for eksempel et lite skript som henter tall fra ett system og legger dem inn i et annet, uten at det rører gjestedata direkte.

Fellestrekket her er at konsekvensen av at noe går galt, er liten og lokal. Hvis kalkulatoren regner feil en dag, oppdager dere det raskt og retter det selv. Ingen gjest blir skadelidende, ingen personopplysning lekker, og ingen betaling blir feil belastet.

Der det blir noe helt annet: gjestedata, betaling og drift

Et PMS eller eventsystem er ikke i denne kategorien, og det er verdt å være helt konkret om hvorfor, i stedet for bare å si «det er mer komplisert» og la det stå der.

Sikkerhet er ikke noe du bygger inn til slutt. Et system som håndterer gjestenavn, kontaktinformasjon, betalingsreferanser og eventuelt helseopplysninger i et kommentarfelt, må tenke gjennom tilgangsstyring, kryptering og logging fra første linje kode — ikke som noe man legger til når man "har tid". Et AI-verktøy som genererer kode raskt, genererer som regel også koden som er raskest å skrive, ikke automatisk den som er sikrest. Det finnes ingen innebygd garanti for at et vibe-kodet system faktisk er beskyttet mot de vanligste angrepsformene, med mindre noen som faktisk forstår sikkerhet, går gjennom det linje for linje.

Regelverket forsvinner ikke fordi dere bygde det selv. Norsk MVA-håndtering på en dagpakke, EHF-fakturering til offentlige kunder, GDPR-krav til hvordan gjesteopplysninger lagres og slettes — alt dette gjelder uansett hvem som skrev koden. Forskjellen er at en etablert leverandør har løst dette én gang og vedlikeholder det kontinuerlig for alle sine kunder samtidig. Bygger dere det selv, må dere også holde det oppdatert selv, hver eneste gang regelverket endrer seg.

Vedlikehold er ikke noe som tar slutt når systemet «er ferdig». Dette er trolig det viktigste punktet av alle, og det som oftest glemmes i entusiasmen rundt å bygge noe raskt. Å bygge en fungerende versjon er den enkle delen — kanskje 20 prosent av den reelle arbeidsmengden over tid. De resterende 80 prosentene er det som skjer etterpå: biblioteker og avhengigheter som må oppdateres når sikkerhetshull oppdages i dem, integrasjoner som slutter å virke når en ekstern tjeneste endrer sitt eget API uten varsel, sikkerhetskopier som må testes jevnlig — ikke bare tas — og noen som faktisk må være tilgjengelig når noe stopper å virke en fredag klokka fire.

Hvem eier problemet når personen som bygde det, slutter eller blir opptatt med noe annet? Dette er kanskje den mest undervurderte risikoen. Et vibe-kodet system har som regel én person som forstår hvordan det henger sammen — gjerne den som bygde det, ofte uten formell dokumentasjon utover det AI-verktøyet genererte underveis. Den dagen vedkommende slutter, blir sykemeldt, eller rett og slett får andre prioriteringer, sitter dere med et system ingen andre egentlig forstår, og ingen leverandør å ringe.

Et enkelt tankeeksperiment som avslører hvor grensen går

Spør dere selv: hvis dette systemet var nede i seks timer på en lørdag med fullt belegg og et bryllup i lokalene, hva ville det kostet dere — i penger, i omdømme, i tapt tillit fra gjester? Og: hvis en gjests betalingsinformasjon eller helseopplysninger lekket ut av dette systemet, hvem ville dere ringe, og hvem ville faktisk stå ansvarlig?

Hvis svaret på det første spørsmålet er «ikke så mye», og svaret på det andre er «det er ikke relevant, det rører ikke den typen data», er dere trolig i den trygge sonen for vibe-koding. Hvis svaret er «det ville vært katastrofalt» eller «det vet vi faktisk ikke», er det et tydelig signal om at dette hører hjemme hos en leverandør med et reelt ansvar — en avtale, en SLA, noen som faktisk kan stilles til ansvar, ikke bare en AI-chat som hjalp dere en ettermiddag.

Det er ikke enten-eller

Det mest fornuftige er sannsynligvis ikke å velge mellom «bygg alt selv» og «kjøp alt fra en leverandør». Bruk vibe-koding fritt til de interne, lavrisiko-verktøyene der det faktisk gir dere noe raskt og billig ingen leverandør ville bygget for dere uansett. Behold en etablert leverandør med reelt ansvar for det som rører gjestedata, betaling og drift av selve virksomheten. Og vær ærlige med dere selv om hvilken kategori et gitt behov faktisk havner i, før dere begynner å bygge — ikke etter at det allerede lever i produksjon og har blitt vanskeligere å si nei til.