Jeg byggede et produkt med AI – sådan forbedrer du det uden at ødelægge det, der fungerer

Læs mere om at arbejde med modeller i Ailoot-dokumentationen.

Hvorfor begynder det dyreste arbejde efter lanceringen?#

Du byggede en app på en aften, offentliggjorde et link og sendte det til dine venner. Den virker. En uge senere dukker det første rigtige menneske op, klikker forkert på noget, og halvdelen af funktionerne holder op med at virke. Du beder Claude om at rette det – den retter én ting og ødelægger en anden. Lyder det bekendt?

Og her melder hovedspørgsmålet sig: Hvad gør du efter at have lanceret et produkt, når euforien over den første fungerende prototype har lagt sig, og du stadig skal vedligeholde det på en eller anden måde? Man kunne kalde det vibe coding for voksne. Byggeri handler om begejstring og fart. Vedligeholdelse kræver koldt blod: Du forstår, hvad du ændrer, og holder det under kontrol. De fleste fejler i denne anden del, fordi ingen forbereder dem på den.

En brancheundersøgelse analyserede mere end en million kodeændringer fra 2,444 teams og beregnede, hvor pengene brugt på AI-udvikling faktisk går hen. Sådan ser billedet ud:

Guiden “Den skjulte pris ved vibe coding” forklarer tallene mere detaljeret. Der handlede spørgsmålet om, hvad du betaler for. Her er spørgsmålet et andet: 44 cent af hver dollar går til at rette fejl – og hele denne artikel handler om at forhindre den andel i at vokse. Arbejdet med at holde den i skak kaldes vedligeholdelse.

Forskellen på en, der laver vibe coding for voksne, og en, der bare passer en neural netmodel, viser sig efter lanceringen. Den førstes kodebase vokser, vedkommende laver forbedringer, og intet går i stykker. En måned senere er den andens produkt blevet et utæt sammensurium, som vedkommende er bange for at røre ved. Nu forklarer jeg, hvordan du ender i den første gruppe.

Hvad går faktisk galt: 5 katastrofer efter lanceringen#

Dette er offentlige efteranalyser af virkelige produkter bygget med AI, med tal og datoer. Tænk på dem som et kort over et minefelt – hver mine er allerede gået af for nogen, og man ved, hvordan man kommer uden om den.

Alle fem har samme grundårsag. Som standard får AI ting til at virke lige nu, ikke sikkert en måned senere under belastning. Du kan ikke se forskellen, mens du udvikler på din computer. Den bliver tydelig, når den første fremmede med onde hensigter dukker op.

Problemet er ikke, at koden ikke skrives i hånden – mange arbejder sådan. Problemet er, at ingen spørger: “Er databasen sikret?” Nu viser jeg dig en prompt, der stiller spørgsmålet for dig.

Det første sikkerhedsnet er git og muligheden for at gå tilbage til “sådan som det var i går”#

Når Claude ødelægger noget, har du brug for en knap til at “sætte det tilbage, som det var i går”. Teknisk set hedder den knap git, og det er enklere, end det lyder.

Tre begreber, en ikke-programmør skal forstå:

1. Repository – din projektmappe gemt i skyen (som regel på GitHub). En kopi af al din kode, som ikke kun findes på din computer.
2. Commit – et tilbagegangspunkt. Du siger i praksis til koden: “gem i denne tilstand”. Hver commit er en markør, du kan vende tilbage til.
3. Deploy – en flytning. Koden var lokal, på din computer, og virkede kun for dig. Deploy sender den til en ekstern server, så den virker for alle.

Så længe du har nyere commit-punkter, kan du rulle enhver skade tilbage med én sætning. Helt bogstaveligt.

Jeg har ødelagt noget – alt virkede i går, men i dag gør det ikke. Find den seneste commit, hvor alt fungerede, vis mig, hvad der er ændret siden da, og rul projektet tilbage til den tilstand.

To regler, du skal indføre med det samme, før andre ser produktet:

• Repositoryet skal være privat. Ikke offentligt. Ellers kan alle læse din kode og alt, hvad den indeholder.
• Sæt hemmelighedsfilen på ignore-listen. Nøgler, adgangskoder og databaseadgangsoplysninger ligger i en separat fil (som regel .env), og den fil må aldrig komme med i repositoryet. Tilføj en linje for .env i .gitignore, så bliver hemmelighederne hos dig.

Der findes en separat guide til sikker tilbagerulning af ændringer i Claude Code: Sådan ruller du ændringer tilbage i Claude Code. Uden tilbagegangspunkter går du på line uden sikkerhedsnet, og før eller siden falder du.

Hvad ruller /rewind tilbage, og hvad gør det ikke?#

Claude Code tager et snapshot af tilstanden før hver ændring, det foretager. Kommandoen /rewind (eller at trykke på Esc to gange) ruller både filer og samtale tilbage til et valgt punkt. Det er praktisk: Hvis du ødelagde en funktion for fem minutter siden, kan du gå fem minutter tilbage.

Men der er en fælde, som får begyndere til at miste data. /rewind ruller ikke alt tilbage:

Anthropic siger det selv klart: Snapshots er en lokal “fortryd”-knap, mens git er permanent historik. Snapshots supplerer versionsstyring, men erstatter den ikke.

Den praktiske lære for en ikke-programmør: /rewind redder dig fra “Claude ødelagde lige en funktion”. Men hvis den nåede at slette en databaselinje eller uploade kode til skyen, kan kun git og en databasesikkerhedskopi bringe det tilbage. Behold derfor begge lag: snapshots til hurtige tilbagerulninger og commits til projektets permanente historik.

Hvordan forbedrer du tingene uden at ødelægge det, der allerede fungerer?#

Hver anden person bliver fanget i denne løkke. Du beder AI om at rette en lille fejl. Den foreslår en fornuftig ændring. Den ændring ødelægger noget andet. Du beder den rette det nye problem, og to problemer mere dukker op. Og sådan fortsætter det.

Løkken opstår, fordi vibe coding er ikke-deterministisk. Den samme prompt giver dig forskellig kode to gange. Derfor kan hver redigering lydløst forskyde den omgivende logik: Rabatgrænsen flytter sig fra 10 til 12 procent, eller en valideringsregel ændrer sin adfærd – uden at du kontrollerer noget og uden en eneste advarsel. Det kaldes logisk drift, og den skader lydløst præcis det, der skaber indtægter: priser, adgang og betalinger.

Der er én regel, som beskytter mod drift, og den er enkel nok til at hænge op på væggen: Commit ikke kode, som du ikke kan forklare ord for ord til en anden person.

I praksis bliver dette til en færdig ramme, du kan bruge før enhver ændring af kode, der fungerer. Den får AI til at tage små skridt og vise dig præcis, hvad der ændrede sig.

Gør dette, før du ændrer koden:

Gem den nuværende fungerende tilstand som et separat tilbagegangspunkt (commit).

Beskriv præcist med ord, hvad du planlægger at ændre, og i hvilke filer.

Lav den mindst mulige ændring – kun det, der løser min opgave, intet ekstra.

Vis mig, hvad der blev ændret, og forklar hver ændring, så jeg kunne forklare den til en anden person.
Rør ikke ved logik for priser, adgang eller betaling, medmindre jeg har bedt dig om det.

Et andet princip, der sparer uger, er disciplin omkring opgavegrænser. Ét problem, én ændring, hurtig implementering. Bed ikke AI om at omskrive halvdelen af projektet i én prompt. Professionelle udviklere begynder nogle gange at bygge en hel Uber, når de kun havde brug for én knap – og trækker det ud i månedsvis. Det behøver du ikke.

Alt, jeg beskriver, bygger på én ting: kontekststyring. For at forhindre AI i at ødelægge nærliggende logik skal den huske projektets regler.

Hvordan kontrollerer du en ændring, før du offentliggør den?#

Mellem “det virker på min computer” og “det virker for alle” er der et mellemtrin, som begyndere springer over: en testkopi. Det er et separat snapshot af produktionsmiljøet, hvor du kontrollerer en ændring, før rigtige mennesker ser den. Arbejdscyklussen ser sådan ud:

1. Byg og kontrollér ændringen selv (udvikling).
2. Deploy den til staging – en kopi af produktion, men uden rigtige brugere.
3. Gennemgå de vigtigste scenarier, og sørg for, at intet har ændret sig.
4. Først nu deployer du den til produktion.

Hvorfor er dette vigtigt efter lanceringen? Hver udgivelse indebærer en risiko. En lille kodeændring kan ødelægge login. Én manglende indstilling kan slå hele produktet ud. Staging fanger disse problemer uden konsekvenser; i produktion mister du kunder.

For at undgå at kontrollere alt manuelt hver gang kan du give AI en prompt, der sammenligner den nye versions adfærd med den gamles på de kritiske områder.

Jeg er ved at deploye en ændring. Gennemgå produktets vigtigste scenarier i rækkefølge, og kontrollér, at hvert stadig fungerer som før:

Registrering og login for nye brugere.

Betaling og tildeling af adgang efter betaling.

Adgangsrettigheder – en almindelig bruger kan ikke se andres data eller adminområdet.

Vigtige tal i forretningslogikken (priser, rabatter, grænser) er ikke ændret.
Hvis noget opfører sig anderledes end i den tidligere version, så stop og vis mig præcis, hvad der er ændret.

Hvor er dine hemmeligheder? Nybegynderens største sikkerhedshul#

Jeg forklarer det største minefelt i detaljer, fordi det rammer flere produkter end noget andet. Når AI skriver kode, er det nemmest at lægge en nøgle dér, hvor den virker med det samme – direkte i koden til siden, der åbnes i browseren. Du bemærker ikke forskellen under udviklingen. Men alle kan læse alt, der når browseren, ved at åbne udviklerværktøjerne.

Grundlæggeren, hvis kunder blev opkrævet $87,500, sagde senere, at én enkelt prompt kunne have forhindret det. Opkrævningerne blev til sidst tilbageført, men gebyrer, der ikke kunne refunderes, og den mistede ro i sindet blev tilbage. Her er den prompt.

Gennemgå hele projektet, og sørg for, at ingen hemmelig nøgle ender i browseren:

Find alle nøgler til databasen, betalingssystemet og eksterne tjenester.

Sørg for, at hver nøgle kun opbevares på serveren i miljøvariabler og ikke i sidens kode.

Kontrollér projektets historik – er en nøgle ved et uheld kommet med tidligere?
Vis mig en liste over alle steder, hvor du fandt hemmeligheder, og hvad der skal gøres ved hver enkelt.

Det næste nærliggende minefelt er kun at kontrollere adgangsrettigheder i browseren. Hvis dit produkt afgør, om det skal “vise adminområdet”, i sidens kode, kan alle omgå den beslutning. Adgangsrettigheder skal altid kontrolleres på serveren. Databasen skal kun returnere data til dem, der har ret til dem – det er det, sikkerhed på rækkeniveau (RLS) er til for, og den skal være aktiveret på hver tabel.

Før du sælger adgang eller lukker andre ind, skal du udføre en generel sikkerhedsrevision af produktet.

Gennemgå projektet som en angriber, og find sikkerhedshuller:

Er der hemmelige nøgler i kode, der sendes til browseren, eller i projektets historik?

Er sikkerhed på rækkeniveau (RLS) aktiveret på hver databasetabel, og kontrolleres adgangsrettighederne på serveren frem for kun i browseren?

Er automatisk sikkerhedskopiering af databasen konfigureret, og har jeg nogensinde kontrolleret, at jeg kan gendanne fra den?

Er produktionsdatabasen isoleret fra det miljø, hvor AI-agenten kører?
Fortæl mig for hvert punkt, om alt er i orden, eller præcis hvad der skal rettes.

Der findes en separat, fuld guide til sikkerhed ved vibe coding: Sådan sikrer du en app bygget med vibe coding. Reglen er enkel: Betragt alt, AI har gjort som standard, som usikret, indtil du har kontrolleret andet.

Hvor skal du hoste dit produkt: hostingtrappen#

Du behøver ikke straks leje din egen server og konfigurere den manuelt – det er en kompliceret opgave i begyndelsen og vil æde din tid. Der er en trappe, du kan gå op ad, efterhånden som produktet vokser:

1. Gratis hosting (for eksempel Vercel) – til dig selv, test og små projekter. Det virker, hvis platformen er tilgængelig for din målgruppe, og du ikke opbevarer folks persondata.
2. En platform med deployment i én kommando (Railway) – når du har en backend og en database. Du deployer med én kommando og behøver ikke konfigurere en server. Tærsklen for at komme i gang er minimal.
3. Din egen dedikerede server – når belastningen er høj, og du har brug for fuld kontrol. Flyt til den senere, når du har nået platformens grænse.

For en ikke-programmør, der lige har lanceret, er den nemmeste løsning en platform med deployment i én kommando uden manuel serverkonfiguration. Flyt til din egen server senere. Hvis du vil følge denne vej med et konkret eksempel, kan du se guiden om at deploye et vibe-kodet projekt på din egen server med Coolify.

Hvornår skal du adskille appen, databasen og sikkerhedskopierne?#

Tre ting bør ikke ligge i samme kurv: appen, databasen og sikkerhedskopierne. Mens der er få brugere, ligger alt samlet, og det er fint. Men der er et tydeligt tegn på, hvornår det er tid til at adskille dem.

• Placér appen og databasen på forskellige maskiner. Tegnet: Ved spidsbelastning bliver CPU- og hukommelsesforbruget ved med at ligge over 70–80 procent, forespørgslerne bliver langsommere, og appen og databasen kæmper om de samme ressourcer. Når de er adskilt, kan du styrke databasen uden at røre appen og omvendt.
• Følg 3-2-1-reglen for sikkerhedskopiering. Tre kopier af dataene, på to forskellige medietyper, hvoraf én opbevares et andet sted. Det beskytter mod hardwarefejl og ransomware. Det vigtigste er, at sikkerhedskopierne laves automatisk.

Hvor ofte du skal tage sikkerhedskopier, afhænger af, hvor dyrt det er at miste data fra flere timer. For en online abonnementstjeneste, hvor tab af en times betalingsposter er uacceptabelt, skal backupintervallet være kortere end en time, eller der skal være verificerede transaktionslogs og gendannelse til et bestemt tidspunkt (PITR). Vælg intervallet efter maksimalt tolerabelt datatab, og test særskilt den tid, der kræves for at gendanne tjenesten. Én gang om dagen er nok for en blog. Logikken er enkel: Beslut, hvor mange data du har råd til at miste, og konfigurér sikkerhedskopieringen derefter.

Hjælp mig med at afgøre, om det er tid til, at mit produkt flytter til en mere seriøs infrastruktur. Kontrollér hvert punkt, og spørg mig om det:

Hvor belastede er CPU og hukommelse ved spidsbelastning – bliver forbruget ved med at ligge over 70–80 procent eller ej?

Ligger databasen og appen på samme maskine eller på forskellige maskiner?

Er automatisk sikkerhedskopiering af databasen konfigureret, og har jeg testet at gendanne fra den?

Findes der en separat kopi af miljøet (staging), hvor ændringer kan kontrolleres før deployment?
Giv mig ud fra resultaterne en klar anbefaling: hvad der skal forblive, som det er, hvad der først skal skilles ud, og hvorfor.

Der er et separat spørgsmål: administreret database eller din egen. For et lille team er en administreret database næsten altid bedst: din egen er billigere i hardware, men sluger timer til vedligeholdelse. Hvis du er alene, og dit produkt ikke handler om infrastruktur, koster de timer mere end forskellen i serverpris.

Hvordan sætter du vedligeholdelsen på autopilot?#

Manuel vedligeholdelse er udmattende. Du kan slippe for den på to måder: overvågning og en patruljerende agent.

Overvågning bruger to forskellige værktøjer til to forskellige opgaver:

1. “Er webstedet oppe?” – en oppetidsovervåger (for eksempel UptimeRobot). Den pinger produktet med få minutters mellemrum og sender en advarsel, hvis det går ned. Der findes et gratis abonnement.
2. “Hvad gik der præcis i stykker?” – en fejlsporing (for eksempel Sentry). Den indsamler fejl inde i appen og viser, hvor og hvorfor noget mislykkedes.

Den første opdager, at produktet er gået ned. Den anden viser, hvilken funktion der fejlede, og hvorfor. Tilsammen besvarer de spørgsmålet: “Får jeg besked om en fejl, før en kunde skriver til support?”

Det andet niveau af autopilot er en patruljerende agent. Forestil dig et ejendomsmæglerfirma: Klokken syv om morgenen læser en AI-agent henvendelser på webstedet, ser, at bookingformularen er i stykker, finder årsagen i koden og kommer tilbage med en færdig rettelse og en forklaring. Du gennemgår den og siger “ja” – så deployer den. Rækkefølgen betyder noget: Løs først brugerens problem (giv adgang, sig undskyld), og undersøg derefter årsagen og pengene.

Endnu en regel for AI’s adgang til produktionsdatabasen: Giv den en bruger med skrivebeskyttet adgang, og skjul persondata bag et mellemlag, så agenten ser “navn” i stedet for personens rigtige navn. Så kan den fysisk set ikke slette eller ødelægge produktionsdata, selv hvis den laver en fejl. Hændelsen i tabellen ovenfor, hvor en agent slettede produktionsdatabasen, handler præcis om, at denne begrænsning manglede. Guiden Hvad gør du, hvis AI slettede din database forklarer, hvad du skal gøre, hvis katastrofen allerede er sket.

Hvornår er det tid til at lukke et produkt?#

Den mest undervurderede del af vedligeholdelse er at vide, hvornår man skal holde op med at vedligeholde. Alle, der bygger meget, har en kirkegård af projekter: Man byggede ét, puslede med det og opgav det så. Det er normalt og ikke en fiasko. Fiaskoen er at slæbe rundt på noget, ingen bruger, i månedsvis, fordi man fortryder den tid, man har brugt.

Tærskler, du kan bruge til at træffe beslutningen:

1. To uger – nok til at se, om en idé virker. Hvis de første rigtige brugere vender tilbage, så fortsæt. Tavshed er et svar.
2. Tre måneder – den hårde grænse. Hvis den ikke har fået momentum på tre måneder, så luk den. Med vibe codings hastighed er det for lang tid at bruge seks måneder på at teste én idé.

Det er psykisk svært at lukke et projekt, så behandl det som en beslutning, ikke en følelse. At give slip på et projekt, du har investeret i, er som at fyre en medarbejder, der ikke kan udføre jobbet: Ubehageligt, men det koster mere at beholde vedkommende end at lade vedkommende gå.

Vedligeholdelse er arbejde, der udføres for at holde et produkt i live og nyttigt for mennesker. Alt andet – git, sikkerhedskopier og overvågning – er blot værktøjer, der hjælper dig frem til det punkt, hvor produktet begynder at arbejde for dig hver dag.

At bygge et produkt med AI på en aften er halvdelen af arbejdet. At holde det i live og sikkert, efterhånden som det vokser – det er det, vibe coding for voksne betyder.

Til dit næste skridt – Ailoot.