For få år siden var “byg en app” noget, der krævede et budget, et bureau og en deadline og budget, der… hov-sa! …stak af. I dag kan du komme fra idé til prototype på timer – uden at kunne kode. Det er kernen i vibe coding: naturligt sprog ind, fungerende løsning ud – i små iterative loops.

Men: hurtig udvikling gør ikke automatisk en løsning hverken sikker, robust eller lovlig. Så hvordan du kommer i gang – og hvornår skal du lade være.

Hurtigt er en feature. Sikkert er en disciplin.

Hvad er vibe coding – kort fortalt

Vibe coding er en AI-drevet udviklingspraksis, hvor du:

• beskriver ønsket funktion i naturligt sprog
• lader en agent generere (og ofte køre) koden
• evaluerer outputtet (ikke koden) i korte, iterative loops

Loopet er hele pointen: du bygger noget hurtigt, tester, justerer kravene, og gentager. Det giver en kæmpe fordel – især for SMV’er og iværksættere – fordi du kan teste idéer og før du investerer tungt i tid og udvikling.

Typiske “gode vibe coding”-cases:

• en landing page med formular og logik
• en proof-of-concept (PoC), der viser at en idé kan fungere
• en simpel intern app (fx registrering, overblik, indsamling af data)

Typiske “pas på”-cases:

• systemer med betaling, helbredsdata eller følsomme persondata
• kritisk drift (hvis det fejler, stopper forretningen)
• store, eksisterende kodebaser med komplekse afhængigheder

AI prototyping: køreplanen fra idé til prototype

Her er en køreplan, der gør processen konkret.

Trin 1: Start med denne model: optimér, forstærk eller transformér
Før du åbner et værktøj, så beslut hvilken type opgave du egentlig løser:

• Optimér: Gør noget eksisterende bedre/hurtigere/billigere.
• Forstærk: Gør noget, I allerede kan, mere synligt eller mere effektivt.
• Transformér: Gør noget nyt muligt (ny service, ny arbejdsgang, ny kanal).

Trin 2: Definér en persona (ja, også internt)
Hvem bygger du til? Skriv det ned som 4 bullets:

• rolle
• mål
• udfordringer
• pain points

Når personaen sidder, bliver det meget lettere at vælge funktioner fra. (Kill your darling(s) og Keep it simple)

Trin 3: Lav en gap-analyse
Sammenlign:

• hvad brugeren prøver at opnå
• hvad der findes i dag
• hvad der mangler (gap’et)

Tommelregel: Hvis du ikke kan beskrive gap’et i 2–3 sætninger, er du ikke klar til at bygge endnu.

Trin 4: Test som en kynisk bruger
Kør 3 runder:

• Kan jeg forstå det uden forklaring?
• Kan jeg ødelægge det med “dumme inputs”?
• Kan jeg få det til at lække noget, jeg ikke burde se?

Trin 5: Beslut: er det “for sjov” eller “for drift”?
Her er den vigtige skillelinje:

• En kampagneside / prototype må gerne være lidt rå, hvis den er isoleret og ikke håndterer følsomme data.
• Et backend-system, som din virksomheden er afhængig af, er en helt anden disciplin: dokumentation, test, sikkerhed, governance, drift og ansvar.

Jeg kommer selv fra bureauverdenen, og én ting er sikker: de bedste udviklere er ikke “hurtige fingre” – de er systematiske, dokumenterer deres arbejde og designer løsninger, der kan driftes. Det mindset skal med, når noget går fra prototype til produkt.

Lovable: prompt → prototype i praksis

Når du har styr på formål, persona og gap, kan du gå fra prompt til prototype. Tænk på din prompt som en mini-brief (kort, konkret og testbar).

Prompt-skabelon (copy/paste):

• Formål: Hvad skal være sandt, når vi er færdige?
• Målgruppe/persona: Hvem bruger det – og hvorfor?
• Use cases (3–5): Hvad skal brugeren kunne gøre?
• Data: Hvilke felter gemmer vi (og hvilke gemmer vi ikke)?
• Regler/krav: GDPR/data-minimering, login, rettigheder, audit-log (hvis relevant).
• UI: Hvilke skærme/flows skal findes (hold det simpelt).
• Definition of done: Hvordan tester vi, at det virker?

I din første version: gå efter en PoC eller en simpel web-side++ – ikke “hele platformen”. Det matcher også en naturlig modenhedsstige: PoC → landing pages → simple apps → apps++.

Bonus-tip: Skriv også 3 ting, der ikke skal være med. Det er den hurtigste måde at holde scope klart.

Sikkerhed, GDPR og EU AI Act

Her er den del som ikke er sexet og som mange springer let henover – og som senere bliver dyr. Vibe coding kan være vildt effektivt, men “hurtigt” og “sikkert” er to forskellige ting.

Hvornår du ikke skal vibe code (eller i hvert fald ikke alene):

• når det er sikkerheds-/compliancekritisk
• når du arbejder i en stor, kompleks kodebase
• når krav er uklare, og der er behov for dyb arkitektur (her er klassisk, review-drevet udvikling sundere)

Mini-risikovurdering
Score dit projekt på de her punkter:

• Data: Håndterer vi persondata, betalinger eller helbredsinfo?
• Konsekvens: Hvad sker der, hvis løsningen fejler (omsætning, drift, tillid)?
• Eksponering: Er det offentligt – og kan alle trykke på knapperne?
• Afhængighed: Bliver vi låst til én platform/vendor?

Hvis 2–4 er “høje”, så skal du op i gear på sikkerhed, test og dokumentation – og ofte have en udvikler med.

Sikkerhed & compliance – minimum før noget går i produktion:

• Beskyt secrets: API-nøgler og credentials må aldrig ligge i client-side kode eller i et repo.
• Budget/limits: Sæt forbrugslofter hos platform-/API-leverandører, så du ikke får en uventet regning.
• Rate limiting: Beskyt endpoints mod misbrug og simple DoS-angreb (overbelastning).
• Input-validering: Sanitér og valider input for at reducere risiko for fx injection-angreb.
• Brug etablerede leverandører: Til “svære ting” som betaling, database og login/auth er standardløsninger ofte mest sikre.

Og ja: Der findes reelle skrækhistorier. Kritikken går typisk på apps der gemmer passwords i klartekst, sender persondata til tilfældige API’er, eller lægger API-/database-oplysninger på client-side. Det er ikke “vibe coding’s skyld” – det er manglende praksis og governance.

Til sidst: Husk GDPR (data-minimering, formål, sletning, databehandleraftaler), og at EU AI Act kan stille krav afhængigt af use case og risiko. Overvej også, om der er krav/ønsker om datalagring i EU/EEA (data residency) hos jer eller jeres kunder.

FAQ

1) Skal jeg kunne kode for at vibe code?
Næææh. Men du får bedre resultater, hvis du kan beskrive krav tydeligt og teste kritisk. Lidt basisforståelse af data, login og sikkerhed hjælper dog en del.

2) Hvad er den bedste første ting at bygge med vibe coding?
En lille PoC eller en landing page++, der beviser værdien: formular, simpelt flow, måske et overblik – uden følsomme data. Fx en to-do app til indkøb

3) Hvornår bør jeg involvere en udvikler?
Når der er persondata, betaling, høj drift-kritikalitet, eller hvis løsningen skal leve længe og skaleres. Så bliver dokumentation, test og arkitektur vigtigt.