Vi skal holde op med at kalde alting for Vibe Coding

Jeg vendte tilbage til kodning efter en lang pause, og det var på Lovable, jeg begyndte igen. Appsene så fantastiske ud, virkede ved første øjekast, og blev samlet på få timer. I starten føltes det bemærkelsesværdigt. Men det var ikke længere nok, så snart jeg ville vide, hvad koden gjorde – og hvorfor. Det var da min tilgang begyndte at ændre sig.

Forskellen handler ikke om værktøjet eller hvor meget af koden AI skriver for dig. Det handler om den kontrakt, du accepterer med dit output: om du kan forklare, hvad du lige har frigivet i verden, eller ej.

Vibe coding, i sin oprindelige betydning, betyder at acceptere AI-genereret software uden at undersøge eller forstå, hvad der ligger under det. AI-assisteret udvikling er anderledes. Modellen kan stadig skrive størstedelen af koden, men personen der bygger systemet forbliver ansvarlig for at forstå dets opførsel, teste dets antagelser og beslutte, om det er klar til at blive udgivet.

For et engangs‑eksperiment, der aldrig forlader din egen maskine, kan forskellen have få konsekvenser. Når softwaren er implementeret, bruges af andre eller kobles på rigtige data, betyder det enormt meget.

Hvordan “Vibe Coding” mistede sin betydning

Udtrykket “vibe coding” blev opfundet i februar 2025 af Andrej Karpathy, medstifter af OpenAI. Hans eksempel var bevidst afslappet: et “kasteprojekt til weekenden” bygget ved automatisk at klikke på “Accept All”, ignorere forskellene og lade koden vokse ud over hans forståelse.

Uger senere bemærkede udvikleren og værktøjsskaber Simon Willison, at udtrykket blev brugt meget anderledes: som en erstatning for al AI-assisteret programmering, hvilket han argumenterede udvander udtrykket og giver et falskt indtryk af, hvad ansvarlig AI-assisteret udvikling kan opnå.

Det interessante er, at Karpathy til sidst indvilligede. Et år senere introducerede han et andet udtryk for mere disciplineret arbejde med kodningsagenter. Han beskrev “agentic engineering” som en arbejdsproces, hvor udviklere styrer og overvåger agenter i stedet for blot at acceptere, hvad de producerer. Skelnen betyder noget: professionel AI-assisteret udvikling kræver planlægning, granskningsarbejde og ansvarlighed på måder, som afslappet vibe coding ikke gør.

Grænsen er ansvar

Willisons regel er enkel, og den fungerer som en test for alle: commit kode, du ikke kan forklare til en anden. Det betyder ikke, at man skal læse hver eneste linje: når agenter genererer hundredevis af linjer på én gang, gør selv erfarne udviklere det ikke længere. Det betyder at forstå den grundlæggende logik og kunne begrunde, hvorfor koden gør præcis, hvad den gør. Hvis du kan, er det lige meget, om en model skrev den eller du gjorde: det er ikke vibe coding, det er at bruge et værktøj til at bygge software.

Forskning offentliggjort i december 2025 understøtter den skelnen. På baggrund af feltobservationer og en kvalitativ undersøgelse af professionelle udviklere fandt forskerne, at erfarne praktikere beholdt kontrollen over softwaredesign og implementering i stedet for at overlade hele processen til AI. De behandlede agenter som samarbejdspartnere, planlagde deres arbejde omhyggeligt og forblev involveret i tilsynet.

Så erfaring alene forklarer det ikke. Det handler om, hvorvidt du er villig til at påtage dig ansvaret for, hvad AI har genereret. Det er en beslutning, hver udvikler træffer igen og igen på hvert projekt.

Hvad sker der, når kontrol mangler

Konsekvenserne af at frigive software uden at forstå eller verificere sikkerheden er ikke abstrakte. Tea, en app designet til at hjælpe kvinder med at føle sig trygge, mens de dater, eksponerede titusinder af ID‑fotos og mere end en million private beskeder i to sikkerhedshændelser. Fejlene omfattede en usikret lagrings‑bucket og en separat database, der var tilgængelig uden godkendelse.

Det samme underliggende problem – software, der så ud til at fungere, mens autorisationslogikken var farligt forkert – viste sig i en applikation bygget på Lovable‑platformen: sikkerhedsforskning fandt, at autorisationslogikken var omvendt, hvilket låste loggede brugere ude, mens uautoriserede angribere frit kom ind, og påvirkede mere end 18.000 brugere, herunder studerende.

Dette er ikke isolerede tilfælde, der kun rammer “dårlige” projekter. Ifølge Googles DORA‑rapport fra 2025 bruger 90 % af udviklerne nu AI på arbejdet, mens omkring en tredjedel rapporterer lidt eller ingen tillid til, hvad den genererer.

AI‑brug er nu udbredt, selvom tilliden forbliver begrænset. Og det gør omhyggelig gennemgang ekstra vigtig, når genereret kode håndterer godkendelse, tilladelser eller følsomme data.

Kontrol er bygget i lag, ikke på én gang

I mit tilfælde startede jeg ikke med en formel sikkerhedsrevision. Jeg nægtede simpelthen at gå videre, hver gang jeg ikke kunne forklare, hvorfor noget opførte sig, som det gjorde – en naturlig instinkt, jeg bringer med som analytiker. Jeg bekymrer mig mindre om syntaksen end om resultatet matcher, hvad vi oprindeligt havde brug for. Når det ikke gør, graver jeg videre.

Min arbejdsproces blev mere struktureret, efterhånden som projekterne blev mere seriøse. I stedet for kun at stole på prompts, begyndte jeg at udarbejde specifikationer, før jeg genererede noget. Jeg dokumenterede forretningskravene, teknologistakken og integrationerne. Derefter fulgte enhedstests og Playwright‑tests for de vigtigste brugerrejser.

Sikkerhedstjek blev tilføjet på samme måde. Jeg gennemgik de biblioteker, AI’en valgte, og indførte malware‑scanning af uploadede filer. Hvert tjek kom fra at spørge, hvad der kunne gå galt næste gang, snarere end at følge en kontrol‑liste, jeg havde udarbejdet i starten.

Den vane opdagede et problem i et projekt. AI’en introducerede et bibliotek, der var inkompatibelt med den framework‑version, jeg brugte. Applikationen fejlede ikke direkte, så inkompatibiliteten kunne let have forblevet ubemærket. At finde det senere ville have gjort årsagen meget sværere at identificere.

Sammenlignet med Tea‑ og Lovable‑sagerne var dette et almindeligt problem. Jeg fandt det tidligt, rettede det og gik videre. Det er, hvordan gennemgang typisk ser ud i praksis. For det meste forhindrer det små problemer i at vokse til større.

Jeg mistroer ikke kode blot fordi AI har produceret den. Jeg stoler heller ikke på den blot fordi applikationen kører. Tests og gennemgang er, hvordan jeg fastslår, om den opfører sig som tilsigtet.

Fra Vibe Coding til Agentic Engineering

Karpthys egen bevægelse væk fra “vibe coding” mod “agentic engineering” er ikke kun et skift i ordforråd. “Agentic engineering” giver os et mere brugbart navn for den retning, professionel udvikling tager. Udviklere kan skrive færre linjer selv, men det reducerer ikke deres ansvar. Det flytter deres arbejde mod at specificere, hvad systemet skal gøre, styre agenter, teste deres output og beslutte, hvad der er sikkert at udgive.

Faren er ikke, at AI genererer kode hurtigt. Det er, at genereringen kan bevæge sig hurtigere end forståelsen. Når det sker, skjuler tilsyneladende produktivitet risici, som ingen har undersøgt ordentligt.

En regel, der er værd at holde fast i

Stop med at bruge “vibe coding” som en betegnelse for enhver form for AI‑assisteret udvikling – det udvander udtrykket og udvisker en skelnen i kontrol, der betyder noget. Sæt en simpel regel: udgiv ikke noget, du ikke kan forklare. Og byg kontrol ind i projektet, efterhånden som det vokser, lag for lag, og tilføj tjek i takt med de risici, der opstår.

AI kan skrive størstedelen af koden. Den kan ikke påtage sig ansvaret for at udgive den. Det ansvar ligger stadig hos os.