Jag byggde en produkt med AI – så gör du förbättringar utan att förstöra det som fungerar

Läs mer om att arbeta med modeller i Ailoot-dokumentationen.

Varför börjar det dyraste arbetet efter lanseringen?#

Du byggde en app på en kväll, publicerade en länk och skickade den till dina vänner. Den fungerar. Sedan dyker den första riktiga personen upp en vecka senare, klickar på något på fel sätt och hälften av funktionerna slutar fungera. Du ber Claude att fixa det – den fixar en sak och förstör en annan. Känns det bekant?

Och här dyker huvudfrågan upp: vad gör man efter att ha lanserat en produkt, när euforin över den första fungerande prototypen har lagt sig och man ändå måste underhålla den på något sätt? Man skulle kunna kalla det vibe coding för vuxna. Att bygga innebär spänning och fart. Underhåll kräver ett kallt huvud: du förstår vad du ändrar och håller det under kontroll. De flesta misslyckas med den här andra delen eftersom ingen förbereder dem på den.

En branschstudie analyserade mer än en miljon kodändringar från 2,444 team och räknade ut vart pengarna som spenderas på AI-utveckling faktiskt tar vägen. Så här ser bilden ut:

Guiden ”Den dolda kostnaden för vibe coding” förklarar siffrorna mer ingående. Där handlade frågan om vad du betalar för. Här är frågan en annan: 44 cent av varje dollar går till att rätta buggar – och hela den här artikeln handlar om att hindra den andelen från att växa. Arbetet med att hålla den i schack kallas underhåll.

Skillnaden mellan någon som ägnar sig åt vibe coding för vuxna och någon som bara passar en neural nätmodell märks efter lanseringen. Den förstnämndas kodbas växer, hen gör förbättringar och ingenting går sönder. En månad senare har den andras produkt blivit en läckande manick som hen är rädd för att röra. Nu ska jag förklara hur du hamnar i den första gruppen.

Vad går egentligen sönder: 5 katastrofer efter lanseringen#

Det här är offentliga efteranalyser av verkliga produkter som byggts med AI, med siffror och datum. Tänk på dem som en karta över ett minfält – varje mina har redan exploderat för någon, och man vet hur man tar sig runt den.

Alla fem har samma grundorsak. Som standard gör AI saker så att de fungerar just nu, inte säkert en månad senare under belastning. Du ser inte skillnaden när du utvecklar på din dator. Den blir tydlig när den första främlingen med onda avsikter dyker upp.

Problemet är inte att koden inte skrivs för hand – många arbetar så. Problemet är att ingen frågar: ”Är databasen skyddad?” Härnäst visar jag en prompt som ställer den frågan åt dig.

Det första skyddsnätet är git och möjligheten att återgå till ”så som det var i går”#

När Claude förstör något behöver du en knapp för att ”ställa tillbaka det som det var i går”. Tekniskt sett heter knappen git, och det är enklare än det låter.

Tre termer som en icke-programmerare behöver förstå:

1. Kodförråd – projektmappen som sparas i molnet (vanligtvis på GitHub). En kopia av all kod som inte bara finns på din dator.
2. Commit – en återställningspunkt. Du säger i praktiken till koden: ”spara i det här läget”. Varje commit är en markör som du kan återvända till.
3. Deploy – en flytt. Koden fanns lokalt på din dator och fungerade bara för dig. Deploy skickar den till en extern server så att den fungerar för alla.

Så länge du har aktuella commit-punkter kan du återställa allt som gått sönder med en enda mening. Bokstavligen.

Jag har haft sönder något – allt fungerade i går, men i dag gör det inte det. Hitta den senaste committen då allt fungerade, visa mig vad som har ändrats sedan dess och återställ projektet till det läget.

Två regler att införa direkt, innan andra ser produkten:

• Kodförrådet måste vara privat. Inte offentligt. Annars kan vem som helst läsa koden och allt som finns i den.
• Lägg hemlighetsfilen på ignore-listan. Nycklar, lösenord och inloggningsuppgifter till databasen finns i en separat fil (vanligtvis .env), och den filen får aldrig hamna i kodförrådet. Lägg till en rad för .env i .gitignore, så stannar hemligheterna hos dig.

Det finns en separat guide om hur du säkert återställer ändringar i Claude Code: Så återställer du ändringar i Claude Code. Utan återställningspunkter går du på lina utan skyddsnät och förr eller senare faller du.

Vad återställer /rewind, och vad återställer det inte?#

Claude Code tar en ögonblicksbild av läget före varje ändring som det gör. Kommandot /rewind (eller att trycka på Esc två gånger) återställer både filer och konversation till en vald punkt. Det är praktiskt: om du råkade ha sönder en funktion för fem minuter sedan kan du gå tillbaka fem minuter.

Men det finns en fälla som gör att nybörjare förlorar data. /rewind återställer inte allt:

Anthropic uttrycker det själv tydligt: ögonblicksbilder är en lokal ångra-knapp, medan git är den permanenta historiken. Ögonblicksbilder kompletterar versionshantering, men ersätter den inte.

Den praktiska slutsatsen för en icke-programmerare: /rewind räddar dig från ”Claude hade just sönder en funktion”. Men om den hann radera en databasrad eller ladda upp kod till molnet kan bara git och en databassäkerhetskopia återställa den. Behåll alltså båda lagren: ögonblicksbilder för snabba återställningar och commits för projektets permanenta historik.

Hur gör du förbättringar utan att förstöra det som redan fungerar?#

Varannan person fastnar i den här loopen. Du ber AI fixa en liten bugg. Den föreslår en rimlig ändring. Den ändringen förstör något annat. Du ber den fixa det nya problemet, och två problem till dyker upp. Och så vidare.

Loopen uppstår eftersom vibe coding är icke-deterministisk. Samma prompt ger dig olika kod två gånger. Därför kan varje redigering i tysthet förskjuta den omgivande logiken: rabattgränsen flyttas från 10 till 12 procent, eller så ändras en valideringsregel – utan att du kontrollerar något och utan en enda varning. Det här kallas logisk drift, och den skadar i tysthet precis sådant som ger intäkter: priser, åtkomst och betalningar.

Det finns en regel som skyddar mot drift, och den är så enkel att du kan sätta upp den på väggen: committa inte kod som du inte kan förklara ord för ord för en annan person.

I praktiken blir detta en färdig instruktion att använda före varje ändring av fungerande kod. Den får AI att ta små steg och visa dig exakt vad som ändrades.

Gör följande innan du ändrar koden:

Spara det aktuella fungerande läget som en separat återställningspunkt (commit).

Beskriv exakt med ord vad du planerar att ändra och i vilka filer.

Gör den minsta möjliga ändringen – bara det som löser min uppgift, inget extra.

Visa mig vad som ändrades och förklara varje ändring så att jag kan förklara den för en annan person.
Rör inte pris-, åtkomst- eller betalningslogik om jag inte har bett dig om det.

En annan princip som sparar veckor är disciplin kring uppgiftens gränser. Ett problem, en ändring, snabb implementation. Be inte AI skriva om halva projektet i en enda prompt. Professionella utvecklare börjar ibland bygga en hel Uber när allt de behövde var en enda knapp – och drar ut på det i månader. Du behöver inte göra så.

Allt jag beskriver bygger på en sak: att hantera kontext. För att hindra AI från att förstöra närliggande logik måste den komma ihåg projektets regler.

Hur kontrollerar du en ändring innan du publicerar den?#

Mellan ”det fungerar på min dator” och ”det fungerar för alla” finns ett mellansteg som nybörjare hoppar över: en testkopia. Det är en separat ögonblicksbild av produktionsmiljön där du kontrollerar en ändring innan riktiga människor ser den. Arbetscykeln ser ut så här:

1. Bygg och kontrollera ändringen själv (utveckling).
2. Driftsätt den till staging – en kopia av produktionen, men utan riktiga användare.
3. Kör igenom nyckelscenarierna och säkerställ att inget har förändrats.
4. Först nu driftsätter du den i produktion.

Varför spelar detta roll efter lanseringen? Varje version innebär en risk. En liten kodändring kan förstöra inloggningen. En enda saknad inställning kan slå ut hela produkten. Staging fångar upp sådana problem utan konsekvenser; i produktion förlorar du kunder.

För att slippa kontrollera allt manuellt varje gång kan du ge AI en prompt som jämför den nya versionens beteende med den gamlas inom de kritiska områdena.

Jag ska driftsätta en ändring. Gå igenom produktens nyckelscenarier i tur och ordning och kontrollera att varje scenario fortfarande fungerar som tidigare:

Registrering och inloggning för nya användare.

Betalning och beviljad åtkomst efter betalning.

Åtkomsträttigheter – en vanlig användare kan inte se någon annans data eller adminområdet.

Viktiga siffror i affärslogiken (priser, rabatter, gränser) har inte ändrats.
Om något beter sig annorlunda än i den tidigare versionen ska du stanna och visa mig exakt vad som har ändrats.

Var finns dina hemligheter? Nybörjarens största säkerhetslucka#

Jag förklarar den största säkerhetsrisken i detalj eftersom den slår ut fler produkter än någon annan. När AI skriver kod är det enklast att lägga in en nyckel där den fungerar direkt – i koden för sidan som öppnas i webbläsaren. Du märker inte skillnaden under utvecklingen. Men vem som helst kan läsa allt som når webbläsaren genom att öppna utvecklarverktygen.

Grundaren vars kunder debiterades $87,500 sa senare att en enda prompt hade kunnat förhindra det. Debiteringarna återfördes till slut, men de ej återbetalningsbara avgifterna och den förlorade sinnesron blev kvar. Här är prompten.

Kontrollera hela projektet och säkerställ att ingen hemlig nyckel hamnar i webbläsaren:

Hitta alla nycklar till databasen, betalningssystemet och externa tjänster.

Säkerställ att varje nyckel endast lagras på servern, i miljövariabler, och inte i sidkod.

Kontrollera projektets historik – har någon nyckel råkat hamna där tidigare?
Visa mig en lista över varje plats där du hittade hemligheter och vad som behöver göras åt var och en.

Nästa säkerhetslucka i närheten är att kontrollera åtkomsträttigheter bara på webbläsarsidan. Om produkten avgör om den ska ”visa adminområdet” i sidkoden kan vem som helst kringgå det beslutet. Åtkomsträttigheter måste alltid kontrolleras på servern. Databasen måste bara lämna ut data till dem som har rätt till den – det är vad säkerhet på radnivå (RLS) är till för, och den måste aktiveras på varje tabell.

Innan du säljer åtkomst eller släpper in andra ska du göra en övergripande säkerhetsgranskning av produkten.

Gå igenom projektet som en angripare och hitta säkerhetshål:

Ligger några hemliga nycklar i kod som skickas till webbläsaren eller i projektets historik?

Är säkerhet på radnivå (RLS) aktiverad för varje databastabell, och kontrolleras åtkomsträttigheterna på servern i stället för enbart i webbläsaren?

Är automatisk säkerhetskopiering av databasen konfigurerad, och har jag någon gång kontrollerat att jag kan återställa från den?

Är produktionsdatabasen isolerad från miljön där AI-agenten körs?
Säg för varje punkt om allt är i sin ordning eller exakt vad som behöver åtgärdas.

Det finns en separat, fullständig guide om säkerhet för vibe coding: Så skyddar du en app byggd med vibe coding. Regeln är enkel: utgå från att allt AI har gjort är oskyddat tills du har kontrollerat motsatsen.

Var ska du hosta produkten: hostingtrappan#

Du behöver inte hyra en egen server och konfigurera den manuellt direkt – det är komplicerat i början och kommer att ta mycket tid. Det finns en trappa att följa när produkten växer:

1. Gratis hosting (till exempel Vercel) – för dig själv, tester och små projekt. Det fungerar om plattformen är tillgänglig för din målgrupp och du inte lagrar personuppgifter.
2. En plattform med driftsättning i ett kommando (Railway) – när du har en backend och en databas. Du driftsätter med ett kommando och behöver inte konfigurera en server. Tröskeln för att komma i gång är minimal.
3. En egen dedikerad server – när belastningen är hög och du behöver full kontroll. Byt till den senare, när du har nått plattformens gräns.

För en icke-programmerare som precis har lanserat är det enklaste alternativet en plattform med driftsättning i ett kommando, utan manuell serverkonfiguration. Byt till en egen server senare. Om du vill följa den här vägen med ett konkret exempel kan du läsa guiden om att driftsätta ett vibe-kodat projekt på en egen server med Coolify.

När ska du separera appen, databasen och säkerhetskopiorna?#

Tre saker ska inte förvaras i samma korg: appen, databasen och säkerhetskopiorna. Så länge det finns få användare ligger allt tillsammans, och det är helt okej. Men det finns en tydlig signal för när det är dags att separera dem.

• Placera appen och databasen på olika maskiner. Signalen: vid toppbelastning ligger processor- och minnesanvändningen kvar över 70–80 procent, förfrågningarna blir långsammare och appen och databasen konkurrerar om samma resurser. När du har separerat dem kan du förstärka databasen utan att röra appen, och tvärtom.
• Följ 3-2-1-regeln för säkerhetskopiering. Tre kopior av data, på två olika typer av medier, varav en förvaras utanför platsen. Det skyddar mot maskinvarufel och utpressningsprogram. Det viktiga är att säkerhetskopiorna skapas automatiskt.

Hur ofta du behöver säkerhetskopiera beror på hur dyrt det är att förlora data från flera timmar. För en prenumerationstjänst online där förlust av en timmes betalningsposter är oacceptabel måste säkerhetskopieintervallet vara kortare än en timme, eller så behövs verifierade transaktionsloggar och återställning till vald tidpunkt (PITR). Välj intervall efter största tolerabla dataförlust och testa separat tiden för att återställa tjänsten. En gång om dagen räcker för en blogg. Logiken är enkel: bestäm hur mycket data du har råd att förlora och konfigurera säkerhetskopieringen därefter.

Hjälp mig avgöra om det är dags för min produkt att flytta till en mer avancerad infrastruktur. Kontrollera och fråga mig om varje punkt:

Hur belastade är processorn och minnet vid toppar – ligger användningen kvar över 70–80 procent eller inte?

Finns databasen och appen på samma maskin eller på olika maskiner?

Är automatisk säkerhetskopiering av databasen konfigurerad, och har jag testat att återställa från den?

Finns det en separat kopia av miljön (staging) för kontroller före driftsättning?
Ge mig utifrån resultaten en tydlig rekommendation: vad som ska vara kvar som det är, vad som ska separeras först och varför.

Det finns en separat fråga: hanterad databas eller egen. För ett litet team är en hanterad databas nästan alltid bättre: en egen är billigare i maskinvara, men den slukar timmar i underhåll. Om du arbetar ensam och produkten inte handlar om infrastruktur kostar de timmarna mer än skillnaden i serverpris.

Hur automatiserar du underhållet?#

Manuellt underhåll är utmattande. Du kan slippa det på två sätt: övervakning och en patrullerande agent.

Övervakning använder två olika verktyg för två olika uppgifter:

1. ”Är webbplatsen uppe?” – en tillgänglighetsövervakare (till exempel UptimeRobot). Den pingar produkten med några minuters mellanrum och skickar en avisering om den slutar fungera. Det finns en gratisplan.
2. ”Vad gick exakt sönder?” – en felspårare (till exempel Sentry). Den samlar in fel inne i appen och visar var och varför något misslyckades.

Den första fångar upp att produkten har slutat fungera. Den andra visar vilken funktion som fallerade och varför. Tillsammans besvarar de frågan: ”Får jag reda på ett fel innan en kund skriver till supporten?”

Den andra nivån av automatisering är en patrullerande agent. Föreställ dig en fastighetsbyrå: klockan sju på morgonen läser en AI-agent förfrågningar på webbplatsen, ser att bokningsformuläret är trasigt, hittar orsaken i koden och kommer tillbaka med en färdig lösning och en förklaring. Du granskar den och säger ”ja” – den driftsätts. Ordningen spelar roll: lös först användarens problem (bevilja åtkomst, be om ursäkt), utred sedan orsaken och pengarna.

Ytterligare en regel för AI:s åtkomst till produktionsdatabasen: ge den en användare med enbart läsbehörighet och dölj personuppgifter bakom ett mellanlager så att agenten ser ”namn” i stället för personens riktiga namn. Då kan den fysiskt sett inte radera eller förstöra produktionsdata, även om den gör ett misstag. Incidenten i tabellen ovan, där en agent raderade produktionsdatabasen, handlar precis om att den här begränsningen saknades. Guiden Vad gör du om AI raderade databasen förklarar vad du ska göra om katastrofen redan har inträffat.

När är det dags att lägga ned en produkt?#

Den mest underskattade delen av underhåll är att veta när man ska sluta underhålla. Alla som bygger mycket har en kyrkogård av projekt: man byggde ett, pillade med det och övergav det sedan. Det är normalt och inte ett misslyckande. Misslyckandet är att släpa runt på något som ingen använder i månader för att man ångrar tiden man lade ned.

Trösklar du kan använda för att fatta beslutet:

1. Två veckor – tillräckligt för att se om en idé fungerar. Om de första riktiga användarna återkommer ska du fortsätta. Tystnad är ett svar.
2. Tre månader – den absoluta gränsen. Om den inte har tagit fart på tre månader ska du lägga ned den. Med vibe codings hastighet är det för länge att lägga sex månader på att testa en idé.

Det är psykiskt svårt att avsluta ett projekt, så behandla det som ett beslut, inte en känsla. Att släppa taget om ett projekt du har investerat i är som att säga upp en anställd som inte klarar jobbet: obehagligt, men det kostar mer att behålla personen än att låta den gå.

Underhåll är arbete som utförs för att hålla en produkt vid liv och användbar för människor. Allt annat – git, säkerhetskopior och övervakning – är bara verktyg som hjälper dig att nå dit där produkten börjar arbeta för dig varje dag.

Att bygga en produkt med AI på en kväll är halva jobbet. Att hålla den vid liv och säker när den växer – det är vad vibe coding för vuxna innebär.

För ditt nästa steg – Ailoot.