När vi skrev om vibe coding i september var det som en snabb introduktion. Nu har ett kvartal gått. Vi har byggt mer, vi har fastnat mer, och vi har hunnit jämföra två av de vanligaste verktygen, Lovable och Google AI Studio, ordentligt.
Det här inlägget handlar inte om att hitta ett “bästa verktyg”. Det handlar om att testa vibe coding på ett sätt som ger dig ett tydligt svar. Funkar det för oss, i vår verklighet, med vår tid, vår designnivå, våra krav och vår risknivå. Vi delar hur vi satte upp testet, vad vi mätte, vad som överraskade oss, och vad som ofta gör att testet blir missvisande.
Den vanligaste fällan är att man börjar i verktyget. Man öppnar Lovable eller AI Studio och tänker att man ska “se vad som händer”. Det känns snabbt och produktivt, tills man inser att man inte kan avgöra om det var bra eller bara snabbt.
Vi började med två frågor som styrde allt vi gjorde. För det första, vart börjar vi för att få en fungerande version fort, utan att slarva bort tiden. För det andra, när är vibe coding ett bra sätt att bygga, och när är det fel väg. Det gjorde att vi kunde säga nej till mycket. Och det gjorde att vi kunde jämföra verktygen på riktigt.
Vi tycker att ett bra testprojekt har tre egenskaper. Det ska vara tydligt vad “klart” betyder. Det ska ha begränsad risk, så att misstag inte blir dyra. Och det ska vara tillräckligt verkligt, så att du inte bara testar en snygg demo.
Ett exempel är en enkel intern app där man kan lägga in och visa data, filtrera, och ha ett flöde med två till tre vyer. Det räcker för att testa design, struktur, iteration och kvalitet, men det är inte så stort att du drunknar i detaljer. Om du väljer något som är för stort kommer du inte testa vibe coding. Du kommer testa din egen uthållighet.
Vi märkte tidigt att det är lätt att lura sig själv. Man får en första version och tänker att det går fort. Sen börjar man peta, och plötsligt har man lagt två kvällar på att få något som känns någorlunda stabilt.
Så vi bestämde oss för att följa några enkla saker genom hela testet. Vi mätte tid till första fungerande version. Vi tittade på hur lätt det var att styra designen till vår kravnivå, inte bara få något som fungerar. Vi tittade på kodens struktur, om den gick att förstå dagen efter. Vi tittade på hur lätt det var att göra ändringar utan att allt gick sönder. Och vi tittade på integrationer, för det är där många projekt blir skarpa på riktigt.
En viktig insikt var att utfallet sällan blir hundra procent. I våra tester hamnade vi ofta på något som kändes som 50 till 70 procent av vad vi ville ha, och resten blev styrning, justering och ibland omskrivning. Det är fortfarande värt mycket, men det är bra att veta innan man lovar något internt.
Det här är den tråkiga delen som gör allt annat roligare.
För det första beskrev vi projektet ordentligt. Inte en rad utan flera sidor om syfte, målgrupp, tänkta vyer och dataflöden. När vi slarvade med detta blev resultatet mer slumpmässigt och vi fick lägga tid på att rädda en riktning i efterhand.
För det andra bestämde vi designspår. Här har vi två lägen. Antingen tar man fram en designtanke med referenser, skisser eller exempel. Då kan man styra mot ett konsekvent uttryck. Eller så kör man “random design” och låter verktyget hitta på. Det kan bli bra, men det är lika ofta skit, och man vet inte varför det blev som det blev. Det här blev extra tydligt när vi jämförde verktygen.
Lovable kändes direkt som en produkt byggd för att komma igång. Vinsten i ett test är att du snabbt får något att reagera på. För många är det exakt det man behöver i början.
Google AI Studio var annorlunda. Första mötet skapade mycket frustration för oss. Designresultatet var, helt ärligt, extremt dåligt i början. Men när vi ändrade arbetssätt, och när vi började vara mycket mer exakta, vände det. Efter 6 till 10 timmars justeringar upplevde vi att Studio kunde bli potentiellt bättre, särskilt om man vill bygga prototyper som använder AI, Google Search och Googles egna tjänster.
En stor skillnad är att Studio inte har en chatt på samma sätt. Det gör att man ofta behöver en AI bredvid. Vi har till exempel promptat i Gemini, gjort prompten kopierbar och tydlig, och sedan använt den i Studio. Det låter omständligt, men för oss blev det ett sätt att få upp kvaliteten.
När det gäller design var vår upplevelse att Lovable oftare tolkar bilder och designunderlag bättre direkt till kod. Studio kräver mer styrning. Det är inget fel, men man behöver veta det, annars tror man att verktyget är sämre än det är.
En annan skillnad är att Studio belönar en systeminstruktion, alltså en grund som modellen alltid förhåller sig till. Hur den ska tänka, strukturera kod, tolka instruktioner. Samma typ av ram går att använda i Lovable, men där är den inte lika kritisk för att komma igång.
Den första missen är att göra stora ändringar. Stora ändringar leder ofta till att AI skriver om hela filer och förstör tidigare arbete. Vi fick bäst resultat när vi gick i små steg, en ändring i taget, och vi upprepade alltid instruktionen “ändra inget annat”.
Den andra missen är att låta design vara en eftertanke. Om du inte bestämmer designriktning blir det lätt generiskt och spretigt. Då tror du att verktyget är dåligt, fast det egentligen är din input som är för lös.
Den tredje missen är att underskatta tid. Många tror att det här är en tvåtimmarsgrej. I verkligheten är 50 till 100 timmar inte ovanligt om du bygger något som ska användas, och varje timme kostar pengar i AI-användning. Det blir också snabbt komplext när man kommer in på databaser, versionhantering, domän, och allt runt omkring.
Vi landade i en praktisk tumregel.
Och om du vill göra ett ärligt test, mät inte bara hur snabbt du fick en skärm. Mät också hur stabilt det blir efter tio ändringar.
Vibe coding är kraftfullt, men det är inte magi. Vår största lärdom efter att ha hårdtestat är att resultatet beror lika mycket på hur vi jobbar som vilket verktyg vi väljer.
Avgränsa, skriv ner vad ni bygger, bestäm designriktning, iterera smått. Då får ni ett svar som går att fatta beslut på. AI kan upplevas magiskt, men principen skit in, skit ut gäller fortsättningsvis också.
I nästa inlägg går vi från test till vardag. Då handlar det om långsiktig hållbarhet, större projekt, säkerhet, och hur man tar sig från test till live utan att det spårar ur.