I förra inlägget skrev vi om hur vi testar vibe coding och hur vi jämför Lovable och Google AI Studio. Om du har kommit så långt att du faktiskt bygger regelbundet uppstår ett nytt problem. Det handlar inte längre om att lyckas få upp något som funkar, utan snarare hur vi fortsätter bygga utan att allt blir rörigt, dyrt eller är fullt av säkerhetshål.
Vi tänkte dela med oss av vår arbetsmodell. Den funkar både i Lovable och 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 lek till något som ska bli en konkret leverans ser vi tre vanliga anledningar till att projekt havererar.
Först, AI:n börjar skapa monoliter. En fil blir enorm, och efter några dagar räcker en liten ändring för att hela filen ska skrivas om. Vi har varit där. Man ber om något litet och får tillbaka 2000 rader som ser “ungefär rätt” ut, men där en massa annat har ändrats lite random.
Sen, man gör för stora ändringar per prompt. Ber vi om fem saker får vi ofta tre okej, två skit, och ibland dessutom några nya knappar vi aldrig bett om.
Till sist, man glömmer lätt att de här miljöerna är frontend först. Kod, nycklar och lösenord kan ligga öppet som default. Det är den största fällan när man går från intern prototyp till något som andra ska använda.
Vårt arbetssätt för större projekt
Vi jobbar med några specifika hållpunkter. Inte som en rigid process, utan som metoder för att hålla kaoset på armlängds avstånd. När vi någon gång hoppat över ett steg kommer det alltid tillbaka senare, dyrare och jobbigare att lösa.
Börja med en spec som är längre än tre rader
Tre rader 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. Det handlar ofta om 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 och laddat upp som beskriver alla delar och hur de förhåller sig till varandra.
Bestäm designväg innan du bygger
Vi har 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, välj referenser. Om du vill få upp något snabbt för intern dialog, funkar fri design. Men var beredd på att AI ofta föreslår och genomför ändringar du inte bett om. Ibland är det bra, ibland är 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 definierar hur vår “utvecklar AI” ska tänka, 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 det.
Bygg först en enkel struktur, inte en “färdig” produkt
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 omtag.
Iterera i små steg, och upprepa samma regel
Gör en ändring i taget. Och vi skriver nästan alltid “ändra inget annat”. 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.
Vi ser ofta att AI landar runt 50 till 70 procent av den pixelperfekta kvalitet vi vill ha. Resten kräver mycket tid och 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 externa 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.
Det här är också en mental grej. Vibe coding gör det lätt att “fortsätta framåt”, men vi behöver ibland ta ett steg tillbaka och göra kodbasen begriplig.
Från test till live, kontrollera vad du delar och var det körs
Det sista steget är inte mer promptning, utan kontroll och flytt från “sandbox” till något som tål 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 GPT, och ber den skapa extremt specifika prompts 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. Det är ett argument för att ha ett workflow. Utan workflow försvinner vinsten snabbt i missförstånd, omtag och “varför ändrade den det där”.
När vibecoding inte räcker, och vad vi gör då
Det finns 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 ser vibe coding som en accelerator. Den tar oss snabbt till en bra prototyp och en grundstruktur. Sen tar vi över mer kontroll, exporterar till vår egen miljö, och ser till att känslig logik ligger på en server vi själva styr.
Vår enklaste veckorutin
Varje vecka gör vi samma sak innan vi fortsätter bygga. Vi läser 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 säkerhetskoll, bara för att inte vänja oss vid att allt “bara funkar”.
Det låter som små saker, men det är de som gör att vibe coding fortsätter vara kul, istället för att bli 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.