De flesta vibecoding-projekt som havererar gör det av samma handfull skäl, och inget av dem handlar om att modellen var för dålig. Det handlar nästan alltid om storleken på steget, avsaknaden av en väg tillbaka, eller att man byggt vidare på något man aldrig provat.
1. Att be om hela appen på en gång
Det första man gör, och det som kostar mest. "Bygg en app där man kan boka tider" ger något som ser imponerande ut och nästan fungerar. När det inte gör det finns ingen delvis fungerande version att gå tillbaka till, för det har aldrig funnits någon.
Gör så här i stället: be om den minsta delen som går att prova. En sida som visar något. Sedan ett fält att skriva i. Sedan att det sparas. Varje steg provkört innan nästa.
2. Att inte kunna gå tillbaka
Utan sparade versioner är varje ändring permanent. Det gör att en dålig timme kan radera en bra vecka, och det gör att man vågar mindre — vilket i sin tur gör att man arbetar långsammare.
Gör så här i stället: ta reda på hur ditt verktyg sparar versioner innan du bygger något, inte efter. Spara en version varje gång något börjar fungera, inte bara när du är klar för dagen.
3. Att stapla fixar
Fel, fix, nytt fel, ny fix. Efter fem varv felsöker du konsekvenserna av dina egna fixar i stället för det ursprungliga problemet.
Gör så här i stället: sätt en gräns vid två försök. Fungerar inte det andra, backa till senast fungerande version och beskriv problemet från början. Se När det går sönder.
4. Att lita på "det ser klart ut"
Modellen skriver att den är klar. Koden ser komplett ut. Ingen har provat något.
Det här är det farligaste misstaget just för att det inte känns som ett misstag. Allt går bra, ända tills flera lager är byggda ovanpå något som aldrig fungerade.
Gör så här i stället: klicka igenom det själv, varje gång. "Klart" betyder att du sett det fungera, inget annat.
5. Att bygga inloggning och betalning själv
Både inloggning och betalning ser enkla ut och är det inte. Det är områden där ett fel inte ger ett felmeddelande utan en läcka eller en felaktig transaktion, ofta utan att någon märker det på ett tag.
Gör så här i stället: använd en färdig tjänst för båda. Be uttryckligen om det: "använd en etablerad inloggningstjänst, bygg inte egen lösenordshantering". Det är inte fusk — det är vad professionella utvecklare gör av precis samma skäl.
6. Att inte veta vad appen ska göra
Projekt som börjar med "något med recept, typ" driver iväg. Varje session lägger till en idé, ingenting blir klart, och till slut är appen för rörig för att förklara ens för modellen.
Gör så här i stället: skriv en mening om vad appen gör, och en lista på vad den inte ska göra i version ett. Läs meningen igen när du frestas att lägga till något.
7. Att strunta i vad det kostar
Använder appen en betaltjänst kan kostnaden vara noll i tre veckor och sedan inte vara det — särskilt om något anropar i en loop, eller om en publik nyckel hittats av någon annan.
Gör så här i stället: sätt en utgiftsgräns hos tjänsten redan första dagen, och titta på förbrukningen någon gång i veckan. Det är fem minuter som kan spara en obehaglig faktura.
8. Att aldrig titta på koden
Så länge man inte tittar alls kan man inte upptäcka att något lagts till som inte skulle vara där, eller att ett problem lösts genom att stänga av det som gick sönder.
Gör så här i stället: lär dig läsa grovt. Det tar en kväll och räcker resten av tiden. Se Läsa AI-genererad kod.
Sju av åtta misstag handlar om samma sak: att gå framåt utan att ha kontrollerat att det senaste steget faktiskt fungerade. Vibecoding är snabbt nog att det känns onödigt att stanna och prova. Det är precis därför det är den vanan som avgör om projektet blir klart.
Om appen växer förbi det du kan hantera själv är det inte ett misslyckande — det är ett normalt läge med ett normalt nästa steg.