Modellen skriver koden. Du bestämmer vad som ska byggas och avgör om det blev rätt. Den delen flyttar inte över, hur bra verktygen än blir. En modell som får en vag beskrivning svarar med något plausibelt — inte med en motfråga. Ditt jobb är att beskriva tydligt, ta ett steg i taget och prova varje steg innan du ber om nästa.
Vad vibecoding faktiskt räcker till
Det lönar sig att vara konkret här, för gränsdragningen avgör om du får något användbart eller bara en hög med halvfärdiga försök.
Metoden är stark när appen är liten, tydligt avgränsad och när du kan se med egna ögon att den fungerar. Den blir svår när resultatet inte går att kontrollera utan förkunskaper — när det handlar om pengar, om andras personuppgifter, eller om saker som bara går sönder efter tre månaders användning.
Projekt som brukar bli klara
- Ett formulär med en lista. Anmälningar, felrapporter, en intresselista. Du fyller i, det syns i listan, du ser direkt att det stämmer.
- En räknare eller kalkyl. Offertunderlag, portionsberäkning, en enkel prislista med tillval.
- En intern översikt. Data du redan har, presenterad så att den går att förstå. Ingen inloggning, en handfull användare.
- En prototyp du ska visa någon. Målet är att förklara en idé, inte att driva den i två år.
- Ett litet verktyg för dig själv. Något som sparar dig tjugo minuter i veckan och där du är den enda som drabbas om det går sönder.
- Egen inloggning med lösenord. Ser ut att fungera direkt och är nästan alltid osäkert. Använd en färdig tjänst i stället — mer om det i guide 5.
- Betalningar du hanterar själv. Kortuppgifter ska aldrig gå genom kod du inte kan granska.
- Appar som hanterar känsliga personuppgifter. Hälsa, ekonomi, barn. Kostnaden för ett fel är en annan än för en anmälningslista.
- Något som ska ändras av andra i flera år. Kod du inte förstår är kod ingen kan förvalta, inklusive du själv om sex månader.
- Integrationer mot system du inte kan testa. Om du inte kan prova anropet kan du inte veta om det blev rätt.
Vad du behöver innan du börjar
Inte mycket, men de här fyra sakerna sparar dagar. Att skaffa dem tar en förmiddag.
Arbetsflödet: fyra steg som upprepas
Samma loop varje gång, oavsett om ändringen tar tio minuter eller en kväll. Poängen är inte ceremonin — det är att varje steg slutar med något du kan titta på innan du går vidare.
Steg 2 hoppas oftast över och lönar sig mest. Om planen är fel blir bygget fel, och det är billigare att upptäcka i punktform. Steg 4 hoppas näst oftast över, och det är det som kostar mest när det går fel.
Projektbeskrivningen: skriv en gång, klistra in varje gång
Modellen har inget minne mellan sessioner. Utan en nedskriven beskrivning börjar varje ny konversation om från noll, och du märker det på att samma diskussion återkommer: ska datumet skrivas si eller så, hette knappen "Anmäl" eller "Skicka".
Lösningen är en kort text som du sparar och klistrar in i början av varje ny session, eller lägger i den fil verktyget läser automatiskt. Den behöver inte vara lång. Den behöver vara sann.
Vad som hör hemma i projektbeskrivningen
- Vad appen gör, i en eller två meningar.
- Vem som använder den och på vilken sorts skärm.
- Vilka skärmar eller sidor som finns, med ett par ord om var och en.
- Vad som uttryckligen inte ingår. Den här raden är den mest värdefulla.
- Beslut du redan tagit och inte vill diskutera igen, med en rad om varför.
- Språket i gränssnittet, datumformatet, tonen i felmeddelanden.
Uppdatera texten när ett beslut ändras. En beskrivning som ljuger är sämre än ingen alls, eftersom modellen följer den utan att invända.
Fem misstag som kostar mest
- Att beställa för mycket på en gång. "Bygg anmälningssystemet" ger något stort som nästan fungerar. Det är den svåraste sortens resultat att komma vidare från. Be om ett steg.
- Att inte ha någon väg tillbaka. Utan versionshistorik är varje ändring permanent. Då blir varje fel dyrt och du börjar undvika att prova saker.
- Att stapla fixar. Fel uppstår, du klistrar in det, får en fix, nytt fel uppstår. Efter fem varv är appen sämre än när du började. Backa i stället — guide 4 handlar bara om det här.
- Att acceptera något du inte alls förstår. Du behöver inte kunna skriva koden. Men om du inte kan säga vad en fil är till för kan du inte heller avgöra om den ska vara där. Fråga tills du kan.
- Att tro på siffror och versioner. Priser, modellnamn och gränser är precis den sorts fakta som låter säkrast och åldras snabbast. Kontrollera mot leverantörens egen sida.
Nästa steg
Om du bara tar med dig en sak: gör stegen mindre. Det är den enskilda vanan som gör mest skillnad, och den är gratis att börja med i dag. Artikeln En sak i taget går igenom varför.
Vill du bygga något konkret parallellt med läsningen finns kursen: ett enda projekt genom sex delar, från en mening om vad appen ska göra till en publicerad adress.
Den här guiden är del ett av åtta. Resten tar ett moment i taget — beställningen, läsningen, felsökningen och data och inloggning — och avslutas med publicering, säkerhet och verktyg.