Vi måste sluta kalla allt för Vibe Coding

Jag återgick till kodning efter ett långt uppehåll, och Lovable var där jag började igen. Apparaten såg bra ut, fungerade vid första anblicken och satt ihop på några timmar. Till en början kändes det enastående. Men det räckte inte längre så snart jag ville veta vad koden gjorde – och varför. Det var då mitt tillvägagångssätt började förändras.

Skillnaden handlar inte om verktyget eller hur mycket av koden AI skriver åt dig. Det handlar om det avtal du accepterar med ditt resultat: om du kan förklara vad du just släppte ut i världen, eller inte.

Vibe coding, i dess ursprungliga betydelse, innebär att acceptera AI‑genererad mjukvara utan att ordentligt granska eller förstå vad som ligger under den. AI‑assisterad utveckling är annorlunda. Modellen kan fortfarande skriva största delen av koden, men den som bygger systemet förblir ansvarig för att förstå dess beteende, testa dess antaganden och avgöra om det är redo att levereras.

För ett engångsexperiment som aldrig lämnar din egen maskin kan skillnaden ha få konsekvenser. När mjukvaran väl har distribuerats, används av andra eller kopplas till verkliga data, blir den enormt viktig.

Hur “Vibe Coding” förlorade sin betydelse

Termen “vibe coding” myntades i februari 2025 av Andrej Karpathy, medgrundare av OpenAI. Hans exempel var avsiktligt avslappnat: ett “släng‑iväg‑helgprojekt” byggt genom att automatiskt klicka på “Accept All”, ignorera diffarna och låta koden växa bortom hans förståelse.

Veckor senare märkte utvecklaren och verktygsbyggaren Simon Willison att termen användes mycket annorlunda: som en ersättare för all AI‑assisterad programmering, vilket han menade urvattnar termen och ger ett falskt intryck av vad ansvarsfull AI‑assisterad utveckling kan åstadkomma.

Det som är slående är att Karpathy så småningom höll med. Ett år senare introducerade han en annan term för mer disciplinerad arbete med kodningsagenter. Han beskrev “agentic engineering” som ett arbetsflöde där utvecklare styr och övervakar agenter snarare än att bara acceptera vad de producerar. Skillnaden är viktig: professionell AI‑assisterad utveckling kräver planering, granskning och ansvar på sätt som avslappnad vibe coding inte gör.

Linjen är ansvar

Willisons regel är enkel, och den fungerar som ett test för alla: commit‑a inte kod som du inte kan förklara för någon annan. Det betyder inte att läsa varje enskild rad: när agenter genererar hundratals rader på en gång, gör inte ens erfarna utvecklare det längre. Det betyder att förstå den grundläggande logiken och kunna motivera varför koden gör exakt det den gör. Om du kan det spelar det ingen roll om en modell skrev den eller du gjorde: det är inte vibe coding, det är att använda ett verktyg för att bygga mjukvara.

Forskning publicerad i december 2025 stödjer den distinktionen. Genom att basera sig på fältobservationer och en kvalitativ enkät bland professionella utvecklare fann forskarna att erfarna praktiker behöll kontrollen över mjukvarudesign och implementering snarare än att överlämna hela processen till AI. De behandlade agenter som samarbetspartners, planerade sitt arbete noggrant och var fortsatt involverade i tillsyn.

Så, erfarenhet ensam förklarar det inte. Det handlar om huruvida du är villig att ta ansvar för vad AI genererat. Det är ett beslut som varje utvecklare måste fatta om och om igen för varje projekt.

Vad som händer när kontrollen saknas

Konsekvenserna av att släppa mjukvara utan att förstå eller verifiera dess säkerhet är inte abstrakta. Tea, en app som ska hjälpa kvinnor att hålla sig säkra när de dejtar, exponerade tiotusentals ID‑foton och mer än en miljon privata meddelanden i två säkerhetsincidenter. Felen inkluderade en osäker lagringsbucket och en separat databas som var åtkomlig utan autentisering.

Samma underliggande problem – mjukvara som verkade fungera medan dess auktoriseringslogik var farligt felaktig – dök upp i en applikation byggd på Lovable‑plattformen: säkerhetsforskning fann att auktoriseringslogiken var omvänd, vilket låste ute inloggade användare samtidigt som oautentiserade angripare släpptes in fritt, och påverkade mer än 18 000 användare, inklusive studenter.

Detta är inte isolerade fall som bara inträffar i “dåliga” projekt. Enligt Googles DORA‑rapport 2025 använder 90 % av utvecklarna nu AI i arbetet, medan ungefär en tredjedel rapporterar lite eller inget förtroende för vad den genererar.

AI‑användning är nu utbredd, även om förtroendet förblir begränsat. Det gör noggrann granskning särskilt viktig när genererad kod hanterar autentisering, behörigheter eller känslig data.

Kontroll byggs i lager, inte på en gång

I mitt fall började jag inte med en formell säkerhetsgranskning. Jag vägrade helt enkelt gå vidare när jag inte kunde förklara varför något beter sig som det gör – en naturlig instinkt jag tar med mig till jobbet som analytiker. Jag bryr mig mindre om syntaxen än om resultatet motsvarar det vi ursprungligen behövde. När det inte gör det fortsätter jag gräva.

Mitt arbetsflöde blev mer strukturerat när projekten blev mer seriösa. Istället för att förlita mig enbart på promptar började jag förbereda specifikationer innan jag genererade någonting. Jag dokumenterade affärskraven, teknikstacken och integrationerna. Därefter följde enhetstester och Playwright‑tester för de viktigaste användarresorna.

Säkerhetskontroller lades till på liknande sätt. Jag granskade de bibliotek AI:n valde och införde skannning efter skadlig kod för uppladdade filer. Varje kontroll kom från att fråga vad som kunde gå fel härnäst, snarare än att följa en kontrollista jag förberett i början.

Den vanan upptäckte ett problem i ett projekt. AI:n introducerade ett bibliotek som var inkompatibelt med den ramverkversion jag använde. Applikationen hade inte kraschat omedelbart, så inkompatibiliteten kunde lätt ha förblivit oupptäckt. Att hitta det senare hade gjort orsaken mycket svårare att identifiera.

Jämfört med Tea‑ och Lovable‑fallen var detta ett vanligt problem. Jag upptäckte det tidigt, åtgärdade det och gick vidare. Så ser granskning vanligtvis ut i praktiken. För det mesta förhindrar det att små problem växer till större.

Jag misstror inte kod bara för att AI har producerat den. Jag litar inte heller på den bara för att applikationen körs. Tester och granskning är hur jag fastställer om den beter sig som avsett.

Från Vibe Coding till Agentic Engineering

Karpthys eget avsteg från “vibe coding” till “agentic engineering” är inte bara ett förändrat vokabulär. “Agentic engineering” ger oss ett mer användbart namn för den riktning som professionell utveckling tar. Utvecklare kan skriva färre rader själva, men det minskar inte deras ansvar. Det flyttar deras arbete mot att specificera vad systemet ska göra, styra agenter, testa deras resultat och besluta vad som är säkert att släppa.

Farorna ligger inte i att AI genererar kod snabbt. Det är att genereringen kan gå snabbare än förståelsen. När det händer döljer den skenbara produktiviteten risker som ingen har granskat ordentligt.

En regel som är värd att behålla

Sluta använda “vibe coding” som en etikett för alla former av AI‑assisterad utveckling – det urvattnar termen och suddar ut en viktig kontrollskillnad. Sätt en enkel regel: släpp inte något du inte kan förklara. Och bygg in kontroll i projektet i takt med att det växer, lager för lager, och lägg till kontroller i takt med de risker som uppstår.

AI kan skriva största delen av koden. Den kan inte ta ansvar för att leverera den. Det ansvaret ligger fortfarande hos oss.