Vibe coding innebär att man skriver mjukvara genom att beskriva vad man vill ha på naturligt språk och accepterar vad modellen producerar, med liten eller ingen granskning av den underliggande koden. Utvecklaren styr på känsla snarare än genom att läsa och resonera om resultatet.
Var termen kommer ifrån
Andrej Karpathy myntade begreppet i början av 2025 för att beskriva ett arbetssätt där man "fully give in to the vibes" och slutar oroa sig för koden i sig. Avsikten var delvis beskrivande, delvis ironisk. Det fastnade eftersom det satte namn på något som redan pågick.
Hur det ser ut i praktiken
En utvecklare promptar en modell, kör det som returneras, beskriver felet om något går sönder och itererar. Ingen granskning av diff:en. Inget frågande om varför modellen gjort ett visst val. Koden behandlas som en ogenomskinlig artefakt. Det fungerar tills det inte gör det.
Detta skiljer sig från agentic coding, där en kodningsagent utför åtgärder i flera steg inuti en kodbas och en människa ändå granskar resultatet. Vibe coding handlar om avsaknaden av den granskningen, inte om förekomsten av automatisering.
Varför det ger prototyper snabbt
För ett proof of concept som ska kastas är metoden riktigt snabb. Modellen tar hand om boilerplate, sammankoppling och den uppenbara strukturen. Människan kan helt fokusera på om lösningen beter sig som beskrivet. Återkopplingsloopen är kort.
För det användningsfallet är avvägningen ofta värd det.
Varför prototypen sällan överlever mötet med produktion
Problem ackumuleras i de delar som inte granskades.
Säkerhet. Modeller reproducerar vanliga mönster, inklusive vanliga sårbarheter. Om du inte har läst koden vet du inte om indata valideras, om hemligheter hanteras korrekt eller om åtkomstkontroller finns. Prompt injection är en specifik risk; det finns många andra.
Underhållbarhet. Kod som ingen förstod när den skrevs är svår att ändra senare. Nästa utvecklare, eller samma utvecklare tre månader senare, har ingen mental modell att utgå från.
Korrekthet i kantfall. Modeller är självsäkra. De producerar kod som ser rätt ut och hanterar det uppenbara fallet. Kantfall, domänspecifika begränsningar och interaktioner mellan komponenter är där felen gömmer sig. Det är just de saker som inte syns i en snabb demo.
Felsökning. När något går sönder i produktion behöver du resonera om koden. Om du aldrig läst den har du inget att resonera utifrån.
Övergångsproblemet
Att flytta en vibe-kodad prototyp till produktion handlar inte om att "städa upp den". Det innebär vanligtvis att läsa varje rad, förstå vad den faktiskt gör snarare än vad du avsåg, hitta de ställen där modellen gjort ett trovärdigt men felaktigt val, och bestämma vad som ska skrivas om. I praktiken tar det ofta längre tid än att skriva det ordentligt från början.
Detta är ingen kritik mot att använda AI för att påskynda utveckling. Det är en beskrivning av vad granskningsfri generering kostar dig senare.
Hur kompetent AI-native-utveckling ser ut istället
En senior utvecklare som använder AI-verktyg väl läser ändå resultatet. De behandlar genererad kod som ett kompetent första utkast, inte en färdig produkt. De fångar de ställen där modellen var säker och fel. De förstår det kontextfönster modellen arbetade utifrån och var den kan ha spårat ur.
Det är en annan färdighet än antingen vibe coding eller traditionellt rad-för-rad-författarskap. Det är också den färdighet som gör AI-assisterad utveckling säker att ställa inför användare. Se hur man granskar AI-genererad kod för vad den processen innebär.
Vad vi testar
Vibe coding-beteende är precis vad vår granskning är utformad för att synliggöra. I AI-native-bedömningen arbetar kandidaterna igenom uppgifter med de verktyg de normalt använder, och vi observerar om de läser det som kommer tillbaka. De bedömningskriterier som är mest direkt relevanta är verifiering av AI-resultat, som testar om någon fångar hallucinerade API:er eller subtilt felaktig logik innan den driftsätts, och riskbaserat omdöme, som testar om genererad kod får samma granskning oavsett hur säker verktyget låter. Fullständig information finns under hur vi granskar.
Korta svar
Är vibe coding alltid dålig praxis?
Inte alltid. För en tillfällig prototyp eller ett personligt skript du aldrig avser att underhålla är avvägningarna rimliga. Problemet är att behandla vibe-kodad produktion som produktionsklar utan det granskningssteg som skulle göra den det.
Hur omvandlar jag en vibe-kodad prototyp till produktionskod?
Läs varje rad med samma noggrannhet du skulle tillämpa på kod från en okänd källa. Kontrollera säkerhetsantaganden, kantfall och underhållbarhet. Räkna med att skriva om betydande delar. Det är sällan en snabb poleringsinsats.
Vad är skillnaden mellan vibe coding och att använda AI-kodningsverktyg?
Skillnaden är granskning. Att använda AI-verktyg väl innebär att läsa och resonera om resultatet. Vibe coding innebär att acceptera det på känsla. Verktygen kan vara identiska; beteendet och resultaten skiljer sig väsentligt.
