Forestill deg å bygge en hel app uten å skrive én eneste linje med kode. Du skriver bare hva du vil ha på norsk eller engelsk, og maskinen leverer resten. Dette er ikke science fiction lenger; det er virkeligheten for mange gründere i dag. I mars 2025 kom et sjokkerende tall fra Y Combinator, verdens mest anerkjente startup-akselerator: hele 25 % av startups i vinterpartiet hadde kodbaser som var 95 % generert av kunstig intelligens. Noen kilder oppgir til og med at tallet kan være så høyt som 90 %.
Dette fenomenet kalles vibe coding. Det har endret måten vi tenker på teknologi, men det kommer med store advarsler. Er dette fremtiden, eller bygger vi sandborg i tidevannet? La oss se nærmere på hva vibe coding egentlig er, hvorfor det tar av, og hvilke skjulte farer det innebærer for sikkerhet og kvalitet.
Hva er egentlig vibe coding?
Terminologien ble lansert av Andrej Karpathy, tidligere AI-sjef hos Tesla og medgrunnlegger av OpenAI, i februar 2025. Han definerte det som en chatbot-basert tilnærming til utvikling der du beskriver prosjekter til store språkmodeller (LLM), som så genererer kildekoden basert på naturlige språkprompter.
Karpathy beskrev metoden som å "fullstendig gi seg hen til stemningen, omfavne eksponentielle fremskritt og glemme at koden overhodet eksisterer". Ideén er at du fokuserer på resultatet, ikke implementasjonen. Du gir mål, eksempler og tilbakemeldinger via vanlig tekst, og modellen justerer seg selv.
Men her dukker det opp en viktig distinksjon. Programmereren Simon Willison argumenterte for at hvis du leser, tester og fullt ut forstår den genererte koden, bruker du bare LLM-en som en tastaturassistent. Egentlig vibe coding handler om å akseptere koden uten å forstå innvollene. Det er denne "blind tilliten" til maskinen som skiller konseptet fra tradisjonell assistert utvikling.
Rask adopsjon i startup-verdenen
Adopsjonen har gått med lynets hastighet. Fra Karpathys konseptualisering i februar til Y Combinators statistikk i mars, var trenden allerede uimotståelig blant nyetablerte selskaper. Under en paneldebatt kalt "Vibe Coding Is the Future" diskuterte ledelsen i Y Combinator - inkludert CEO Garry Tan, managing partner Harj Taggar og general partner Diana Hu - implikasjonene av denne natur-språkdrevne kodestyringen.
Hvorfor tar det så raskt av? Svaret er hastighet. For en gründer som trenger å teste en idé på helgen, er det umulig å slå en metode som reduserer tiden fra tanke til funksjonell prototype fra uker til timer. Men hastighet er ofte fienden til nøyaktighet. Når vi ser på kvaliteten i denne eksplosive veksten, begynner bildet å bli mer nyansert.
Kvalitet og sikkerhet: Den skjulte prisen
Det lyder for godt til å være sant, og det er kanskje det. En analyse fra desember 2025 utført av CodeRabbit undersøkte 470 åpne GitHub-pull requests. Resultatene var alarmerende for dem som tror blindt på AI:
- Kode co-authored av generativ AI inneholdt omtrent 1,7 ganger flere "store" problemer enn menneskeskrevet kode.
- Logikkfeil, som feil avhengigheter og dårlig kontrollflyt, var 75 % hyppigere i AI-generert kode.
- Sikkerhetssårbarheter opptrådte 2,74 ganger oftere i kode laget av AI.
Analysen dokumenterte også høy grad av lesbarhetsproblemer, inkludert formatteringsfeil og inkonsistente navngivninger. Disse funnene motsier påstandene om effektivitetsgevinster ved å vise til betydelige kvalitetskompromisser. Hvis 25 % av YC-startups har 95 % AI-kode, betyr det at en stor del av neste generasjons teknologi er bygd på grunnlag av kode som er statistisk sett mer utsatt for feil og sikkerhetshull.
Skaleringsutfordringen: Hva skjer når brukerne kommer?
Y Combinators egen ledelse har varslet faretruende tegn. General partner Diana Hu understreket at man trenger "smak" og nok trening for å vite når en LLM spytter ut dårlig stoff. "For å gjøre god 'vibe coding', må du fortsatt ha smak og kunnskap til å dømme godt fra dårlig," sa hun.
CEO Garry Tan tok opp spørsmålet om skalerbarhet og feilsøking. Han stilte et kritisk scenario: "La oss si at en startup med 95 % AI-generert kode går ut på markedet, og et år eller to senere har de 100 millioner brukere på produktet. Hopper det sammen eller ikke? De første versjonene av resonansmodeller er ikke gode på feilsøking. Så du må gå dypt inn i hva som skjer med produktet."
Tan poengterte videre at gründere trenger klassisk programmeringstrening for å opprettholde produkter på lang sikt. Grunnen er enkel: Når ting går galt i produksjon, hjelper det lite å be chatboten om å fikse det hvis du ikke forstår *hvorfor* det gikk galt. Feilsøking krever en mental modell av systemet, noe vibe coding ofte ødelegger.
Begrensningene hos store språkmodeller (LLM)
Utfordringene starter når prosjektet vokser ut av prototypen-fasen. Erfarne utviklere på Hacker News rapporterer om vesentlige problemer når kodbasen når størrelsen nødvendig for å løse reelle forretningsproblemer. Kvaliteten på output varierer vilt, kompleksiteten i promptene øker dramatisk, og koden krever omfattende redigering for å integreres uten feil.
En sentral hypotese er at etter hvert som kompleksiteten øker, vil spesifikiteten og kompleksiteten i input-prompts kreve mer fra ingeniøren enn bare å skrive selve koden. Kode er per definisjon mer spesifikk enn naturlig språk. Språkmodeller lider av "hallusinasjoner" - der de genererer troverdige, men feilaktige opplysninger. Jo større kodbasen eller problemrommet blir, jo mindre nøyaktige blir LLM-ene.
Noe av løsningen som utviklere finner på, er å bruke strenge TypeScript-typsystemer, omfattende testdekning og regelmessige sykluser for forenkling av kode. De ber også modellene om "ren, enkel og elegant kode" for å motvirke tendensen til overkomplisert output.
Homogenisering av programvareutviklingen
Det finnes også bredere, systemiske bekymringer. Maya Posch, som forklarer forskningsfunn innenfor open source, pekte på en mekanisme for "homogenisering av programvareutvikling". Språkmodeller graviterer mot store, etablerte biblioteker som dukker opp hyppig i treningsdatasettene.
Dette fjerner den organiske seleksjonsprosessen for verktøy og biblioteker. Det blir vanskeligere for nye open-source-verktøy å få oppmerksomhet fordi AI-en nesten alltid velger det kjente alternativet. Dessuten mangler språkmodeller evnen til å sende nyttige feilrapporter eller ha bevissthet om potensielle problemer for open-source-vedlikeholdere, noe som reduserer helsen i hele økosystemet.
Cognitiv vitenskapsmann Gary Marcus kritiserte også påstandene om originalitet. Da Kevin Roose demonstrerte byggingen av LunchBox Buddy-appen med vibe coding, bemerket Marcus at algoritmen sannsynligvis var trent på eksisterende kode for lignende oppgaver. Suksessen skyldtes reproduksjon av kode, ikke løsning av virkelig nye problemer. Vibe coding excellerer ved å remiksere eksisterende mønstre, ikke ved innovasjon.
| Egenskap | Tradisjonell utvikling | Vibe Coding (AI-assistert) |
|---|---|---|
| Læringskurve | Høy (må lære syntaks og logikk) | Lav (naturlig språk er nok) |
| Hastighet (prototype) | d>Middels til langsomVeldig rask | |
| Sikkerhet | Kontrollert av utvikler | 2,74x flere sårbarheter (CodeRabbit) |
| Skalerbarhet | Stabil ved korrekt arkitektur | Usikker; feilsøking er vanskelig |
| Originalitet | Høy (ny løsning på problem) | Lav (remiksing av treningsdata) |
Hva bør du gjøre nå?
Hvis du er en gründer eller utvikler, betyr ikke dette at du skal ignorere AI. Det betyr at du må bruke det klokt. Bruk vibe coding for raske prototyper, intern verktøy og "throwaway weekend projects" som Karpathy foreslo. Men for kjerneproduktet ditt, spesielt det som håndterer brukerdatal eller sikkerhet, må du beholde menneskelig oversikt.
Investér i forståelse. Selv om AI skriver koden, må du forstå strukturen. Implementer strenge testsuites tidlig. Ikke la deg lure av at koden "ser bra ut". Sjekk avhengighetene. Les gjennom logikken. Og husk: AI er en fantastisk assistent, men ennå ikke en erstatter for ekspertise når det gjelder å bygge robuste, sikre systemer som skal bære millioner av brukere.
Hvem oppfant begrepet vibe coding?
Begrepet ble introdusert av Andrej Karpathy i februar 2025. Han beskrev det som en metode der man lar store språkmodeller generere kode basert på naturlige språkprompter, uten å fokusere tungt på den tekniske implementasjonen underveis.
Er vibe coding trygt for store applikasjoner?
Foreløpig er svaret nei, ifølge flere eksperter. En analyse fra CodeRabbit viste at AI-generert kode har 2,74 ganger flere sikkerhetssårbarheter enn menneskeskrevet kode. Uten dyp forståelse av koden blir feilsøking og vedlikehold svært utfordrende når applikasjonen skaleres.
Hvor mye av koden i Y Combinator-startups er generert av AI?
I mars 2025 rapporterte Y Combinator at 25 % av startups i vinterpartiet (W25) hadde kodbaser som var 95 % AI-generert. Noen alternative kilder nevnte opptil 90 %, noe som indikerer en massiv og rask adopsjon av teknikken.
Hva er forskjellen mellom vibe coding og vanlig AI-assistert coding?
Forskjellen ligger i forståelsen. Hvis du leser og tester all AI-generert kode grundig, bruker du AI som en assistent. Vibe coding innebærer å akseptere koden uten å fullt ut forstå innvollene, og stole på iterativ tilbakemelding via prompter for å rette opp feil.
Kan AI erstatte behovet for å lære programmering?
Ikke helt. Selvom Karpathy hevdet at engelsk er det "heteste programmeringsspråket", understreker Y Combinators Garry Tan at gründere fortsatt trenger klassisk programmeringstrening for å kunne feilsøke og vedlikeholde komplekse systemer på lang sikt.
Hva mener Gary Marcus om vibe coding?
Gary Marcus er skeptisk til påstandene om originalitet. Han mener at AI-generert kode ofte bare er en remiksing av eksisterende kode fra treningsdataene, snarere enn løsning av virkelig nye problemer. Det gjør det mindre egnet for innovasjon, men godt for standard oppgaver.