Vibe coding betyder, at man bygger software ved at beskrive det, man vil have, til en AI, og at man tager imod den kode, der kommer ud, uden at læse eller forstå den. Man styrer efter, om resultatet virker på skærmen, og retter med nye beskeder. Metoden er fremragende til at afprøve en idé på få dage. Den bærer dårligere, når der kommer betalende kunder, persondata og en forventning om, at produktet stadig virker om et år. Grænsen går ved det tidspunkt, hvor andre end jer selv kommer til skade, hvis noget går galt.
Hvor ordet kommer fra
Udtrykket blev brugt af AI-forskeren Andrej Karpathy i februar 2025 om en måde at programmere på, hvor man overlader sig helt til værktøjet og glemmer, at der overhovedet ligger kode bag. Siden er ordet blevet bredere. Nogle bruger det i dag om al softwareudvikling med AI, også når erfarne udviklere læser hvert forslag.
Forskellen er vigtig. Ifølge definitionen hos OpenSSF, en organisation for sikkerhed i åben kildekode, holder det op med at være vibe coding, når et menneske gennemgår det, AI’en har skrevet. Det er også den skelnen, der betyder noget for jer som ledelse, for det afgørende er, om nogen har forstået koden.
Sådan foregår det i praksis
I skriver i et chatvindue, hvad appen skal kunne. Værktøjet laver skærmbilleder, logik og ofte en database. I prøver resultatet, skriver, hvad der skal ændres, og gentager. Der findes værktøjer til formålet, som samler det hele i browseren, og kodeværktøjer, der arbejder direkte i en mappe med kode. Forskellen er gennemgået i Lovable, Bolt, Cursor eller Claude Code.
For en ikke-teknisk stifter føles det som et gennembrud, og det er det på mange måder. I kan nu vise en idé frem, før I bruger penge på et udviklingshus.
Det egner metoden sig til
Vibe coding giver mening, når prisen for en fejl er lav:
- At afprøve en idé. Viser interesserede kunder et kerneflow, I kan klikke jer igennem, lærer I mere end af et dokument.
- At forklare, hvad I vil have. En klikbar prototype er en bedre beskrivelse end mange siders krav, også over for en kommende udvikler eller leverandør.
- Interne småværktøjer. Et lille værktøj til få kolleger, uden følsomme data og uden nogen, der er afhængig af det.
- At lære. Stifteren forstår hurtigere, hvad produktet egentlig består af.
Hvad en første version skal besvare, er uddybet i hvordan første version afgrænses.
Det ændrer sig, når rigtige kunder kommer ind
Der er fem steder, hvor en app ser færdig ud på skærmen og alligevel ikke er det.
Adgang. Kan en kunde se en anden kundes data, hvis vedkommende ændrer lidt i adressen eller forespørgslen? En demo med ét login viser det aldrig.
Nøgler. Appen taler med betalingstjenester, mailtjenester og databaser ved hjælp af hemmelige nøgler. Ligger de et sted, hvor browseren kan læse dem, kan alle andre også.
Data. Hvor ligger kundernes data, er der backup, og har nogen prøvet at læse den ind igen?
Fejl. Hvad sker der, når en betaling fejler halvvejs, eller to brugere gør det samme samtidig? Hvem får besked?
Ændringer. Jo større appen bliver, jo oftere retter AI’en én ting og ødelægger en anden, især når der ikke er automatiske test til at fange det. Mange stiftere når et punkt, hvor hver ny besked skaber lige så mange fejl, som den løser.
Ingen af punkterne betyder, at I har gjort noget forkert. De betyder, at produktet er kommet ind i en ny fase, hvor nogen skal eje det, der ikke kan ses på skærmen.
Fem spørgsmål, der viser, hvor I står
Stil dem ærligt. Ét nej er ikke farligt, og flere nej betyder, at det er tid til at stoppe op:
- Kan vi forklare, hvor kundernes data ligger, og hvem der kan se dem?
- Har vi prøvet at logge ind som to forskellige kunder og forsøgt at se hinandens data?
- Har vi selv koden og databasen i egne konti, uden for værktøjet?
- Har vi prøvet at genskabe data fra en backup?
- Kan vi rette en alvorlig fejl en lørdag, hvis værktøjet ikke lige finder løsningen?
Er svaret nej, og er I på vej mod betalende kunder, er rækkefølgen fra prototype til produkt det næste at læse. Ligger koden stadig kun i værktøjet, så start med, om I kan tage koden med ud.
Hvad vibe coding ikke ændrer
AI har gjort det billigere at skrive kode. De beslutninger, der altid har været de svære, er stadig tilbage: hvad produktet skal være, hvordan data skal organiseres, hvad der skal være sikkert, og hvem der tager telefonen, når det går galt. Det er den del, en CTO har ansvaret for, og den bliver mere synlig, når selve koden bliver let at få.
Det skal I lade være med
· At tage penge fra kunder for en urørt prototype. Betalende kunder med rigtige data er grænsen.
· At lægge rigtige persondata i en app, ingen har gennemgået. Brug opdigtede data, så længe I afprøver.
· At tolke en app, der virker, som en app, der er sikker. Det ene siger intet om det andet.
· At afvise det hele. Som afprøvning af en idé er metoden både hurtig og nyttig.
Det skal I kræve af den eksterne
- ☐ En forklaring uden fagord på, hvad der er solidt, og hvad der er skrøbeligt.
- ☐ Et klart råd om, hvor langt prototypen kan bruges.
- ☐ En prioriteret liste over det, der skal være på plads før første betalende kunde.
- ☐ Respekt for det, I har bygget, og for det, I har lært undervejs.
Kilder
- OpenSSF Glossary: Vibe coding: definition og oprindelse. Læst november 2026.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Eftersyn af AI-genereret kode før lancering · Ikke-teknisk stifter
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
