Backa till något som fungerade innan du felsöker. En trasig app som du felsöker vidare på blir mer trasig, inte mindre. Först när du står på fast mark igen är det värt att ta reda på vad som gick fel — och då ska du fråga efter orsaken, inte efter en fix.
Slingan av staplade fixar
Så här ser den ut varje gång, och den är värd att känna igen tidigt:
Orsaken är enkel: modellen ser felmeddelandet, inte orsaken. Den svarar på det du visade. Varje varv lägger till en ändring som bara är motiverad av föregående varv, och sammanhanget blir för stort för att någon — inklusive modellen — ska kunna överblicka.
Tredje gången samma problem inte är löst: sluta fråga. Backa till senaste versionen som fungerade. Läs vad du gjorde sedan dess. Börja om från den punkten med ett mindre steg.
Det känns som att slösa arbete. Det är det motsatta — arbetet efter varv två var redan förlorat, du har bara inte betalat för det än.
Att backa är en färdighet
Att kunna gå tillbaka är den enda tekniska förmåga du absolut måste ha i vibecoding. Utan den är varje ändring permanent, och då vågar du inte prova något — vilket i sin tur är det som gör projekt långsamma.
Läsa ett felmeddelande utan förkunskaper
Felmeddelanden ser avskräckande ut men är oftast byggda av tre delar. Du behöver bara hitta dem.
app.js:42. Det är där du ska titta, inte i alla filer.Klistra alltid in hela meddelandet, inte första raden. Radnumret och filen är det som gör frågan besvarbar.
Var felmeddelandet gömmer sig
- På byggplattformar: i en panel som heter Console, Logs eller Errors. Ofta bakom en liten ikon längst ned.
- I webbläsaren: tryck F12 och välj fliken Console. Röd text är fel, gul är varningar du oftast kan ignorera.
- Om sidan är helt vit: felet finns nästan garanterat i Console. En vit sida är inte "ingen information", det är "informationen ligger någon annanstans".
Fem fel du kan lösa själv på fem minuter
- Ingenting händer när jag klickar. Knappen är oftast inte kopplad till något. Fråga: "Vad händer när knappen Anmäl klickas? Visa raden som avgör det."
- Allt försvann när jag laddade om. Data låg bara i webbläsarens minne. Det är inte ett fel, det är en saknad funktion — se guide 5.
- Det fungerar hos mig men inte hos andra. Nästan alltid något som bara finns på din dator, eller en nyckel som inte följde med vid publicering. Guide 6 går igenom det.
- Sidan är vit. Ett fel tidigt i koden stoppade allt. Öppna Console, ta första röda raden, klistra in hela.
- Det var rätt men blev fel efter senaste ändringen. Backa ändringen. Nu vet du precis vad som orsakade det, vilket är mer värdefullt än en fix.
Frågan som ger en förklaring i stället för en fix
Jag gör: [exakt vad du klickar och skriver, i ordning]. Jag förväntar mig [X] men får [Y].
Hela felmeddelandet: [klistra in allt].
Det fungerade innan jag [senaste ändringen].
Förklara vad som orsakar det här innan du föreslår någon ändring. Om du är osäker på orsaken, säg det och föreslå hur vi tar reda på den.
Den fetmarkerade raden är hela skillnaden. Utan den får du en ändring som kanske döljer symptomet. Med den får du en orsak, och kan avgöra om den föreslagna ändringen är rimlig.
- Fel som bara händer ibland. Fungerar nio gånger av tio. Nästan alltid en tidsfråga i koden, och svårt att felsöka utan förkunskaper.
- Fel som bara händer för vissa användare. Kan bero på deras webbläsare, deras data eller deras rättigheter.
- Fel som handlar om pengar eller behörighet. Här är gissningar för dyra. Ta hjälp.
- Fel som funnits sedan starten och som ingen fix biter på. Ofta är grundstrukturen fel, och då är det billigare att börja om litet än att laga stort.
Nästa steg
Det vanligaste "felet" i vibecoding är inget fel alls, utan att data aldrig sparades någonstans. Nästa guide handlar om var data faktiskt hamnar — och om de två sakerna du aldrig ska bygga själv.