I förra inlägget skrev vi om hur vi hårdtestat vibe coding och jämför Lovable och Google AI Studio. Om du har kommit så långt att du faktiskt använder de här verktygen regelbundet har du kanske märkt att det uppstår nya problem. Det handlar inte längre om att lyckas få upp något som funkar, utan mer om hur man kan kan fortsätta bygga utan att det blir för rörigt, dyrt eller fullt av säkerhetshål.
Så vi delar här med oss av vår arbetsmodell. Den funkar lika bra i Lovable som i Google AI Studio. Skillnaden mellan dem är mest hur vi arbetar runt verktygen, inte vad de klarar av.
Varför det spårar ur när projektet blir på riktigt
När vibe coding går från hopp och lek till något som ska bli en konkret leverans har vi stött på tre vanliga saker som gör att våra projekt havererar.
Först och främst blir det inte alltid som den bild vi har i huvudet. Vi får mer än vi ber om eller inte alls det vi ber om. Ber vi om fem saker får vi tre okej, två skit, och ibland dessutom några nya knappar vi inte alls efterfrågat.
Sen så skapar AI:n monoliter. En fil blir enorm och oöverskådlig, och efter några dagar blir det segjobbat och det räcker en liten ändring för att hela filen ska skrivas om. Man ber om något litet och får tillbaka 2000 rader som ser ungefär rätt ut, men där en massa saker har ändrats lite här och där. Ibland upptäcker man först senare vad som ändrats.
Till sist så kan det kännas skakigt säkerhetsmässigt inför lansering. Kod, nycklar och lösenord kan ligga öppet som default. Det är kanske den största fällan när man går från intern prototyp till något som andra ska använda och kan vara lite risky eller mycket risky beroende på vilken information som ligger öppen.
Vårt arbetssätt för större projekt
Vi jobbar med några specifika grejer för att undvika de här tre sakerna och för att hålla kaoset på armlängds avstånd. När vi fuskat har det alltid kommit tillbaka och bitit oss i häcken senare, och blivit dyrare och jobbigare att lösa.
Börja med en spec som är längre än tre rader
Tre rader inledande beskrivning räcker när det bara ska vara en kul grej. Ska det du bygger användas på riktigt behöver du beskriva projektet tydligt med flera sidor dokumentation.
Vi skriver ner syfte, användare, flöde, och vad som uttryckligen inte ingår. Det är också här vi bestämmer vad som ska vara frontend och vad som måste ligga i backend, så att AI:n inte “råkar” lägga känslig logik i gränssnittet. Vi har även ritat flödesscheman som beskriver alla delar och hur de förhåller sig till varandra och bifogar till prompten.
Bestäm designväg innan du bygger
Här har vi två lägen. Antingen låter vi AI bygga fritt, eller så utgår vi från skisser och referenser, ibland använder vi gränssnitt vi gillar från andra verksamheter som referens.
Om du vill ha ett specifikt uttryck, som vi oftast vill, ta fram designunderlag. Om du vill få upp något snabbt för intern dialog funkar fri design. Det ser ofta ganska generiskt ut och ibland blir det bra, ibland blir det skit.
Sätt en grundinstruktion som styr allt
Det här är vår största tidsvinst, alla kategorier.
I Google AI Studio lägger vi in en systeminstruktion som alltid gäller. Den berättar hur vår utvecklar AI strukturera kod och tolka instruktioner. I Lovable kan vi lägga samma typ av regler i första prompten. Där är det inte lika kritiskt för att komma igång, men det är lika viktigt för att hålla kvalitet när projektet växer. Vi brukar inkludera saker som filstruktur, namngivning, och en regel om att aldrig skriva om något annat än den kod om vi ber om.
Bygg först grundstruktur, inte hela baletten
Vi försöker alltid få upp en stomme först. Om vi bygger en guide i fem steg gör vi första sidan halvt funktionell, och resten blir dummyinnehåll. Det här är också något vi beskriver i första prompten. "Vi kommer vilja att du bygger alla de här stegen men vi vill att du börjar med enbart ..."
Det här gör vi för att vi vill se flödet, navigationen och komponenterna innan vi börjar optimera detaljer. När vi försöker göra allt rätt direkt blir det ofta fler och mer omfattande omtag.
Iterera i små steg, och upprepa samma regel
Be om en förändring i taget. Och vi skriver nästan alltid “ändra inget annat” även om det står i instruktionen. Hängslen och livrem. Det här är extra viktigt när du närmar dig design som ska kännas “klar”, annars dyker det upp knappar och funktioner som du inte alls har tänkt dig.
För att ta den lösning vi bygger till den kvalitet vi vill ha kräves ofta väldigt specifika instruktioner, ibland på detaljnivå och beskrivet i kodtermer.
Bryt monoliter tidigt, refaktorisera hellre för ofta än för sällan
Efter några dagars byggande gör vi nästan alltid en refaktor, alltså omstrukturera befintlig kod utan att ändra dess beteende. Vi bryter isär stora filer i fler komponenter och mappar. Annars är risken att en liten ändring leder till att AI skriver om hela filen, och att saker vi lagt många timmar på förändras utan att vi vill. Vibe coding gör det lätt att bara fortsätta framåt, men ibland är det bra att ta ett steg tillbaka och göra kodbasen begriplig. Speciellt om våra utvecklare ska ta över sen.
Från test till live, kontrollera vad du delar och var det körs
Det sista steget är inte mer promptning, utan en säkerhetskontroll och flytt från “sandbox” till något som funkar i verkligheten. Vi utgår från att allt vi ser i Lovable och AI Studio är frontend. Då är all kod synlig. Det betyder att du inte ska lägga in API-nycklar eller något annat känsligt som inte får hamna i fel händer.
Om vi kopplar på GitHub för versionhantering ska repos alltid vara privata, annars publicerar du hela lösningen direkt. Och om det här ska bli något publikt ser vi AI Studio som en playground. När man vill gå till produktion behöver man ta det vidare, till exempel via Vertex AI Studio, och lägga på riktiga delar som databas och säkerhet.
Två praktiska skillnader mellan Lovable och AI Studio i vardagen
Skillnaden i arbetssätt för oss handlar mest om stöd runt promptningen.
Lovable har en inbyggd chatt som kan resonera, planera och formulera strategi. I AI Studio finns inte samma chatt, så vi använder en AI bredvid, ofta Gemini eller ChatGPT, och ber den skapa specifika prompter som vi kan kopiera in.
Den andra skillnaden är feedback på design. AI Studio har en väldigt smidig funktion där man tar en skärmdump, ritar på den och förklarar ändringar, och sen uppdateras koden utifrån det. Den gör finjusteringar enklare när du väl har fått upp strukturen.
En realistisk förväntan på tid och pengar
Vi tycker fortfarande att vibe coding är magiskt, men vi tycker också att man måste vara ärlig. Många underskattar tidsåtgången kraftigt. 50 till 100 timmar är inte ovanligt om du ska bygga något som faktiskt ska användas, och varje timme kostar, i credits (loveable), svordomar och slitning av hår.
Det är inte ett argument mot vibe coding utan ett argument för att ha ett bra arbetsflöde så att inte tidsvinsten försvinner i omtag och “varför ändrade den det där”.
När vibecoding inte räcker, och vad vi gör då
Det finns också en punkt där vi slutar försöka prompta oss ur allt. När vi får fler användarroller, autentisering och mer avancerad logik börjar AI-ändringar slå igenom på oväntade ställen och felsökning tar tid. Ibland måste delar byggas om helt.
Samma sak gäller tillgänglighet. Verktygen kan lova WCAG och föreslå justeringar, men våra tester visade att det inte räcker. Tillgänglighet handlar om upplevelsen, och den behöver testas manuellt.
I praktiken betyder det att vi oftast ser vibe coding som en accelerator. Den tar oss snabbt till en bra prototyp och en grundstruktur. Sen exporterar vi till vår egen miljö och ser till att känslig logik ligger på en server vi själva styr.
Vår veckorutin
Varje vecka innan vi fortsätter bygga läser vi igenom specen och uppdaterar den om något förändrats. Vi ser över systeminstruktionen så att den fortfarande matchar kodbasen. Vi letar efter stora filer och bryter isär dem innan vi lägger på fler features. Och vi gör en snabb koll så att allt fortfarande funkar. Små saker som gör att vibe coding fortsätter vara kul och inte blir ett projekt där man till slut inte vågar röra något.
Sammanfattningsvis, styr arbetet innan det går över styr
Vibe coding i vardagen handlar mindre om att hitta rätt prompt och mer om att styra arbetet. Skriv en riktig spec, välj designväg, sätt en grundinstruktion, bygg en stomme, iterera smått, refaktorisera ofta och ha en säkerhetsgrind innan något lämnar den interna miljön.
Gör du det kan Lovable och Google AI Studio bli verktyg du faktiskt vågar använda regelbundet, och som kan ta dig från test till live utan att du tappar kontrollen.