Vad är vibe coding? Definition, hur det fungerar – och kapitlet som guiderna hoppar över

Varje vibe coding-verktyg, oavsett vad marknadsföringen säger, kör en version av samma loop: beskriv → generera → kör → reagera. Du skriver ”en att göra-lista sorterad på deadline”; agenten planerar ändringen, skriver koden i alla filer som behövs, bygger projektet, ser samma fel som en programmerare skulle se, rättar dem och visar dig ett fungerande resultat. Nästa mening – ”försenade uppgifter ska vara röda” – kör loopen igen ovanpå allt som redan finns.

Tre saker på insidan avgör om loopen producerar något bra, och de är värda att känna till eftersom de förklarar varje kvalitetsskillnad mellan verktyg:

Kontext. Agenten kan bara respektera det den ser – dina tidigare beslut, den befintliga koden, designsystemet. Verktygen skiljer sig enormt i hur mycket de minns och hur de väljer vad de tittar på.

Struktur. Be om funktioner en i taget utan plan, och agenten improviserar en arkitektur per prompt – bra för en demo, dåligt på ett sätt som ackumuleras fram till funktion tjugo. Verktyg som bestämmer strukturen i förväg (eller låter dig bestämma den) producerar kod som förblir användbar.

Verifiering. De bästa verktygen levererar inte kod som borde fungera: de bygger den, kör den, testar den och rättar sina egna fel innan du ser något. Skillnaden mellan ”genererar kod” och ”levererar mjukvara” sitter nästan helt här. Till och med Apple har byggt in agenter i Xcode som itererar mellan bygge och rättning.

Lägg märke till vad som saknas i listan: din förmåga att programmera. Det loopen faktiskt förbrukar är din förmåga att beskriva exakt och reagera ärligt – och det är därför produktfolk tog till sig det snabbare än någon annan. Att skriva ner vad som ska finnas, scenario för scenario, var redan deras jobb.

Klarar, i dag: att gå från idé till fungerande mjukvara på en sittning; att iterera billigt (det ”försök igen” som kostade en utvecklares eftermiddag kostar nu en mening); standardytorna i en produkt – skärmar, formulär, listor, konton, betalningar mot färdiga backends; och att låta personen med produktomdöme bygga direkt i stället för att skicka budskapet genom lager.

Brister fortfarande, ärligt: arbete utan en beskrivbar specifikation (om du inte kan säga hur ”rätt” ser ut kan agenten inte heller veta det); genuint nya algoritmer och ovanlig systemprogrammering; att rädda en stor, gammal kodbas som den inte själv byggt; och att kompensera för avsaknad av produkttänk – en agent förstärker beslutskvaliteten åt båda hållen.

Och ett sätt att misslyckas ligger hos användaren, inte verktygen: att förväxla en demo med en produkt. Vilket verktyg som helst på den här sidan ger dig en imponerande demo på en eftermiddag. En produkt behöver dessutom en struktur som överlever funktion tjugo, konton som fungerar, data som stannar kvar, uppdateringar som går ut och kod som är din. Verktygen skiljer sig betydligt mer i den andra halvan än i demohastighet – och det tar oss till kartan.

De flesta listor sorterar efter hastighet och finish. Sortera i stället efter resultat – vad det du beskriver faktiskt blir – och hela marknaden delar sig i fem grupper. (Inga priser här: de ändras, och varje verktyg publicerar sina egna. Frågan att ställa är alltid densamma: i vilken plan kan jag publicera och ta med mig koden?)

Webbyggare – resultat: webbapp. Lovable, från Stockholm, är referensen: appar i React, GitHub-synk, backend på Supabase; dess egen dokumentation säger att ”Lovable does not generate React Native projects”. v0 från Vercel och Bolt spelar samma match. För webbprodukter publicerar de på riktigt; för att prototypa vad som helst är de utmärkta.

Prototypverktyg – resultat: klickbara demor som slängs. Figma Make lever i designekosystemet och är ärligt med vad det är: gjort för att utforska, inte för att publicera.

Kodagenter med din egen AI – resultat: det du lyckas styra fram. Claude Code, Cline, Aider: agenter som arbetar i en riktig kodbas med din prenumeration eller din API-nyckel. Maximal frihet, inga räcken – utmärkt för utvecklare, och den väg där produktfolk mest behöver den struktur som nästa grupp bygger in.

Mobilbyggare – resultat: mobilapp, med en förgrening inuti gruppen som nästan ingen lista nämner. Vibecode, Newly och Bolt med Expo genererar React Native/Expo – plattformsoberoende JavaScript som körs på telefonen genom en brygga, med samma skärmar på båda systemen. FlutterFlow sätter ihop Flutter-appar visuellt. Rork gick 2026 över till native-kod – Swift för iPhone, Kotlin för Android – som två separata appar i ett projekt: enligt dess egna docs ”each app has its own code”. Och Modaal (vårt) genererar riktig native-kod för varje plattform – Swift/SwiftUI för iPhone, Kotlin/Jetpack Compose för Android – från ett enda projekt, med varje funktions logik skriven en gång och en native-skärm per plattform, med en plan du godkänner före varje funktion, koden på din Mac och obegränsat antal prompts i gratisplanen. Varför förgreningen spelar roll är nästa kapitel – för det är den del av vibe coding som guiderna fortsätter att hoppa över. (Tio byggare, sorterade efter vad de producerar, finns i vår jämförelse på engelska.)

Det här är den märkliga luckan i alla vibe coding-guider som publicerats hittills, på svenska som på engelska: de förklarar loopen, listar verktygen, visar en webbdemo – och stannar vid telefonen. ”För mobil” dyker upp, om alls, som ”din webbapp fungerar också i telefonens webbläsare”. För den som har en produkt som hör hemma på en telefons hemskärm döljer den meningen de tre fakta som betyder mest:

1. En webbplats i telefonen är inte en app. Push-notiser, offline-läge, kamera och sensorer, widgets, klocka och köp inuti butikerna hör till riktiga appar. Snabbtestet: kommer dina användare genom att trycka på en länk eller genom att öppna en ikon? Hela jämförelsen finns i vår guide på engelska.

2. Att paketera din vibe-kodade webbapp tar dig inte över klyftan. Den uppenbara genvägen – att lägga webbappen i ett skal som ser ut som en app – krockar med Apples granskning, som regelbundet avvisar tunna skal runt en webbplats, och med alla begränsningarna ovan, eftersom appen fortfarande är en förklädd webbplats.

3. Klyftan korsas nu med samma färdighet. Det här är vad som ändrats och vad guiderna ännu inte fångat: loopen beskriv-och-iterera producerar nu riktig native-kod. I Modaals version är loopen medvetet mer strukturerad än webb-vibe coding – ett produktdokument när projektet startar och, för varje funktion, skriver agenten först en plan du kan läsa (scenarier, angreppssätt, risker, tester) och bygger först efter att du godkänt den; resultatet är Swift och Kotlin som en plattformsutvecklare känner igen, byggt och testat, på din Mac. Vibe coding med improvisationen utbytt mot specifikationer – exakt den korrigering som gör ett produktionsresultat möjligt.

Den praktiska konsekvensen: webbvägen och mobilvägen börjar nu likadant – med en beskrivning – och behöver inte längre sluta med en omskrivning. Validerade du något i Lovable som visade sig vara en app? Backend överlever oftast flytten; framsidan blir en riktig native-app, beskriven på samma språk som prototypen. Och om produkten ska till båda butikerna skrivs logiken en gång och varje plattform får sin egen native-skärm – utan att något byggs om för Android.

Uppfarten på en sittning, i den ordning som undviker de klassiska misstagen:

1. Välj något riktigt men litet. Inte företagets flaggskeppsprodukt – ett verktyg du själv vill ha. Lärandet sitter i loopen, och små saker snurrar fortare.

2. Skriv fem meningar innan du rör något verktyg. Vad den gör; tre scenarier ”användaren gör X, ser Y”; vad den första versionen medvetet lämnar utanför. Det är skillnaden mellan att styra och att driva – och det är vanan som senare skalar hela vägen till produktion.

3. Välj verktyg efter resultatet, inte efter demon. Webbprodukt → webbyggare. Mobilprodukt → verktyg med mobilt resultat (och välj medvetet mellan native och plattformsoberoende). Bara utforskar → vilket som helst, utan dåligt samvete.

4. Reagera exakt. ”Fel” lär agenten ingenting; ”knappen ska ner, där tummen når” rättar det i ett steg. Ge agenten instruktioner som du skulle ge en mycket bokstavlig och mycket snabb utvecklare – en färdighet produktfolk redan har.

5. Iterera tidigt på en riktig telefon, om produkten är mobil – simulatorn är artig, tummen är ärlig.

Att börja kostar inget som spelar roll: webbyggarna har gratisplaner, och Modaals gratisplan är ett helt projekt med obegränsat antal prompts; Pro kostar 9 € per månad vid årsbetalning – detaljerna finns på prissidan. Vad det faktiskt kostar att göra en app, väg för väg och med varje siffra verifierbar, finns i vad kostar det att göra en app. Den knappa resursen är den vanliga – att veta vad som ska byggas. Verktygen har bara slutat dölja det.