Hva er vibe coding? Forklart på enkelt språk
Vibe coding er å bygge programvare ved å beskrive for en KI, med vanlig språk, hva du vil ha, kjøre det den lager, og styre etter resultatene i stedet for etter koden. Du vurderer appen — virker knappen, ser siden riktig ut — og ber om endringer til den gjør det du trenger. Begrepet ble laget av KI-forskeren Andrej Karpathy i et innlegg på X i februar 2025, der han beskrev at han ga etter for «vibene» og glemte at koden finnes.
Hvor begrepet kommer fra
Karpathy, medgründer av OpenAI og tidligere leder for KI hos Tesla, brukte uttrykket for å beskrive hvordan han bygde små prosjekter i helgene: han snakket med et KI-kodeverktøy, aksepterte endringene uten å lese forskjellene, og limte inn feilmeldinger igjen til ting fungerte. Han var tydelig på at dette passet for engangsprosjekter.
Uttrykket slo an fordi det ga navn til noe mange allerede gjorde. I løpet av få måneder ble det brukt om alt fra hobbyprosjekter til prototyper for oppstartsbedrifter, og Collins English Dictionary valgte «vibe coding» som årets ord for 2025. I dag brukes det løst om all bygging der KI-en skriver koden og et menneske styrer den med vanlig språk.
Hvorfor det betyr noe hvis du bygger med KI
For folk som ikke skriver kode, er vibe coding hele grunnen til at KI-appbyggere er nyttige. En grunnlegger kan teste en idé på en ettermiddag; en småbedriftseier kan bygge skjemaet for bestillinger eller lagersporeren de aldri kunne forsvare å betale et byrå for; en designer kan gjøre en skisse om til noe man kan klikke seg gjennom.
Men definisjonen inneholder sin egen advarsel. «Glem at koden i det hele tatt finnes» er greit når koden bare må fungere for deg, i dag. Det er mindre greit når appen lagrer kunders data, tar betalinger eller må fungere i årevis. Å vite hvor denne grensen går, er det nyttigste du kan lære om vibe coding.
En hverdagslig sammenligning
Tenk på å pusse opp kjøkkenet ved å fortelle en byggmester hva du vil ha, i stedet for å tegne planene selv. Du sier «en lang benkeplate under vinduet, åpne hyller, kjøleskapet nær døren», og så går du inn hver kveld, ser på det som er gjort og sier hva som skal endres.
Det fungerer godt for oppsettet og utseendet. Du kan bedømme det bare ved å stå i rommet. Det fungerer dårligere for det som er bak veggene: ledningene, rørleggerarbeidet, om gassrøret holder mål. Du kan ikke se det, og et problem der viser seg kanskje ikke før noe går galt. En omsorgsfull eier får likevel en inspeksjon.
Vibe coding er det samme. Skjermene er det synlige rommet. Sikkerhet, datahåndtering og hvordan koden er organisert, er ledningene.
Slik ser vibe coding ut i praksis
Anta at du vil ha et enkelt verktøy for å følge med på hvilke kunder som har betalt fakturaene sine.
| Steg | Hva du gjør | Hva KI-en gjør |
|---|---|---|
| 1. Beskriv | «En side som lister opp kundene mine med fakturabeløp, forfallsdato og status betalt/ubetalt. Jeg kan legge til en kunde og merke en faktura som betalt.» | Skriver sidene, skjemaet og logikken for å lagre oppføringer |
| 2. Prøv | Legg til en kunde, merk den som betalt, last siden på nytt | Kjører appen i en forhåndsvisning |
| 3. Reager | «Etter en oppdatering er kundene borte» | Forklarer at oppføringene bare lå i nettleserens minne, og legger til en database |
| 4. Finjuster | «Sorter forfalte fakturaer øverst og gjør dem røde» | Endrer listen |
| 5. Sjekk | Åpne den på telefonen; prøv et tomt skjema | Retter det du rapporterer |
Du åpnet aldri en kodefil. Men legg merke til steg 3: appen så ferdig ut før den faktisk lagret noe. Vibe coding belønner folk som tester som en bruker og beskriver nøyaktig det de ser.
Fordeler
- Fart. En fungerende første versjon på minutter eller timer i stedet for uker.
- Lav kostnad for å prøve ideer. Du kan bygge tre versjoner av noe og beholde den som virker.
- Direkte kontroll. Personen som forstår problemet, er den som former produktet, uten at noe går tapt i oversettelsen til en utvikler.
- Lære ved å gjøre. Mange lærer hvordan apper henger sammen — frontend og backend, databaser, API-er — bare ved å se hva KI-en bygger og spørre hvorfor.
De reelle risikoene
Dette er ikke grunner til å la være å drive med vibe coding. Det er ting vibene ikke sjekker for deg.
Sikkerhetshull du ikke ser
En app kan se perfekt ut og likevel la enhver innlogget bruker lese alle andre brukeres poster, eller eksponere en hemmelig nøkkel i kode som kjører i besøkendes nettleser. Ingen av delene viser seg når du klikker rundt som deg selv. Vanlige problemer er manglende tilgangskontroller på serveren, API-nøkler plassert i frontend-kode, og skjemaer som godtar hva som helst.
Kode ingen forstår
Hvis ingen har lest koden, vet ingen hvordan den er organisert. Det går fint i små størrelser. Etter hvert som appen vokser, risikerer hver endring å ødelegge noe urelatert, og KI-en kan begynne å «fikse» én feil ved å lage en annen. Apper som har blitt vibe-kodet i månedsvis uten gjennomgang, er ofte vanskeligere å endre enn apper bygget saktere.
Å ikke vite hva «ferdig» betyr
KI-en vil gjerne fortelle deg at noe er fikset. Bare testing forteller om det er det. De som hopper over testing, ender opp med funksjoner som virker i demoen og feiler med ekte data: lange navn, tomme felt, to personer som booker samme tidspunkt.
Skjulte avhengigheter og kostnader
KI-bygde apper henter ofte inn eksterne tjenester — e-postleverandører, betalingsløsninger, KI-API-er. Hver har sin egen konto, sine nøkler, grenser og regninger. Vit hva appen din er avhengig av før du lanserer.
Vanlige misforståelser
| Misforståelse | Hva som faktisk er riktig |
|---|---|
| «Vibe coding betyr at det ikke finnes kode.» | Det finnes ekte kode. Du leser bare ikke den. Derfor kan du senere eksportere den eller gi den til en utvikler. |
| «Hvis den kjører, er den riktig.» | Å kjøre og å være korrekt, sikker og vedlikeholdbar er ulike ting. |
| «Det er bare for folk uten utviklerbakgrunn.» | Mange profesjonelle utviklere bruker vibe coding på prototyper, og går så gjennom eller skriver om før de lanserer. |
| «KI-en vil si fra om problemer.» | Det gjør den ofte hvis du spør, men den gjør det ikke alltid av seg selv. Spør direkte. |
| «Du kan ikke bygge noe seriøst på denne måten.» | Mange ekte apper starter slik. Det seriøse er å legge til testing og gjennomgang før ekte brukere er avhengige av den. |
Slik driver du vibe coding ansvarlig
Noen få vaner dekker det meste av risikoen:
- Hold endringene små. Én forespørsel, én endring, så test. Store, vage forespørsler gir store, vage resultater.
- Bruk sjekkpunkter. Sørg for at du kan gå tilbake til siste fungerende versjon før du prøver noe risikabelt.
- Be KI-en forklare. «Hva gjør denne endringen? Hva kan gå i stykker?» koster lite og fanger mye.
- Test som en fremmed. Logg inn som en andre bruker og prøv å se den første brukerens data.
- Hold hemmeligheter ute av kode og chat. API-nøkler hører hjemme i miljøvariabler eller prosjekthemmeligheter.
- Gjennomgå før ekte brukere. For alt med betalinger eller personopplysninger, gå gjennom en sikkerhetssjekkliste eller få en utvikler til å se på det.
Hva du skal be KI-byggeren om
Nyttige prompter som gjør vibes til sjekker:
- «Før du bygger dette, fortell meg planen din og hvilke data den skal lagre.»
- «List opp alle steder denne appen lagrer eller sender brukerdata.»
- «Kan en innlogget bruker se eller endre en annen brukers poster? Sjekk serverkoden, ikke bare sidene.»
- «Er noen API-nøkler synlige i kode som kjører i nettleseren?»
- «Hva skjer hvis to personer sender dette skjemaet på samme øyeblikk?»
- «Oppsummer hva som endret seg i de tre siste redigeringene.»
For flere mønstre, se hvordan skrive prompter til KI-appbyggere, og når ting går galt, hvordan feilsøke en KI-bygget app.
Vibe coding med Mythex
Mythex er en KI-appbygger laget for denne måten å jobbe på: du beskriver appen i chatten, agenten skriver og kjører koden i en live forhåndsvisning, og du publiserer den til en offentlig URL. Noen funksjoner finnes spesielt for risikoene over. Plan-modus lar agenten legge opp en tilnærming før den rører noen filer, Ask-modus svarer på spørsmål uten å redigere noe, og hver vellykkede tur lagrer et sjekkpunkt du kan gå tilbake til. På Pro kan du åpne den fulle kodeeditoren, eksportere prosjektet eller synkronisere det til GitHub når du vil at en utvikler skal gjennomgå det. Chat-dokumentasjonen forklarer modusene og sjekkpunktene, og malene gir deg et utgangspunkt hvis en tom side virker for mye.
Spørsmål
Hvem laget begrepet vibe coding?
Andrej Karpathy, forsker innen KI og medgründer av OpenAI, laget begrepet i et innlegg på X i februar 2025. Han beskrev at han ga etter for «vibene» og glemte at koden i det hele tatt finnes, og uttrykket spredte seg raskt derfra.
Er vibe coding det samme som no-code?
Ikke helt. No-code-verktøy lar deg bygge i en visuell editor som skjuler koden. Med vibe coding skriver en KI ekte kode som ligger i filer; du velger bare å ikke lese den, og styrer ved å beskrive hva du vil ha og sjekke resultatet.
Er vibe coding trygt for en ekte app?
Det kan det være, hvis du legger til kontroller som vibene hopper over: test at brukere ikke kan se hverandres data, oppbevar API-nøkler som hemmeligheter og ikke i koden, og gjennomgå alt som håndterer penger eller personopplysninger. For engangsprototyper er risikoen lav; for apper med ekte brukere er den ikke lav.
Må jeg lære å kode for å drive med vibe coding?
Nei. Men kjenner du de grunnleggende ideene — hva en database, et API og autentisering er — blir forespørslene dine tydeligere, og du oppdager lettere når noe er galt. Du trenger ikke skrive kode for å forstå disse begrepene.