Vibekoding blir ofte sammenlignet med å bygge et hus med flott fasade og dårlig fundament. Det kan se imponerende ut, og alt virker kanskje ved første øyekast, men bak overflaten ligger kode ingen har kontroll på, sikkerhetshull og løsninger som blir vanskelige å vedlikeholde.

Det er ikke en urimelig kritikk. Spørsmålet er om problemet egentlig er at AI skriver koden, eller at vi bruker AI på en måte der ingen passer på fundamentet.

Vibekoding var aldri ment som ingeniørkunst

Da Andrej Karpathy introduserte begrepet «vibe coding» i 2025, beskrev han en ganske løs arbeidsform. Han lot språkmodellen skrive koden, brukte «Accept All», leste i liten grad endringene og sendte feilmeldinger tilbake til modellen når noe ikke fungerte. Han skrev også at dette fungerte greit til «throwaway weekend projects».

Martin Fowler bruker nettopp dette skillet når han beskriver vibekoding: Hvis AI skriver all koden, men du fortsatt leser den, vurderer strukturen og tar ansvar for resultatet, er det ikke nødvendigvis vibekoding i Karpathys opprinnelige betydning. Martin Fowler: Vibe Coding

Det er en viktig forskjell, for mye av det som i dag omtales som vibekoding er egentlig bare AI-assistert softwareutvikling.

Sikkerhetskritikken er likevel reell

Det finnes gode grunner til ikke å stole blindt på koden AI produserer. Veracode har testet språkmodeller på 80 kontrollerte kodeoppgaver i Java, JavaScript, C# og Python. Oppgavene var konstruert slik at modellen kunne velge en sikker eller usikker implementasjon innen fire kjente sårbarhetsklasser.

I deres sommermåling for 2026 var gjennomsnittlig sikkerhetsrate rundt 56 prosent. Modellene fikk imidlertid svært begrenset kontekst og ingen spesifikk beskjed om å tenke på sikkerhet, og Veracode presiserer selv at dette var tester av rå modeller, ikke komplette kodeagenter. Resultatet bør derfor ikke leses som at «44 prosent av all AI-kode er usikker». Det viser noe mer avgrenset, men fortsatt viktig: Funksjonell kode blir ikke automatisk sikker kode. Veracode: GenAI Code Security Report 2026

Det fikk oss til å tenke på selve arbeidsformen.

Hvis vi ber AI om å lage en kundeportal, vil den gjerne begynne å lage en kundeportal. Men hvem stiller spørsmålene om tilgangsstyring, datamodell, migrering, feilscenarier og hva som skjer hvis produktet vokser?

Tradisjonelt er svaret flere mennesker med forskjellige roller.

Men må alle disse rollene nødvendigvis være mennesker?

Hva om AI får flere roller?

Vi har begynt å leke med en hypotese der AI ikke bare får være utvikleren. Før noe større bygges kan den for eksempel opptre som systemarkitekt og foreslå hvordan løsningen bør settes sammen. Deretter skifter den rolle og blir en skeptisk CTO som får i oppgave å finne svakheter i sitt eget forslag.

En sikkerhetsrolle kan se etter angrepsflater. En QA-rolle kan forsøke å få funksjonen til å feile. En kodegransker kan lete etter unødvendig kompleksitet, mens en «fremtidig vedlikeholder» vurderer om noen andre vil forstå løsningen om to år.

Det høres mer omstendelig ut enn vibekoding, men disse vurderingene kan skje svært raskt. Poenget er å få AI til å se på det den har laget fra flere vinkler før vi aksepterer resultatet.

Håndtegnet illustrasjon av fire personer med tydelig ulike roller rundt et bord, i aktiv diskusjon
Fire roller rundt samme bord: arkitekt, utvikler, forretning og kvalitet. I praksis er det samme løsningen som granskes fra fire stoler.

Det betyr heller ikke at fem AI-roller automatisk gjør en løsning trygg. OWASP anbefaler fortsatt at AI-generert kode har en menneskelig eier og at endringene blir gjennomgått av mennesker. I deres nyere retningslinjer for AI-assistert utvikling er poenget ganske tydelig: AI-en som skriver koden og en AI som kontrollerer den er ikke det samme som uavhengig menneskelig kontroll. OWASP: Secure Coding with AI

Vår hypotese er derfor ikke at mennesker kan fjernes fra prosessen. Den er at AI kanskje kan gjøre langt mer av arbeidet som normalt må gjøres før den menneskelige vurderingen.

Når AI må revurdere seg selv

Vi synes også det er interessant å gjøre denne kontrollen til en liten loop. AI bygger noe, andre roller finner svakheter, løsningen revideres og vurderes på nytt.

Men loopen trenger en stoppregel. Hvis AI fortsatt finner alvorlige problemer etter to eller tre runder, er det ikke sikkert vi trenger enda en patch. Kanskje arkitekturen eller selve antagelsen vi startet med er feil.

Det gir en ganske enkel arbeidsregel:

Hvis rettelsene ikke gjør løsningen tydelig bedre, gå tilbake til fundamentet.

Håndtegnet sirkel av piler med hammer, forstørrelsesglass og blyant som symboliserer bygg, gransk og revider
Bygg, gransk, revider. Og ha en stoppregel som sender deg tilbake til fundamentet når lappene ikke bærer.

Vi ser også for oss at grundigheten må variere. Å endre tekst eller farge på en knapp trenger ikke et virtuelt sikkerhetsråd. Innlogging, betaling, personopplysninger og databaseendringer bør derimot få en helt annen behandling.

Kanskje fundamentet er prosessen

Det er lett å lage dårlig software med AI. Karpathys opprinnelige versjon av vibekoding er nærmest en oppskrift på å miste oversikten hvis løsningen skal leve lenge.

Men derfra følger det ikke nødvendigvis at software som hovedsakelig er skrevet av AI må ha dårlig fundament.

Det kan hende vi legger for stor vekt på hvem som skriver koden, og for liten vekt på hvordan arbeidet rundt koden organiseres.

Hvis AI først må forstå problemet, foreslå en arkitektur, argumentere mot sitt eget forslag, bygge, teste, forsøke å finne feil og revurdere løsningen når den ikke holder, begynner arbeidsformen å ligne mindre på vibekoding og mer på softwareutvikling der en stadig større del av selve produksjonen er automatisert.

Om dette kan gi like robuste systemer som et godt utviklingsteam, vet vi ikke. Det er nettopp det som gjør hypotesen interessant.

Kanskje fremtidens viktigste ferdighet ikke er å kunne skrive all koden selv, men å sørge for at de riktige spørsmålene blir stilt før vi godtar den.