AI i praksis (vibe coding): sådan bruger du AI som makker uden at miste kontrollen

Kort fortalt: Hvad er vibe coding?

Vibe coding er en måde at bygge software på, hvor du beskriver det, du vil have, i helt almindeligt sprog, og lader en AI-model foreslå eller skrive koden. Du arbejder iterativt: beskriv → få kode → afprøv → justér. AI’en kan skrive meget, men ansvaret for krav, kvalitet, sikkerhed og beslutninger ligger stadig hos dig.

I praksis betyder det, at du ikke starter med at åbne en tom editor og skrive alt fra bunden. Du starter med at beskrive en funktion: “Jeg vil have en simpel bookingside til et autoværksted med kalender, kundeliste og bekræftelsesmail”. AI’en genererer kode eller en hel lille app, du så tester, retter og tilpasser.

Det minder om AI-assisteret programmering, men med en vigtig nuance:

• Vibe coding: Du beskriver en hel løsning og lader AI’en tage store skridt på én gang. Godt til hurtige prototyper, men kræver skarp kontrol bagefter.
• AI-assisteret udvikling: Du er mere finmasket. Du beder AI om små ændringer, snippets og forslag og gennemgår dem grundigt. Mere kontrolleret, velegnet til produktion.

I resten af artiklen går vi igennem, hvornår vibe coding er en god idé, hvilke værktøjer der giver dig passende kontrol, og hvordan du konkret arbejder, så AI er makker og ikke autopilot.

Hvornår giver vibe coding mening – og hvornår gør det ikke?

Vibe coding er stærk, når du bygger noget nyt, afgrænset og relativt ufarligt: idéer, prototyper, små interne værktøjer. Risikoen stiger, når du bruger det i eksisterende systemer, der allerede kører i drift (brownfield), eller hvor der er login, betaling, følsomme data eller høj oppetidskrav.

En enkel måde at vurdere egnethed på er at kigge på to ting:

• Projektets modenhed: idé, prototype, intern løsning, produktion.
• Risiko: påvirker det mange brugere, penge, data eller drift?

Egnethedsmatrix for vibe coding

Hurtig “bedst til / undgå når”

Bedst til:

• Nye idéer og prototyper, hvor du vil se noget visuelt hurtigt.
• Små interne værktøjer uden følsomme data.
• Personlige projekter og læring af webudvikling.

Undgå / vær meget forsigtig, når:

• Løsningen styrer betaling, ordrer, logistik eller andre driftskritiske flows.
• Der behandles persondata eller fortrolige virksomhedsoplysninger.
• Ingen med kodeerfaring kan gennemgå og teste resultatet ordentligt.

Hvis du er i tvivl, så start med vibe coding til idé og prototype, og skift over til en mere kontrolleret AI-assisteret tilgang, når noget nærmer sig produktion.

Sådan bruger du AI uden at miste kontrollen

Du bevarer kontrollen ved at arbejde i små, tydelige skridt: afgræns opgaven, sæt klare acceptkriterier, lad AI foreslå en ændring, gennemgå diffs, test, gem i Git og deploy kun efter review. Aldrig shippe AI-kode direkte til produktion uden menneskelig gennemgang og test.

En enkel kontrolmodel: Krav → Build → Review → Test → Deploy

1. Krav
   Beskriv én afgrænset ting, du vil have bygget. Ikke “lav et helt CRM”, men fx “tilføj en side, hvor brugeren kan oprette en booking med dato, navn og telefonnummer”. Definér 3 – 5 acceptkriterier, fx:
   • Formularen har felter for navn, telefon og dato.
   • Der er validering på telefonnummer og dato.
   • Data gemmes i lokal storage / database X.
   • Brugeren får en kort bekræftelse på skærmen.
2. Build med AI
   Brug et AI-værktøj til at generere koden. Del opgaven i små bidder. I stedet for én kæmpe prompt kan du fx skrive:
   • “Her er min nuværende HTML. Tilføj en formular efter afsnit Y med felterne …”
   • “Tilføj JavaScript, der gemmer disse felter i localStorage.”
   • “Skriv validering, så dato ikke kan være før i dag.”

   Hvis du vil nørde dybere i prompts, er der konkrete tips i denne guide til prompts til kodning.

3. Review: læs, som om det var en kollegas kode
   AI-kode skal behandles som kode fra en juniorudvikler, du ikke helt kender stilen på endnu. Tjek fx:
   • Hvad er ændret? Brug diff-visning.
   • Er der hårdkodede API-nøgler eller tokens? Hvis ja, stop og læs om sikker håndtering af tokens.
   • Er der inputvalidering, eller kan brugeren skrive hvad som helst ind?
   • Bruger koden pakker eller biblioteker, du ikke kender? Undersøg dem kort.

   Undgå at copy-paste ukritisk. Der er en grund til, at der findes en helt artikel, der hedder stop med bare at copy-paste AI-kode.

4. Test: mere end “det virker på min maskine”
   Lav mindst disse tests, før noget får lov at leve videre:
   • Manuelle tests af de vigtigste flows (happy path + et par fejlscenarier).
   • Regression: tjek at eksisterende funktioner ikke er gået i stykker.
   • Hvis du har automatiserede tests, så kør dem hver gang. Hvis du ikke har, kan du starte med at læse om testkultur i denne guide til at faktisk få kørt tests.
5. Deploy: altid med sikkerhedsnet
   Før du shipper til rigtige brugere:
   • Gem ændringen i en separat Git-branch med meningsfuld besked.
   • Brug feature flags, så du kan slå den nye funktion til/fra uden at rulle hele deploy tilbage.
   • Sørg for logning og monitorering, så du kan se, hvordan den nye funktion opfører sig i drift. Her er logs vs mavefornemmelse en god intro.

Typiske kontrolpunkter, du ikke skal springe over

• Diff gennemgang: Forstå alle ændringer, før du merger.
• Dependencies: Tjek nye biblioteker for vedligeholdelse og sikkerhed.
• Secrets: Ingen API-nøgler i klientkode eller repos. Brug miljøvariabler (env vars), og læs gerne om, hvorfor secrets skal være kedelige.
• Rollback-plan: Ved du præcis, hvordan du ruller tilbage, hvis noget går galt?

Hvis du arbejder i et team, så sørg for, at jeres måde at bruge AI på hænger sammen med jeres generelle governance for sikkerhed og udvikling.

Værktøjer til vibe coding: hvad skal du vælge?

Valget af værktøj handler mindre om “hvad er mest hypet?” og mere om hvor meget kontrol du vil have, og hvor teknisk du er. Groft sagt:

• App-builders er gode til begyndere og hurtige prototyper, men du har mindre kontrol over koden.
• AI-kodeeditorer er gode til udviklere, der vil have forslag inde i deres IDE og fuld kontrol over repoet.
• Terminal-agenter er for erfarne brugere, der vil have AI til at køre kommandoer og ændre filer direkte.

Sammenligningstabel over værktøjstyper

Hvordan vælger du?

Stil dig selv tre spørgsmål:

• Mit niveau: Kan jeg læse og forstå kode? Hvis nej, så start med app-builder og meget små projekter.
• Mit formål: Skal det i produktion, eller er det til læring og demo? Jo tættere på produktion, jo mere taler det for AI-kodeeditor frem for ren app-builder.
• Mit kontrolbehov: Skal løsningen integreres i eksisterende systemer? Så vælg noget, der spiller godt med Git og dine nuværende værktøjer.

Hvis du allerede arbejder med AI til kodning, fx ChatGPT, er det værd at læse guiden til ChatGPT på dansk for udviklere og eventuelt sammenligne modeller i dybden via overblikket over kodeorienterede AI-modeller.

Hvad koster vibe coding – og hvor hurtigt kan du komme i gang?

Du kan komme i gang med vibe coding gratis eller for få hundrede kroner om måneden. De fleste værktøjer har gratis niveauer til små projekter. Prisen stiger, når du bruger det meget, har brug for teamfunktioner, bedre sikkerhed eller enterprise-kontrol.

Vejledende prisbillede

Derudover kan du vælge kurser eller workshops. Her ligger et intensivt to-dages forløb typisk i niveauet nogle tusind kroner pr. deltager ekskl. moms, afhængig af udbyder og indhold.

Husk at priser og funktioner ændrer sig hurtigt. Nogle modeller afregnes efter tokens (mængden af tekst/kode, du sender og får tilbage). Hvis du vil forstå det teknisk og økonomisk, kan du dykke ned i guiden om tokens, pris og context length.

Hvad kan man faktisk bygge med vibe coding?

Med vibe coding kan du bygge overraskende meget: alt fra en simpel to-do webapp til et internt bookingsystem. Det fungerer bedst til afgrænsede løsninger med få brugertyper og enkle flows. Jo mere komplekst og kritisk systemet bliver, jo mere skal vibe coding betragtes som prototypeværktøj, ikke som “færdig løsning på første hug”.

Eksempel 1: Simpelt internt dashboard

Problem: Et lille team vil have et internt dashboard, der viser opgaver fra et regneark, status og deadlines.

Med vibe coding:

• Beskriv ønsket: “Byg en enkel webapp, der læser en CSV med kolonnerne X, Y, Z og viser dem som tabel med filtrering på status.”
• AI’en genererer HTML, CSS og JavaScript til at læse CSV og vise data.
• Du tester, retter kolonnenavne, tilføjer lidt styling og gemmer det som intern side.

Resultat: Hurtig værdi, lav risiko, fordi ingen persondata bruges, og appen kun lever internt.

Eksempel 2: Bookingside til autoværksted (prototype)

Problem: Et autoværksted vil teste en online bookingløsning.

Med vibe coding:

• Du beskriver: “Byg en simpel bookingside med kalender, hvor kunder kan vælge dato, tid, angive registreringsnummer og telefonnummer. Gem data i en simpel database eller fil. Ingen login.”
• AI’en genererer en grundlægger app med formular, liste og simpel lagring.
• Du gennemgår koden, tester med fiktive data og viser prototypen til værkstedet.

Resultat: God til at teste konceptet. Men før rigtig drift skal du stramme sikkerhed, databehandling og drift op manuelt.

Eksempel 3: Lidt for ambitiøs produktion fra dag 1

Problem: En mindre webshop vil “bare lige” have AI til at bygge en ny betalingsløsning og sende den live hurtigt.

Hvis du kører ren vibe coding her:

• AI’en kan godt bygge en integration til en betalingsgateway og en ny checkout-side.
• Men der er stor risiko for manglende fejlhåndtering, utilstrækkelig logging, ingen rate limiting og små sikkerhedshuller.

Konklusion: Det er et typisk eksempel, hvor vibe coding kan bruges til et internt proof of concept, men hvor produktionen kræver en langt mere kontrolleret proces, manuel sikkerhedsgennemgang og ofte ekstra ekspertise.

Hvad kan gå galt – og hvordan undgår du det?

De største problemer opstår sjældent, fordi AI laver en åbenlys syntaksfejl. De opstår, når du giver uklare prompts, stoler blindt på output, ikke tester nok eller bruger vibe coding til noget, der er mere risikabelt, end du tror.

Fem klassiske fejl ved vibe coding

1. Uklare prompts giver uklare løsninger
   Hvis du skriver: “Lav et bookingsystem”, får du noget, der ligner et bookingsystem, men som ofte mangler det, du faktisk brugte tid på at forklare i mødet med brugerne.
   Modtræk: Skriv konkrete krav, lav eksempler på data, og byg i små dele. Brug gerne teknikkerne fra denne prompt-guide.
2. Blind tillid til AI-output
   AI kan hallucinere pakker, metoder og API’er, der ikke findes, eller bruge usikre kodemønstre.
   Modtræk: Antag, at intet er 100 procent rigtigt, før du har læst, testet og evt. slået op i dokumentationen.
3. Ingen eller for svag sikkerhed
   Typiske mønstre er manglende inputvalidering, SQL-injektioner, API-nøgler i frontend og svage adgangskontroller.
   Modtræk: Kør et sikkerhedsreview, især på endpoints, der håndterer login, betaling eller data. Læs fx om tokens og opbevaring af API-nøgler.
4. Manglende tests og rollback
   Hvis du bare merger AI-koden direkte på main, uden tests og mulighed for at rulle tilbage, er du reelt passager i dit eget repo.
   Modtræk: Brug Git-branches, automatiske tests og feature flags. Hav altid en tydelig rollback-plan.
5. Overforbrug og uforudsete omkostninger
   Hvis du integrerer direkte mod en AI-API uden rate limiting, kan et script løbe løbsk og bruge langt flere tokens end forventet.
   Modtræk: Indbyg rate limiting, logging og alarmer på API-kald.

GDPR og vibe coding: sådan undgår du at træde forkert

Vibe coding kan godt bruges i en GDPR-kontekst, men kun hvis du har styr på, hvilke data du sender til AI-værktøjer, på dit behandlingsgrundlag og på de tekniske og organisatoriske foranstaltninger omkring udviklingen. Det kritiske punkt er persondata og fortrolige oplysninger, der ryger ind i eksterne tjenester.

Grundprincipper, du skal have på plads

• Ingen persondata i ukontrollerede værktøjer
  Send ikke rigtige navne, CPR-numre, helbredsoplysninger, elevdata eller lignende til offentlige AI-tjenester, medmindre der er lavet en klar aftale og vurdering.
• Testdata skal være “falske nok”
  Brug syntetiske data eller anonymiserede datasæt, når du tester AI-genereret kode.
• Dataminimering
  Send kun det, der er nødvendigt til AI’en. Klip kode/konfiguration ned, før du kopierer det ind i et promptfelt.
• Databehandleraftaler
  Hvis AI-værktøjet behandler persondata på dine eller din organisations vegne, skal der være styr på databehandleraftale og dokumentation.

Mini-compliance-proces til udvikling med AI

1. Kortlæg data
   Hvilke datatyper indgår i systemet? Persondata, fortrolige forretningsdata, kun offentlige data? Skriv det ned.
2. Bestem, hvad AI må se
   Definér en klar regel: “Disse datatyper må aldrig i eksterne AI-tjenester” vs. “disse må kun via godkendte værktøjer”.
3. Vurder risici
   Hvis systemet håndterer persondata eller anden højrisiko-information, kan du have brug for en konsekvensanalyse (DPIA) efter GDPR-reglerne. Datatilsynet har skabeloner og vejledning, som er gode at læne sig op ad.
4. Vælg værktøjer med omtanke
   Brug helst værktøjer, der tilbyder datalagring i EU/EØS eller klare aftaler om databehandling. Tjek, om der er mulighed for at slå træning på dine data fra.
5. Tekniske foranstaltninger
   Hold secrets og nøgler ude af kodebasen (brug miljøvariabler), sørg for logning og adgangsstyring, og overvej sikkerhedsheaders som Content Security Policy i webapps.
6. Organisatoriske foranstaltninger
   Lav interne retningslinjer for, hvordan teamet må bruge AI. Her er guiden om IT- og cybersikkerhed governance et godt sted at starte.

Hvis din organisation i forvejen har en privatlivspolitik, så sørg for, at måde at bruge AI på ikke undergraver det, I allerede har lovet brugerne.

Trin for trin: sådan kommer du i gang med vibe coding

Den bedste måde at lære vibe coding på er at tage ét konkret, lille problem og føre det hele vejen fra idé til fungerende løsning. Her er en enkel workflow, du kan følge.

1. Vælg en lille, ufarlig opgave

Vælg noget, der ikke handler om betaling, login eller følsomme data. Gode første opgaver:

• En simpel to-do-liste i browseren.
• En formular, der samler input og viser det på en resultat-side.
• Et lille dashboard, der viser statiske eller syntetiske data.

2. Skriv en kort kravspecifikation

Svar på:

• Hvem skal bruge det?
• Hvad skal de kunne gøre på siden?
• Hvordan ser succes ud? (3 – 5 klare acceptkriterier)

Det er den tekst, du giver AI’en som startprompt.

3. Vælg værktøj og model

• Er du begynder: vælg en app-builder med grafisk interface.
• Er du vant til VS Code: prøv en AI-kodeeditor.
• Vil du bare teste idéen: et browserbaseret værktøj som Replit eller et tilsvarende setup er ofte nok.

4. Byg første version med AI

Start med en prompt som:

“Jeg vil bygge en simpel webapp, der gør X. Brug HTML, CSS og JavaScript. Start med en version, der kun har [funktion A]. Skriv koden, og forklar kort, hvordan jeg kører den lokalt.”

Kør koden, se hvad der sker, og notér hvad der ikke lever op til dine acceptkriterier.

5. Iterér i små skridt

For hver iteration:

• Beskriv ét problem eller én forbedring.
• Bed AI’en rette på eksisterende kode frem for at omskrive alt.
• Test ændringen, før du går videre.

6. Ryd op, gem og dokumentér

• Ryd duplikat-kode og døde filer væk.
• Gem projektet i Git med meningsfulde commits.
• Tilføj en kort README med:
  • Hvad appen gør.
  • Hvordan man kører den.
  • Hvad der er kendte begrænsninger.

7. Først derefter: overvej næste skridt

Når din prototype virker lokalt, kan du overveje:

• Skal den deployes til et testmiljø?
• Skal den kobles på rigtige data? (Ofte: ikke endnu.)
• Skal du skifte fra vibe coding til en mere kontrolleret AI-assisteret udviklingsstil for den videre udvikling?

Hvis du vil bruge AI som sparringspartner mere generelt i din kodehverdag, er der flere praktiske råd i overbliksartiklen om AI som medprogrammør uden at blive passager i eget repo.

Opsummering: AI som makker, ikke autopilot

Vibe coding gør det muligt at komme fra idé til kørende prototype på timer i stedet for uger. Men gevinsten kommer kun rigtigt hjem, hvis du samtidig tager kontrol alvorligt: klare krav, små iterationer, gennemgang af kode, tests, sikkerhed og dokumentation.

Brug vibe coding mest til idéudvikling, prototyper og interne værktøjer uden høj risiko. Når en løsning nærmer sig produktion, skal du spænde sikkerhedsselen: stram review, test og governance op, og behandl AI som en dygtig, men uforudsigelig junior, du altid dobbeltchecker.