Hvad er vibe coding? Muligheder og begrænsninger

Vibe coding er at bygge software ved at beskrive hvad du vil have i almindeligt sprog, lade en AI skrive koden og bedømme resultatet på om appen virker, uden at læse koden. Det er fremragende til prototyper og til at teste en idé på dage i stedet for måneder. Risikoen begynder når rigtige brugere, persondata eller betalinger kommer ind i billedet.

Jeg er udvikler og tjener blandt andet penge på at gøre AI-prototyper klar til drift, så læs med det forbehold. Jeg mener faktisk at vibe coding er noget af det bedste der er sket for folk med en idé og uden et udviklerbudget, så længe man ved hvor grænsen går.

Den korte version: hvornår er det nok?

Min tommelfingerregel er enkel: vibe coding er fint så længe en fejl kun koster dig selv tid. Når en fejl kan koste andre deres data, deres penge eller deres tillid til dig, skal nogen kunne forklare hvad koden gør.

Har du allerede en app med brugere, så spring videre til min guide om at gøre en AI-prototype klar til produktion. Dette indlæg handler om det der kommer før: hvad vibe coding er, og hvordan du bruger det klogt.

Hvad betyder vibe coding?

Udtrykket stammer fra AI-forskeren Andrej Karpathy. I februar 2025 beskrev han en måde at kode på hvor han gav sig hen til stemningen, accepterede alle AI'ens ændringer uden at læse dem og glemte at koden overhovedet fandtes. Ordet spredte sig hurtigt, og Collins Dictionary kårede det som årets ord i 2025.

I dag bruges ordet i to betydninger. Den brede betydning, som Collins bruger, dækker al programmering hvor en AI skriver koden ud fra beskrivelser i almindeligt sprog. Den smalle betydning, som var Karpathys pointe, er at du bygger med AI uden at gennemgå den kode den skriver.

Udvikleren Simon Willison har argumenteret for den smalle betydning. Bruger en udvikler AI til at skrive kode, men læser, tester og forstår den, er det efter hans definition AI-assisteret programmering og ikke vibe coding. Jeg bruger også den smalle betydning her, fordi det netop er det at ingen læser koden, der giver både farten og risikoen.

I praksis foregår vibe coding i værktøjer som Lovable, Bolt, v0 og Replit. Du skriver i et chatvindue og ser appen tage form ved siden af. Mange bruger også kodeeditorer som Cursor, hvor AI'en arbejder direkte i projektets filer. Hvilket værktøj der passer til din idé, har jeg sammenlignet i Lovable vs Bolt vs v0 vs Replit.

Hvad det er rigtig godt til

Vibe coding har flyttet grænsen for hvem der kan bygge noget man kan klikke på. Det er en reel fordel, og den er størst i de tidlige faser, hvor det vigtigste er at lære hurtigt.

Prototyper du kan vise frem

En klikbar prototype overbeviser bedre end en præsentation eller et dokument. Med et værktøj som Lovable kan du på en dag eller to have skærme, formularer og et helt forløb som en kunde kan prøve selv. Før krævede det typisk en designer og en udvikler i flere uger, og derfor blev mange idéer aldrig testet.

Validering før du bruger rigtige penge

Det dyreste i softwareudvikling er at bygge noget ingen vil bruge. En prototype lader dig teste idéen på potentielle kunder, før du bruger et større beløb på udvikling. Se mere på hvad folk gør end på hvad de siger. Klikker de rundt og spørger hvornår de kan få den, er det et godt tegn. Gør de ikke, har du sparet både tid og penge, og det er også et brugbart svar.

Et bedre oplæg til udvikleren

For en udvikler er en prototype ofte mere præcis end ti siders tekst. Den viser hvilke felter en formular har, hvad der sker når man trykker gem, og i hvilken rækkefølge tingene foregår. Den erstatter ikke en egentlig kravspecifikation, for den siger intet om sikkerhed, data eller hvad der skal ske når noget går galt. Men den gør specifikationen kortere og samtalen med udvikleren mere konkret.

Små værktøjer til eget brug

Et script der rydder op i en eksport, et lille dashboard over dine egne tal eller en formular til internt brug. Er du den eneste bruger, og koster en fejl kun lidt tid, er vibe coding et rigtig godt valg. Tag bare en kopi af de data værktøjet arbejder på.

Her begynder risikoen

Problemet er ikke at AI altid skriver dårlig kode. Meget af den er helt fin. Problemet er at ingen ved hvilke dele der ikke er, fordi ingen har læst dem. Det betyder ikke noget i en prototype, men det betyder alt når andre stoler på appen.

Koden virker, men den er ikke nødvendigvis sikker

Sikkerhedsfirmaet Veracode testede kode fra over 100 sprogmodeller og fandt at 45 % af kodeeksemplerne indeholdt sikkerhedshuller fra OWASP Top 10, en udbredt liste over de mest almindelige sårbarheder i webapps. Koden løste opgaven. Den var bare ikke sikker.

Et konkret eksempel: i 2025 gennemgik to sikkerhedsforskere 1.645 apps fra Lovables egen fremvisningsside og fandt at omkring 170 af dem lod uvedkommende hente data som e-mailadresser, telefonnumre og API-nøgler. Årsagen var manglende eller forkerte adgangsregler i databasen. Appene så fine ud udefra, og ejerne kunne ikke se fejlen uden at læse koden. De typiske huller har jeg samlet i oversigten over sikkerhedshuller i AI-genereret kode.

Hver rettelse ødelægger noget andet

Når appen vokser, sker der ofte et skift. De første dage føles magiske, men senere skaber hver prompt en ny fejl et andet sted. AI'en ser ikke hele appen på én gang, og ingen har tegnet den samlede struktur, så den samme logik ender i flere varianter. Bruger du mere tid på at rette end på at bygge nyt, er det et af tegnene på at du skal stoppe med at prompte.

Det der ikke ses i en demo

Betaling, fejlede betalinger, moms, brugerroller, backup, overvågning og opdateringer er usynlige når du klikker rundt i en prototype. Det er også dem der koster mest, når de mangler. AI kan godt skrive koden til en betaling, men den ved ikke hvad din bogholder skal bruge, eller hvad der skal ske når et kort bliver afvist. Jeg har gennemgået det for abonnementsprodukter i kan du bygge en SaaS med AI alene?

Farten kan snyde

Følelsen af fart er ikke det samme som fart. I et forsøg fra METR løste 16 erfarne udviklere 246 opgaver i kodebaser de kendte godt, og med AI-værktøjer tog de 19 % længere tid, selvom de selv troede at de var blevet omkring 20 % hurtigere. Forsøget handler om erfarne udviklere og ikke om prototyper, og forskerne understreger selv at resultatet ikke kan overføres til al softwareudvikling. Pointen er at mavefornemmelsen ikke er en måling. Mål på om brugerne kan bruge appen, ikke på hvor meget du nåede at prompte.

Seks trin til at teste en idé med AI

Trinene er skrevet til dig der vil teste en idé hurtigt uden at skabe problemer for dig selv senere.

1. Skriv ned hvad du vil lære

Før første prompt skal du formulere én sætning: hvem er appen til, og hvad skal de kunne? Skriv også hvad der skal til før du kalder testen en succes, fx at fem ud af ti potentielle kunder vil betale for en færdig version. Uden et mål bliver prototypen ved med at vokse, og så ender du med en halvfærdig app i stedet for et svar.

2. Byg kun det forløb der tester idéen

Spring login, indstillinger, administration og mails over, hvis det ikke er dem du tester. Én vej gennem appen, fra start til det øjeblik hvor brugeren får noget ud af den, er nok. Jo mindre der er, jo lettere er det at smide væk eller overdrage.

3. Brug opdigtede data

Læg ikke rigtige kunders oplysninger ind i en prototype. Persondata er persondata, også i en test, og GDPR gælder stadig. Opdigtede navne og tal viser idéen lige så godt og gør ingen skade hvis de slipper ud.

4. Hold nøgler og betalinger ude

Indsæt ikke hemmelige API-nøgler direkte i chatten eller i koden, og brug betalingsudbyderens testtilstand hvis du viser betaling. En nøgle der ender i den kode browseren henter, kan alle se. Skal prototypen tale med en betalt tjeneste, så sæt et lavt forbrugsloft hos udbyderen.

5. Gem koden uden for værktøjet

Forbind projektet til GitHub fra første dag. Så har du en historik, du kan rulle tilbage hvis AI'en ødelægger noget, og en udvikler kan se koden uden at få adgang til din konto. Det gør dig også mindre afhængig af ét værktøj.

6. Beslut før første rigtige bruger

Når testen er færdig, har du tre muligheder. Holdt idéen ikke, så smid prototypen væk og vær glad for at det var billigt. Er det et værktøj til dig selv, kan du bygge videre. Skal andre logge ind, betale eller gemme data, så få koden gennemgået før lanceringen og ikke efter første fejl.

Hvornår du ikke har brug for en udvikler

Jeg sælger netop den slags hjælp, så jeg vil sige det tydeligt: ofte skal du ikke hyre nogen endnu. En udvikler er spildte penge hvis

• idéen ikke er testet på nogen der kunne finde på at betale,
• appen kun bruges af dig eller et par kolleger, og en fejl kun koster tid,
• prototypen skal bruges til ét møde eller én demo og derefter kan smides væk,
• du stadig skifter retning hver uge.

At betale for at polere en prototype ingen har prøvet, er den dyreste måde at bruge AI på. Brug værktøjerne til at blive klogere, og hent hjælp når der er noget at beskytte.

Næste skridt

Står du med en prototype der virker, er spørgsmålet ikke om vibe coding var en fejl. Det var det sandsynligvis ikke. Spørgsmålet er om appen er klar til det næste den skal kunne.

Kan du ikke krydse det hele af, er det ikke en katastrofe, men så er det din opgaveliste før lanceringen. Vil du have hjælp, kan du se hvordan jeg arbejder med at få en AI-app fra prototype til produktion. Jeg starter med et betalt forprojekt til fast pris, så du ved hvad der skal laves, og du ejer koden fra første dag.

Ofte stillede spørgsmål

Skal jeg kunne programmere for at bruge vibe coding?+

Nej, du kan bygge en fungerende prototype uden at kunne skrive kode. Det hjælper dog meget at forstå nogle få begreber: forskellen på frontend og backend, hvad en database og en API-nøgle er, og hvorfor hemmeligheder ikke må ligge i browseren. Med den viden skriver du bedre prompts og opdager selv de mest åbenlyse fejl, før de bliver dyre.

Hvad koster det at komme i gang med vibe coding?+

Det er billigt at komme i gang. Lovable, Bolt, v0 og Replit har alle gratis planer, og den billigste betalte plan lå på 20-30 dollars om måneden efter værktøjernes egne prissider i oktober 2026. Regningen stiger med forbruget af credits, når appen vokser. Den store udgift kommer typisk senere, hvis prototypen skal gøres klar til rigtige brugere.

Er vibe coding det samme som no-code?+

Nej. No-code-værktøjer som Bubble lader dig bygge med visuelle byggeklodser inde i platformen, og du kan sjældent tage koden med dig. Ved vibe coding skriver AI'en rigtig kode, ofte i React, som du kan lægge i GitHub og lade en udvikler arbejde videre på. Til gengæld er det i højere grad dit eget ansvar at koden er sikker og kan holdes kørende.

Hvem ejer koden, når jeg bruger Lovable eller Bolt?+

Det afhænger af værktøjets vilkår, så læs dem før du bygger noget forretningskritisk. I praksis er det vigtigste spørgsmål om du kan få koden og dine data ud. De store værktøjer kan kobles til GitHub, så koden er let at flytte, mens data i værktøjets egen database kan kræve en manuel flytning. Tjek det tidligt, mens appen er lille.

Gør vibe coding udviklere overflødige?+

Det tror jeg ikke, men arbejdet flytter sig. Mindre tid går med at skrive standardkode, og mere går med arkitektur, sikkerhed, gennemgang og drift. Samtidig betyder flere prototyper flere apps der skal gøres klar til rigtige brugere. Det der bliver mindre værd, er at kunne skrive kode hurtigt. Det der bliver mere værd, er at vide hvilken kode der kan holde.