Vi må slutte å kalle alt Vibe Coding

Jeg gikk tilbake til koding etter en lang pause, og Lovable var stedet jeg tok det opp igjen. Appene så flotte ut, fungerte ved første øyekast, og ble satt sammen på noen timer. I begynnelsen føltes det bemerkelsesverdig. Men det var ikke nok så snart jeg ville vite hva koden gjorde – og hvorfor. Da begynte tilnærmingen min å endre seg.

Forskjellen handler ikke om verktøyet, eller hvor mye av koden AI skriver for deg. Det handler om kontrakten du godtar med ditt resultat: om du kan forklare hva du nettopp slapp løs i verden, eller ikke.

Vibe coding, i sin opprinnelige betydning, betyr å godta AI-generert programvare uten å undersøke eller forstå hva som ligger under. AI-assistert utvikling er annerledes. Modellen kan fortsatt skrive mesteparten av koden, men personen som bygger systemet er fortsatt ansvarlig for å forstå dens oppførsel, teste antakelsene og avgjøre om den er klar for utrulling.

For et engangs‑eksperiment som aldri forlater din egen maskin, kan forskjellen ha få konsekvenser. Når programvaren er distribuert, brukes av andre eller kobles til reelle data, betyr det enormt mye.

Hvordan «Vibe Coding» mistet sin betydning

Begrepet «vibe coding» ble oppfunnet i februar 2025 av Andrej Karpathy, medgründer av OpenAI. Eksemplet hans var bevisst uformelt: et “throwaway weekend project” bygget ved automatisk å klikke “Accept All,” ignorere diffene og la koden vokse utover hans forståelse.

Uker senere oppdaget utvikleren og verktøyskaperen Simon Willison at begrepet ble brukt på en helt annen måte: som en erstatning for all AI-assistert programmering, noe han mente fortynner begrepet og gir et falskt inntrykk av hva ansvarlig AI-assistert utvikling kan oppnå.

Det som er interessant er at Karpathy til slutt var enig. Et år senere introduserte han et annet begrep for mer disiplinert arbeid med kodeagenter. Han beskrev «agentic engineering» som en arbeidsflyt der utviklere styrer og overvåker agenter i stedet for bare å godta det de produserer. Differansen er viktig: profesjonell AI-assistert utvikling krever planlegging, gransking og ansvarlighet på måter som uformell vibe coding ikke gjør.

Linjen er ansvar

Willisons regel er enkel, og den fungerer som en test for alle: ikke sjekk inn kode du ikke kan forklare til noen andre. Det betyr ikke at du må lese hver eneste linje: når agenter genererer hundrevis av linjer på én gang, gjør ikke engang erfarne utviklere det lenger. Det betyr å forstå den grunnleggende logikken og kunne begrunne hvorfor koden gjør akkurat det den gjør. Hvis du kan, spiller det ingen rolle om en modell skrev den eller du gjorde det: det er ikke vibe coding, det er å bruke et verktøy til å bygge programvare.

Forskning publisert i desember 2025 støtter den forskjellen. Basert på feltobservasjoner og en kvalitativ undersøkelse av profesjonelle utviklere, fant forskerne at erfarne praktikere beholdt kontrollen over programvaredesign og implementering i stedet for å overlate hele prosessen til AI. De behandlet agenter som samarbeidspartnere, planla arbeidet nøye og forble involvert i tilsyn.

Så, erfaring alene forklarer det ikke. Det handler om hvorvidt du er villig til å ta ansvar for det AI har generert. Det er en beslutning hver utvikler må ta på nytt for hvert prosjekt.

Hva skjer når kontrollen mangler

Konsekvensene av å slippe programvare uten å forstå eller verifisere sikkerheten er ikke abstrakte. Tea, en app som skal hjelpe kvinner å holde seg trygge mens de dater, avslørte titusenvis av ID‑bilder og mer enn en million private meldinger i to sikkerhets‑hendelser. Feilene inkluderte en usikret lagringsbøtte og en separat database som var tilgjengelig uten autentisering.

Det samme underliggende problemet – programvare som ser ut til å fungere mens autorisasjonslogikken var farlig feil – dukket opp i en applikasjon bygget på Lovable‑plattformen: sikkerhetsforskning fant at autorisasjonslogikken var omvendt, som låste ute påloggede brukere mens uautentiserte angripere fikk fri tilgang, og påvirket mer enn 18 000 brukere, inkludert studenter.

Dette er ikke isolerte tilfeller som bare skjer i «dårlige» prosjekter. Ifølge Googles DORA‑rapport fra 2025 bruker 90 % av utviklerne nå AI på jobben, mens omtrent en tredjedel rapporterer liten eller ingen tillit til det AI genererer.

AI‑bruk er nå utbredt, selv om tilliten fortsatt er begrenset. Derfor er grundig gjennomgang spesielt viktig når generert kode håndterer autentisering, tillatelser eller sensitiv data.

Kontroll er bygget i lag, ikke på én gang

I mitt tilfelle begynte jeg ikke med en formell sikkerhetsrevisjon. Jeg nektet simpelthen å gå videre når jeg ikke kunne forklare hvorfor noe oppførte seg som det gjorde – en naturlig instinkt jeg tar med meg som analytiker. Jeg bryr meg mindre om syntaksen enn om resultatet samsvarer med det vi opprinnelig trengte. Når det ikke gjør det, fortsetter jeg å grave.

Arbeidsflyten min ble mer strukturert etter hvert som prosjektene ble mer alvorlige. I stedet for kun å stole på promptene, begynte jeg å forberede spesifikasjoner før jeg genererte noe. Jeg dokumenterte forretningskravene, teknologistakken og integrasjonene. Deretter kom enhetstester og Playwright‑tester for de viktigste brukerreisene.

Sikkerhetssjekker ble lagt til på omtrent samme måte. Jeg gjennomgikk bibliotekene AI valgte og innførte skadelig‑programvare‑skanning for opplastede filer. Hver sjekk kom fra å spørre hva som kunne gå galt neste, i stedet for å følge en kontroll‑liste jeg hadde laget i starten.

Den vanen oppdaget et problem i ett prosjekt. AI introduserte et bibliotek som var inkompatibelt med rammeverksversjonen jeg brukte. Applikasjonen hadde ikke feilet direkte, så inkompatibiliteten kunne lett ha gått ubemerket hen. Å finne den senere ville ha gjort årsaken mye vanskeligere å identifisere.

Sammenlignet med Tea‑ og Lovable‑sakene var dette et vanlig problem. Jeg oppdaget det tidlig, fikset det og gikk videre. Det er slik gjennomgang vanligvis ser ut i praksis. For det meste hindrer det små problemer i å vokse til større.

Jeg misliker ikke kode bare fordi AI har produsert den. Jeg stoler heller ikke på den bare fordi applikasjonen kjører. Tester og gjennomgang er hvordan jeg fastslår om den oppfører seg som forventet.

Fra Vibe Coding til Agentic Engineering

Karpthys eget skifte fra «vibe coding» til «agentic engineering» er ikke bare en endring i vokabular. «Agentic engineering» gir oss et mer nyttig navn på retningen profesjonell utvikling tar. Utviklere kan skrive færre linjer selv, men det reduserer ikke ansvaret deres. Det flytter arbeidet deres mot å spesifisere hva systemet skal gjøre, styre agenter, teste deres output og avgjøre hva som er trygt å slippe.

Faren er ikke at AI genererer kode raskt. Det er at genereringen kan gå raskere enn forståelsen. Når det skjer, skjuler tilsynelatende produktivitet risikoer som ingen har grundig undersøkt.

En regel som er verdt å holde fast ved

Slutt å bruke «vibe coding» som en betegnelse for enhver form for AI-assistert utvikling – det fortynner begrepet og fjerner en viktig kontrollforskjell. Sett en enkel regel: ikke lever noe du ikke kan forklare. Og bygg kontroll inn i prosjektet etter hvert som det vokser, lag for lag, og legg til sjekker i takt med de risikoene som dukker opp.

AI kan skrive mesteparten av koden. Den kan ikke ta ansvar for å levere den. Det ansvaret ligger fortsatt hos oss.