Der er et nyt fænomen i tech-branchen. Det hedder vibe coding, og det har fået en hel generation af projektledere, iværksættere og karriereskiftere til at tro, at de nu er softwareudviklere. Spoiler: Det er de ikke.
For os, der har været i branchen længe nok til at huske Dreamweaver-æraen, føles det bekendt. Dengang var det også pludselig muligt for alle at "lave hjemmesider" uden at forstå HTML. Resultatet var millioner af uvedligeholdbare monstre med nested tables, inline styles og blinkende GIF'er. Vi ryddede op i årevis. Nu gentager historien sig, bare med mere avanceret teknologi og betydeligt højere indsatser.
Lad mig slå fast med det samme, før de vrede kommentarer begynder at tikke ind: Jeg elsker AI-assisteret udvikling. Jeg bruger det dagligt. Intensivt. Nærmest intimt. Min VS Code er så integreret med Claude og Copilot, at jeg nogle gange glemmer, hvem af os der egentlig skriver koden. Men der er en afgørende forskel på at bruge AI som et professionelt værktøj og at bruge det som en magisk tryllestav, der forvandler uvidenhed til fungerende software.
Velkommen til æraen af prompt-drevet selvbedrag
Vibe coding, for de uindviede, er kunsten at beskrive, hvad man vil have til en AI, acceptere det første output, og så erklære sig selv for færdig. Det er programmering reduceret til ønsketænkning. Det er som at bestille en burger på en restaurant og derefter kalde sig selv for kok.
Og det virker. I starten. Det er det forfærdelige ved det.
Du prompter: "Lav mig en login-side med React og Firebase." Og voilà, du har en login-side. Den compiler. Den kører. Du kan logge ind. Du poster et screenshot på LinkedIn med teksten "Day 1 of my coding journey 🚀" og høster likes fra andre mennesker, der også lige har opdaget, at de kan få en AI til at skrive kode for dem.
Men hvad du ikke ved, fordi du ikke har den tekniske baggrund til at vurdere det, er at din nyfødte login-side:
- Gemmer passwords i plain text i localStorage
- Har tre forskellige race conditions
- Bruger et deprecated Firebase SDK fra 2019
- Har en SQL injection-sårbarhed, selvom du ikke engang bruger SQL (ja, det er muligt, og nej, jeg vil ikke forklare hvordan)
- Er struktureret på en måde, der får erfarne udviklere til at græde stille i deres kaffe
Men hey, den virker. Og det er jo det, der tæller. Ikke?
"Det virker" er ikke det samme som "det er færdigt"
Her er den ubehagelige sandhed, som ingen på Twitter vil fortælle dig: At kode compiler og kører er det absolutte minimum. Det er ikke et kvalitetsstempel. Det er startlinjen. Ikke målstregen.
Forestil dig en bro. Du kan bygge en bro, der holder én bil, én gang, under perfekte vejrforhold, hvis chaufføren ikke vejer for meget, og hvis ingen kigger for længe på den. Teknisk set er det en bro. Den "virker". Men ville du køre over den hver dag? Ville du lade din familie køre over den?
Det samme gælder software. Produktionsklar kode skal håndtere edge cases, fejltilstande, concurrent users, uventede inputs, netværksfejl, timeout-scenarier, og en million andre ting, som din venlige AI-assistent ikke tænkte på, fordi du ikke spurgte, og fordi du ikke vidste, at du burde spørge.
Vibe coding er som at bygge et hus ved at bede nogen beskrive, hvordan et hus ser ud. Du får vægge og et tag. Men du får ikke fundament, isolering, kloakering eller elektriske installationer, der overholder bygningsreglementet. Og når det regner, finder du ud af forskellen.
Den usynlige regning: Teknisk gæld med ågerrenter
Her kommer den del, hvor jeg skal tale til jer, der ansætter folk, og til jer, der tror, at I lige har sparet 500.000 kroner ved at lade praktikanten vibe code jeres MVP.
Teknisk gæld er et begreb, vi bruger til at beskrive den pris, man betaler senere for genveje, man tager nu. Og vibe coding uden teknisk forståelse er ikke bare en genvej. Det er at optage et lån hos en lånehaj, der opkræver 40% i rente, betales i udviklertimer, frustration og forsinkede releases.
Jeg har set det igen og igen. Et startup launcher med en "fungerende" prototype, bygget af en founder, der lærte at prompte sig til en app på en weekend. Seks måneder senere hyrer de rigtige udviklere til at "bare lige tilføje et par features." De rigtige udviklere kigger på kodebasen. Der er en lang, tung stilhed. Nogen forlader lokalet. Nogen begynder at drikke.
Det, der skulle tage to uger, tager fire måneder. Ikke fordi de nye udviklere er inkompetente, men fordi de først skal arkæologisk udgrave, hvad den originale kode overhovedet prøver at gøre, og derefter genopbygge det fra grunden, mens de samtidig holder den eksisterende funktionalitet kørende.
Dette er ikke et hypotetisk scenarie. Dette er tirsdagen i branchen. Hver uge arver dygtige udviklere kodeproblemer, de ikke selv har skabt, og bruger deres arbejdstid på at rydde op efter folk, der troede, at de kunne prompte sig ud af at forstå, hvad de lavede.
De usynlige ofre: Udviklerne bag oprydningen
Lad os tale om dem, der betaler prisen for vibe coding uden ansvar. Det er ikke de mennesker, der producerer den tvivlsomme kode. De er for længst videre til næste projekt, næste startup, næste LinkedIn-post om, hvordan AI revolutionerer deres produktivitet.
Nej, prisen betales af de udviklere, der arver rodet. De får en kodebase, der ligner resultatet af, at nogen har bedt en AI om at løse problemer, som personen ikke selv forstod. Og det kan man se. Der er ingen sammenhæng. Ingen arkitektur. Ingen konventioner. Bare lag på lag af genererede løsninger, stablet oven på hinanden som et digitalt Jenga-tårn, der venter på at vælte.
Disse udviklere skal nu:
- Forstå kode, der ikke følger nogen genkendelig logik
- Debugge problemer i systemer uden dokumentation
- Tilføje features til en arkitektur, der ikke var designet til at udvides
- Forklare ledelsen, hvorfor "bare en lille ændring" tager tre uger
- Gøre alt dette uden at få lov til at smide det hele ud og starte forfra
Det er som at blive bedt om at renovere et hus, mens familien stadig bor i det, og mens huset aktivt er ved at falde sammen, og mens nogen konstant spørger, hvorfor du ikke bare "fikser taget hurtigt."
Udbrændthed i tech-branchen er et reelt problem. Og en del af det problem er, at dygtige mennesker bruger deres energi på at kompensere for andre menneskers uansvarlige brug af værktøjer, de ikke forstår.
Min egen praksis: At danse med AI uden at træde sig selv over tæerne
Nu skal jeg være ærlig om min egen brug af AI i udvikling, for jeg vil ikke fremstå som en hykler, der fordømmer værktøjer, jeg selv bruger dagligt.
Jeg vibe coder. Hele tiden. Men jeg gør det med åbne øjne og med årtiers erfaring i bagagen.
Her er forskellen: Når AI genererer kode for mig, er jeg dens code reviewer. Jeg læser hver linje. Jeg stiller spørgsmål. Jeg refaktorerer. Jeg forkaster. Jeg beder om alternativer. Jeg integrerer det i en arkitektur, jeg forstår og kan forsvare.
Samtidig bruger jeg AI som min code reviewer. Jeg beder den gennemgå min egen kode for fejl, sikkerhedshuller, performance-problemer og stilistiske inkonsistenser. Det er et samarbejde, ikke en outsourcing.
Mit ansvar forsvinder ikke, fordi en AI har skrevet koden. Arkitekturen er stadig mit ansvar. Sikkerheden er stadig mit ansvar. Performance er stadig mit ansvar. Vedligeholdelse på lang sigt er stadig mit ansvar. AI er et ekstremt kraftfuldt værktøj, der gør mig hurtigere og mere effektiv. Men værktøjet tager ikke ansvar. Det gør jeg.
Det er som forskellen på at bruge en elektrisk sav som uddannet tømrer versus at bruge den som total amatør. Begge kan skære træ. Kun den ene ved, hvad der sker, når noget går galt.
Den farlige forveksling: Værktøj versus kompetence
Der er en bredere tendens her, som rækker ud over vibe coding. Vi ser det i no-code-platforme. Vi ser det i low-code-løsninger. Vi ser det i hver eneste "byg en app uden at skrive en linje kode"-reklame.
Disse værktøjer er ikke problemet. Problemet er den implicitte påstand om, at værktøjet erstatter kompetencen.
En god lommeregner gør dig ikke til matematiker. En stavekontrol gør dig ikke til forfatter. Og en AI, der kan generere kode, gør dig ikke til udvikler. Disse værktøjer forstærker eksisterende kompetencer. De skaber dem ikke.
Det betyder ikke, at værktøjerne er ubrugelige for nybegyndere. Tværtimod. AI kan være en fantastisk lærer, en tålmodig forklarer, en uudtømmelig kilde til eksempler og vejledning. Men læring kræver, at man faktisk prøver at forstå, ikke bare at man copy-paster og går videre.
Hvis du bruger AI til at lære, er du på rette vej. Hvis du bruger AI til at undgå at lære, bygger du på sand.
Hvem bærer ansvaret?
Dette er et legitimt spørgsmål, og svaret er ubehageligt for alle involverede.
AI-virksomhederne bærer noget af ansvaret. Markedsføringen lover ofte mere, end værktøjerne kan levere, og nedtoner de nødvendige kompetencer for at bruge dem ansvarligt.
Beslutningstagerne bærer noget af ansvaret. Når man hyrer folk til at "vibe code" kritisk infrastruktur, fordi det er billigere end at ansætte rigtige udviklere, har man truffet et valg med konsekvenser.
Men primært bærer de enkelte mennesker ansvaret for deres egne valg. Hvis du ved, at du ikke forstår den kode, du producerer, og du alligevel deployer den til produktion, har du truffet en uetisk beslutning. Ikke fordi AI er farligt, men fordi du har valgt at ignorere din egen uvidenhed.
En konstruktiv vej fremad
Jeg vil ikke slutte med ren kritik, for det tjener ingen. Her er, hvad jeg faktisk anbefaler:
Hvis du er ny til udvikling og tiltrukket af vibe coding: Fantastisk. Brug det. Men brug det til at lære, ikke til at undgå at lære. Bed AI om at forklare den kode, den genererer. Stil dumme spørgsmål. Prøv at ændre ting og se, hvad der går i stykker. Byg forståelse, ikke bare artefakter.
Hvis du er erfaren udvikler: Omfavn værktøjerne. De gør os hurtigere og bedre. Men husk, at dit ansvar ikke outsources. Du er stadig den voksne i rummet.
Hvis du er beslutningstager: Stop med at tro, at AI fjerner behovet for kompetence. Det forskyder det bare. I stedet for at spare på udviklerbudgettet, investér i folk, der ved, hvordan man bruger disse værktøjer ansvarligt.
Konklusionen, I kom for
Vibe coding er et kraftfuldt værktøj. I hænderne på udviklere med teknisk forståelse accelererer det arbejdet, forbedrer kvaliteten og åbner nye muligheder.
I hænderne på alle andre er det bare en ekstremt effektiv måde at producere fremtidige problemer på.
Og de problemer? Dem ender rigtige udviklere med at løse. Med overarbejde, frustration og en stille undren over, hvorfor nogen nogensinde syntes, at dette var en god idé.
Så næste gang du prompter dig til en "fungerende" løsning, stil dig selv ét spørgsmål: Forstår jeg, hvad denne kode gør? Kan jeg forsvare den? Kan jeg vedligeholde den? Kan jeg fejlfinde den, når den går galt?
Hvis svaret er nej, har du ikke bygget software. Du har bare udskudt problemet.
Og regningen kommer altid.
Jeg bruger selv AI-assisteret udvikling dagligt og anbefaler det varmt til alle, der ved, hvad de laver. Til alle andre anbefaler jeg at lære, hvad de laver, først.
