Vibecoding Del 3

När appen går sönder

Det börjar med ett fel, en fix, ett nytt fel. Efter fem varv fungerar ingenting och du vet inte längre vilken ändring som orsakade vad. Det finns bara en väg ut ur det läget, och den går bakåt.

Senast granskad: 26 jul 2026

Del 3 av 6 i vibecoding-spåret — för dig som bygger genom att beskriva vad du vill ha. Skriver du kod till vardags är guideserien mer detaljerad.

Kort sagt

Backa först, felsök sedan. När appen slutat fungera är den mest lönsamma åtgärden nästan alltid att gå tillbaka till den senaste version som fungerade — inte att be om ännu en fix. Det känns som att förlora arbete. I praktiken är det att sluta gräva sig djupare.

Läget du hamnat i

Det börjar med ett fel. Du klistrar in det, får en fix, ett nytt fel dyker upp. Du klistrar in det också. Efter fem varv fungerar ingenting, felmeddelandena handlar om saker du aldrig hört talas om, och du vet inte längre vilken ändring som orsakade vad.

Det som hänt är att varje fix bygger på antagandet att den förra var rätt. Var den inte det felsöker du nu konsekvenserna av tidigare fixar i stället för det ursprungliga problemet. Ju längre du håller på, desto svårare blir det.

Det finns bara en väg ut ur det läget, och det är bakåt.

Första åtgärden: backa

1
Gå tillbaka till senaste version som fungerade. De flesta verktyg har historik eller versioner inbyggt. Har du inte det — det är den viktigaste saken att fixa innan nästa projekt.
2
Bekräfta att den faktiskt fungerar. Klicka igenom appen. Utgå inte från att den gör det bara för att den gjorde det igår.
3
Skriv ned vad du försökte göra när det gick sönder. Det är den enda informationen som är värd att ta med från de senaste tjugo minuterna.
4
Be om det igen — men i ett mindre steg. Om "lägg till inloggning" gick sönder, be om bara inloggningsformuläret först, utan att det gör något.

Läsa ett felmeddelande utan att kunna koda

Felmeddelanden ser skrämmande ut för att de är skrivna för utvecklare. Men fyra saker går att plocka ut utan förkunskaper, och de räcker nästan alltid.

Fyra saker att leta efter

Med de fyra sakerna kan du ställa en fråga som handlar om ditt problem i stället för om felmeddelandet i allmänhet — och det ändrar svaret helt.

Frågan som fungerar

När något gått sönder Efter att du backat

Vad jag försökte göra: [i en mening]

Vad som händer i stället: [vad du ser på skärmen]

Felmeddelandet: [hela, inte bara sista raden]

När det senast fungerade: [innan jag bad om X]

Förklara först vad felet betyder, på vanlig svenska. Föreslå fix efter det — en enda, den minsta möjliga.

"Den minsta möjliga" är värd att ha med. Utan den formuleringen kommer förslaget gärna med en omskrivning av tre filer, och du är tillbaka där du började.

Fel du kan lösa själv

Vissa problem är så vanliga att det är värt att prova innan du frågar någon.

Sidan är tom och vit
Nästan alltid ett fel som stoppat allt. Öppna webbläsarens utvecklarkonsol — högerklicka, "Inspektera", fliken "Console". Där står felet.
Ändringen syns inte
Ladda om hårt, eller prova i ett privat fönster. Webbläsaren visar ofta en sparad äldre version.
Fungerar lokalt, inte publicerat
Något som finns på din dator saknas på servern — oftast en inställning eller en nyckel. Se Publicera appen.
Data försvinner vid omladdning
Det sparas ingenstans permanent. Det är inte en bugg utan en funktion som saknas — be om den uttryckligen.

När du ska sluta för dagen

Två tecken på att det inte är läge att fortsätta: du har fått samma förslag två gånger, eller du kan inte längre förklara vad appen ska göra.

Backa till en fungerande version, spara den, och gå ifrån det. Problemet ser nästan alltid annorlunda ut nästa gång. Det är inte ett tålamodsråd — det är att en trött person som stapla fixar gör mer skada per timme än en utvilad gör nytta.


När appen fungerar lokalt återstår momentet som överraskar flest: att få den att fungera för någon annan än dig.

Nästa del
Publicera appen