Hvad er vibe coding, og hvorfor ændrer det måden, vi arbejder på?

Vibe coding er på kort tid blevet et fast begreb i AI-land og blandt produkt- og softwareudviklere.

Navnet er ikke tilfældigt. “vibe” peger på en mere kreativ og mindre skræmmende måde at tænke kode på, hvor man ikke nødvendigvis sidder og finretter hver eneste linje, men arbejder i et flow af hurtige iterationer. Pludselig kan du “tale” et stykke software frem. Ikke som magi, men som en ny form for samarbejde mellem menneske og maskine, hvor AI’en producerer koden, og du producerer og definerer intentionen.

Det betyder, at flere kan være med til at bygge, at prototyper bliver til på rekordtid, og at feedback-loops kan blive ekstremt korte. Til gengæld opstår der nye krav til kvalitet, sikkerhed og arbejdsprocesser. For vibe coding kan bringe dig hurtigt frem i feltet, men det kan også gøre, du kører i grøften i racerbilsfart.

For at forstå vibe coding i praksis har vi talt med Anne Lindberg, der er softwareudvikler i Digitalisering og IT i Region Midtjylland og stifter og konsulent i LindbergAI, hvor hun hjælper virksomheder med at komme hurtigt i gang med AI-drevne løsninger. Hun arbejder dagligt med generativ AI, er uddannet softwareingeniør og har en stærk baggrund i backend-udvikling, AI-værktøjer og digital produktudvikling.

Hvad er vibe coding med dine ord?

“Hvis vi skærer det helt ind til benet, så er Vibe coding, at du bruger generativ AI til at kode for dig. Du beskriver, hvad du vil have, i en prompt, og så skriver modellen koden. Lidt som når man får AI til at generere tekst eller billeder, bare med software som output.”

Hvor stammer begrebet fra, og hvad adskiller vibe coding fra almindelig prompting?

“Begrebet blev især kendt gennem et opslag fra Andrej Karpathy, AI-forsker og tidligere AI-leder hos Tesla, som i februar 2025 skrev, at han var begyndt at kode på en ny måde, han kaldte vibe coding. Bevægelsen med at lave kode via prompts var allerede godt i gang – men nu kom der altså et navn, for den måde at udvikle på. Pointen var netop at overgive sig til flowet. Man sidder ikke og finretter hver eneste linje selv. Man kigger på resultatet, copy-paster, og når noget knækker, smider man fejlbeskeden tilbage i modellen og siger i praksis: Fix det, og så itererer man derfra. I Karpathys egen beskrivelse går det så langt, at han næsten ikke rører tastaturet, men kan snakke til værktøjet og få ting bygget.

Prompting er et kæmpe begreb, der kan dække alt fra tekst og billeder til analyse og ideudvikling. Vibe coding er mere specifikt: Det er prompting med det meget konkrete formål at få et stykke software til at virke gennem hurtige iterationer. Du bygger ved at beskrive, afprøve, fejlfinde og forbedre og i den rene vibe coding-ånd, behøver du ikke nødvendigvis forstå hver linje kode undervejs, så længe du kan styre retning og verificere resultatet.”

Kan du huske dit første møde med vibe coding?

“Jeg kan virkelig godt huske det. Jeg tror faktisk ikke, jeg vidste, at det hed vibe coding dengang. Jeg så et opslag på LinkedIn om nogen, der havde prøvet et værktøj, og jeg tænkte: Det ser godt nok smart ud. Jeg har aldrig været særlig god til at lave UI og frontend. Jeg arbejder som backend-udvikler, så jeg satte værktøjet til at lave en hjemmeside for mig, og jeg var helt blown away over, at den spyttede alt muligt fedt ud. Jeg sagde det til alle, jeg kendte, både på mit arbejde og i min familie.

Jeg fik endda min far, der går meget op i vin, til at lave en vinside og noget til hans golfklub. Jeg syntes, det var sindssygt fedt, at jeg lige pludselig kunne gøre noget, jeg ellers altid har haft rigtig svært ved. Så det var virkelig en åbenbaring. Det kan virkelig noget, tænkte jeg. Og så er det bare gået hurtigt siden.”

Hvilke konkrete udfordringer i produktudvikling hjælper vibe coding med at løse?

“Den største forskel er hastighed. Før kunne det tage virkelig lang tid at bygge noget, selv en enkelt feature kunne være uger eller måneder. Med vibe coding kan du ofte få en første version på få dage, og det betyder, at du kan teste tidligere og lære hurtigere.

Men det handler ikke kun om fart. Det ændrer også, hvem der kan være med til at bygge. Pludselig bliver det mere tilgængeligt – softwareudvikling bliver demokratiseret, kan du sige. Flere i teamet kan bidrage direkte til at få noget op at stå, ikke kun den klassiske udviklerrolle. Det kan være produktfolk, designere eller andre, der kan beskrive behovet klart og iterere sammen med værktøjet.

Og så er der noget, jeg synes er ret vigtigt, nemlig personligt software. I stedet for at købe endnu et tool og endnu et abonnement, kan man i mange tilfælde bygge det, man selv har brug for, ret præcist. Små løsninger, der passer til den konkrete hverdag, uden at du skal vente på en stor udviklingsproces.

Jeg kan fx huske engang, en kollega og jeg ikke kunne finde ud af, om vi skulle bruge Trello eller JIRA til et projekt – og begge var nok lidt overkill i forhold til, hvad vi skulle bruge det til. Så satte vi os ned, og på halvanden time havde vi lavet det, vi brugte til at holde styr på vores projekter og opgaver. Der er vibe coding virkelig stærkt.”

Er der andre stærke use cases for vibe coding?

“Prototyper – dér er vibe coding også virkelig stærkt. Når du kan få dine idéer hurtigt ud både visuelt og funktionelt, så du kan teste dem og få feedback med det samme. Vibe coding er også godt til kundedialoger og stakeholder-samtaler. Hvis du kan bygge en skitse live eller inden for meget kort tid, bliver det meget nemmere at afklare: Var det her det, I mente? Eller var det slet ikke det? Det sparer ekstremt mange runder med antagelser.

Vibe coding er også godt til de små løsninger, der ellers aldrig bliver prioriteret. Det kan være interne værktøjer eller personligt software, hvor man normalt ville ende med at købe et nyt tool eller leve med en workaround. Her kan vibe coding gøre det realistisk at bygge en lille løsning, der passer præcis til behovet, uden at det bliver et kæmpe projekt, der suger ressourcer ud af organisationen.”

Hvad er vibe coding ikke godt til?

“Jeg plejer at sige, at vibe coding tools er rigtig gode til simple til mellemkomplekse projekter. Men hvis man skal lave noget, der er rigtig, rigtig komplekst, så kan det godt være, at man ikke skal vibe code det hele, men i stedet finde nogle dygtige udviklere, der kan hjælpe en med at lave det.

Det handler i høj grad også om, hvad man sidder med. Hvis man ikke selv har den tekniske forståelse, og man arbejder med noget komplekst, der måske også rummer personfølsomme data, så skal man kunne sikre sig, at det vibe coding-værktøj man har brugt, ikke har lavet et eller andet lille smart trick for at gøre det nemmere for sig selv, men som måske ender med at udgøre en sikkerhedsrisiko i den software man har bygget.

Ved komplekse systemer vil jeg ikke bare vibe code det direkte. Det kræver grundigt forarbejde og en ordentlig opsætning af arkitektur, sikkerhed og governance, før det fungerer i praksis."

Hvordan ser en god vibe coding-proces ud i praksis?

“Hvis man vil sætte sig selv op til en god vibe coding-session, så starter det med at modne idéen. Man kan gøre det alene, men man kan også bruge fx ChatGPT til at sparre om scope, behov og hvad der konkret skal bygges.

Når jeg ved nogenlunde, hvad løsningen skal kunne, plejer jeg at tegne nogle wireframes eller få noget visuelt ned. Det gør prompts langt skarpere. Derefter smider jeg det ind i et værktøj som Lovable, som også er bygget sådan, at hvis det er usikker på det, du spørger om, så stiller den opklarende spørgsmål.

Nogle gange bruger jeg det mere spontant. Hvis jeg bare har en idé, jeg vil teste hurtigt, så springer jeg de første trin over, åbner Lovable og bruger annoteringsfunktionen til at sige: ‘Byg det her’. Outputtet er ikke nødvendigvis det, man ender med at bruge, men det kan være nok til hurtigt at se retningen og teste, før man investerer mere tid.

Og hvis det skal i produktion, så er det ofte ret enkelt. Der er en publish-knap, og du kan i praksis udgive med ét klik. Hvis du har dit eget domæne, kan du koble det på, ellers genererer de et for dig.”

Hvilke faldgruber ser du oftest, når folk går i gang med vibe coding?

“Der er faldgruber, men jo bedre værktøjer man bruger, jo færre falder man ned i, fordi de har indbyggede guardrails (sikkerhedsmekanismer red.), der hjælper med at undgå sikkerhedshuller.

En typisk fejl i starten er, at outputtet bliver meget generisk og ikke ser særlig godt ud, og derfor skal man lære at prompte på en måde, der løfter både kvalitet og udtryk. Og så er det afgørende at tænke design først, når man prompter, for det er i sidste ende garbage in, garbage out, så det handler om at blive dygtig til at prompte.”

Hvordan sikrer man kvalitet undervejs?

“Der er helt sikkert fordomme om kodens kvalitet, og det var måske også mere rigtigt for et år siden, eller bare for et halvt år siden. Men værktøjerne rykker så hurtigt nu, at hvis man nogenlunde ved, hvordan man prompter dem teknisk, kan man ofte fange fejlene undervejs, og de opstår heller ikke per default på samme måde længere. Tidligere kunne man for eksempel opleve, at API keys endte i en fil og blev synlige (nøgler der burde være skjult var tilgængelige for alle, red.), men det er ikke sådan, de er designet i dag. De fleste tools har et sikkerhedstjek, man kører før udgivelse, som fanger langt størstedelen af fejlene. Men man kommer selvfølgelig ikke udenom det grundlæggende: Du skal altid teste din kode og sikre, at det hele spiller.”

Hvilke værktøjer er mest udbredte?

“Hvis vi tager det mest udbredte tool lige nu, så er Lovable, som jeg allerede har nævnt, et vibe coding tool fra Sverige, og det er helt klart et af de største. Det fungerer også som et no-code tool, hvor man egentlig ikke behøver at se koden, hvis man ikke har lyst.

Og så er det selvfølgelig også værd at tilføje, at hvis man er udvikler, eller har mod på at prøve kræfter med lidt tungere vibe coding tools, så kan man prøve claude code eller cursor, som er to af de meget populære tools på markedet lige nu.

Det, der kendetegner området lige nu, er i det hele taget hastigheden. Jeg har oplevet, at nogen spørger til en workshop – hvorfor kan værktøjet ikke gøre X, Y, Z, fx eksportere til webshop, og så næste morgen annoncerer de, at nu kan man bygge en hel webshop ved at trykke på en knap. Så hurtigt rykker det – det er vildt.”

Hvad ændrer vibe coding i teams og måden man samarbejder på?

“Hvis man tager de her værktøjer til sig, så ændrer det samarbejdet ret markant. Man kan for eksempel eksportere direkte fra Figma, så hvis en UX’er har lavet et virkelig flot stykke arbejde, kan man tage det og få det direkte ind i Lovable. Derefter kan udviklerne køre det op og koble det sammen med backend, hvis de vil bruge noget andet der. Og det fede er, at næsten alle tools gør det muligt at sidde derinde sammen, næsten som i Google Docs, hvor man kan prompte på tværs og se ændringerne ske. Så kan man faktisk arbejde meget mere fælles om at få produkterne til at spille.”

Hvad bliver vigtigst inden for vibe coding det næste år?

“Jeg tror, det her ender med at blive rigtig vildt. Der kommer til at strømme enorme investeringer ind i de virksomheder, der er længst fremme, og udviklingen kommer til at accelerere. For mig bliver det vigtigste, at man går til det med åbenhed og en læringsmentalitet, og at man faktisk får værktøjerne ind i sin praksis. Dem, der vælger det fra, risikerer at sakke bagud. Jeg tror, det er afgørende at holde sig opdateret, fordi det her er den retning, vi bevæger os i, både som udviklere og som ikke-udviklere. Flere og flere kommer til at bruge de her værktøjer.

Samtidig rejser det nogle vigtige spørgsmål. Hvis vi i fremtiden skriver mindre kode selv, hvad betyder det så for dem, der er på vej ind i faget? Hvordan sikrer vi, at de stadig får de håndværksmæssige kompetencer og den systemforståelse, der skal til? Og jeg tror også, vi kommer til at se et behov for oprydning i noget af det, der bliver bygget hurtigt af folk, der ikke helt har erfaringen endnu, i hvert fald indtil værktøjerne bliver så modne, at de kan hjælpe med at rydde op lige så effektivt, som de kan bygge.
‍

Men for at gentage mig selv – jeg tror det bliver rigtig rigtig vildt!”

‍