Jeg bygde et produkt med AI – slik gjør du forbedringer uten å ødelegge det som fungerer

Les mer om å jobbe med modeller i Ailoot-dokumentasjonen.

Hvorfor begynner det dyreste arbeidet etter lansering?#

Du bygde en app på en kveld, publiserte en lenke og sendte den til vennene dine. Den fungerer. Så, en uke senere, dukker den første virkelige brukeren opp, klikker på noe på feil måte, og halvparten av funksjonene slutter å virke. Du ber Claude fikse det – den fikser én ting og ødelegger en annen. Høres det kjent ut?

Og det er da hovedspørsmålet dukker opp: Hva gjør du etter at du har lansert et produkt, når euforien over den første fungerende prototypen har lagt seg, og du fortsatt må vedlikeholde det på et eller annet vis? Du kan kalle det vibe coding for voksne. Bygging handler om spenning og fart. Vedlikehold krever et kaldt hode: Du forstår hva du endrer og holder det under kontroll. De fleste mislykkes i denne andre delen fordi ingen forbereder dem på den.

En bransjeundersøkelse analyserte over én million kodeendringer fra 2 444 team og beregnet hvor pengene som brukes på AI-utvikling faktisk går. Slik ser det ut:

Guiden «Den skjulte kostnaden ved vibe coding» forklarer disse tallene mer inngående. Der var spørsmålet hva du betaler for. Her er spørsmålet et annet: 44 cent av hver dollar går til å fikse feil – og hele denne artikkelen handler om å hindre at den andelen vokser. Arbeidet med å holde den i sjakk kalles vedlikehold.

Forskjellen mellom noen som driver med vibe coding for voksne, og noen som bare passer på et nevralt nettverk, viser seg etter lansering. Den førstes kodebase vokser, de gjør forbedringer, og ingenting går i stykker. En måned senere har den andres produkt blitt en lekk konstruksjon som de er redde for å røre. Nå forklarer jeg hvordan du kan havne i den første gruppen.

Hva går egentlig galt: 5 katastrofer etter lansering#

Dette er offentlige postmortem-rapporter om virkelige produkter bygget med AI, med tall og datoer. Tenk på dem som et kart over et minefelt – hver mine har allerede gått av for noen, og man vet hvordan man kommer seg rundt den.

Alle fem har samme grunnårsak. Som standard får AI ting til å fungere akkurat nå, ikke trygt om en måned under belastning. Du kan ikke se forskjellen mens du utvikler på datamaskinen din. Den blir tydelig når den første fremmede med dårlige hensikter dukker opp.

Problemet er ikke at koden ikke skrives for hånd – mange jobber på denne måten. Problemet er at ingen spør: «Er databasen sikret?» Nå skal jeg vise deg en spørsmålstekst som stiller dette spørsmålet for deg.

Det første sikkerhetsnettet er git og muligheten til å gå tilbake til «slik det var i går»#

Når Claude ødelegger noe, trenger du en knapp for å «sette det tilbake slik det var i går». Teknisk kalles den knappen git, og det er enklere enn det høres ut.

Tre begreper en ikke-programmerer bør forstå:

1. Repository – prosjektmappen din lagret i skyen (vanligvis på GitHub). En kopi av all koden din som ikke bare ligger på datamaskinen.
2. Commit – et tilbakegangspunkt. Du sier egentlig til koden: «lagre denne tilstanden». Hver commit er et merke du kan gå tilbake til.
3. Deploy – en flytting. Koden var lokal på datamaskinen din og fungerte bare for deg. Deploy sender den til en ekstern server, slik at den fungerer for alle.

Så lenge du har nylige commit-punkter, kan du rulle tilbake enhver feil med én setning. Bokstavelig talt.

Jeg har ødelagt noe – alt fungerte i går, men ikke i dag. Finn den siste commiten der alt var i orden, vis meg hva som har endret seg siden da, og rull prosjektet tilbake til den tilstanden.

To regler du bør innføre med en gang, før andre ser produktet:

• Repository-et må være privat. Ikke offentlig. Ellers kan hvem som helst lese koden din og alt som ligger i den.
• Legg filen med hemmeligheter på ignoreringslisten. Nøkler, passord og tilgangsopplysninger til databasen ligger i en egen fil (vanligvis .env), og den filen skal aldri inn i repository-et. Legg til en linje for .env i .gitignore, så blir hemmelighetene hos deg.

Det finnes en egen guide til trygg tilbakestilling av endringer i Claude Code: Slik tilbakestiller du endringer i Claude Code. Uten tilbakepunkter balanserer du på en line uten sikkerhetsnett, og før eller siden faller du.

Hva ruller /rewind tilbake, og hva gjør den ikke?#

Claude Code tar et øyeblikksbilde av tilstanden før hver endring den gjør. Kommandoen /rewind (eller å trykke Esc to ganger) ruller både filer og samtalen tilbake til et valgt punkt. Det er praktisk: Hvis du ødela en funksjon for fem minutter siden, kan du gå fem minutter tilbake.

Men det finnes en felle som får nybegynnere til å miste data. /rewind ruller ikke tilbake alt:

Anthropic sier det selv rett ut: Øyeblikksbilder er en lokal «angre»-knapp, mens git er permanent historikk. Øyeblikksbilder utfyller versjonskontroll, men erstatter den ikke.

Det praktiske poenget for en ikke-programmerer: /rewind redder deg fra «Claude ødela nettopp en funksjon». Men hvis Claude rakk å slette en rad i en database eller laste opp kode til skyen, er det bare git og en sikkerhetskopi av databasen som kan få den tilbake. Behold derfor begge lagene: øyeblikksbilder for raske tilbakestillinger, commits for prosjektets permanente historikk.

Hvordan gjør du forbedringer uten å ødelegge det som allerede fungerer?#

Annenhver person havner i denne løkken. Du ber AI fikse en liten feil. Den foreslår en fornuftig endring. Den endringen ødelegger noe annet. Du ber den fikse det nye problemet, og to problemer til dukker opp. Og så videre.

Løkken oppstår fordi vibe coding er ikke-deterministisk. Den samme spørsmålsteksten gir forskjellig kode to ganger. Hver redigering kan derfor i det stille forskyve logikken rundt: rabattgrensen flyttes fra 10 til 12 prosent, eller en valideringsregel endrer oppførsel – uten at du kontrollerer noe eller får én eneste advarsel. Dette kalles logisk drift, og det skader i det stille nettopp de tingene som gir inntekter: priser, tilgang og betalinger.

Det finnes én regel som beskytter mot drift, og den er enkel nok til å henge på veggen: Ikke commit kode du ikke kan forklare ord for ord til en annen person.

I praksis blir dette en ferdig mal du kan bruke før enhver endring i fungerende kode. Den får AI til å ta små steg og vise deg nøyaktig hva som ble endret.

Gjør dette før du endrer koden:

Lagre den nåværende fungerende tilstanden som et eget tilbakepunkt (commit).

Beskriv med ord nøyaktig hva du planlegger å endre, og i hvilke filer.

Gjør den minst mulige endringen – bare det som løser oppgaven min, ikke noe ekstra.

Vis meg hva som ble endret, og forklar hver endring slik at jeg kan forklare den til en annen person.
Ikke rør prising, tilgang eller betalingslogikk med mindre jeg ber deg om det.

Et annet prinsipp som sparer uker, er disiplin rundt oppgavegrenser. Ett smertepunkt, én endring, rask gjennomføring. Ikke be AI skrive om halve prosjektet i én prompt. Profesjonelle utviklere begynner noen ganger å bygge en hel Uber når de bare trengte én knapp – og bruker måneder på det. Det trenger ikke du.

Alt jeg beskriver, bygger på én ting: å håndtere kontekst. For at AI ikke skal ødelegge logikken rundt, må den huske prosjektreglene dine.

Hvordan kontrollerer du en endring før du publiserer den?#

Mellom «det fungerer på datamaskinen min» og «det fungerer for alle» finnes et mellomtrinn nybegynnere hopper over: en testkopi. Det er et separat øyeblikksbilde av produksjonsmiljøet der du kontrollerer en endring før virkelige mennesker ser den. Arbeidssyklusen ser slik ut:

1. Bygg og kontroller endringen selv (development).
2. Deploy den til staging – en kopi av produksjon, men uten virkelige brukere.
3. Kjør de viktigste scenarioene og kontroller at ingenting har endret seg.
4. Først nå deployer du den til produksjon.

Derfor er dette viktig etter lansering: Hver utgivelse innebærer risiko. En liten kodeendring kan ødelegge innloggingen til en konto. Én manglende innstilling kan slå ut hele produktet. Staging fanger opp slike problemer uten konsekvenser; i produksjon mister du kunder.

For å slippe å kontrollere alt manuelt hver gang kan du gi AI en spørsmålstekst om å sammenligne den nye versjonens oppførsel med den gamle på kritiske områder.

Jeg skal til å deploye en endring. Gå gjennom produktets viktigste scenarioer i rekkefølge, og kontroller at hvert av dem fortsatt fungerer som før:

Registrering av ny bruker og innlogging.

Betaling og tilgang etter betaling.

Tilgangsrettigheter – en vanlig bruker kan ikke se andres data eller administratorområdet.

Viktige tall i forretningslogikken (priser, rabatter, grenser) er ikke endret.
Hvis noe oppfører seg annerledes enn i forrige versjon, stopp og vis meg nøyaktig hva som ble endret.

Hvor er hemmelighetene dine? Nybegynnerens største hull#

Jeg forklarer den største landminen grundig fordi den rammer flere produkter enn noe annet. Når AI skriver kode, er det enkleste å legge en nøkkel der den fungerer med en gang – rett i koden til siden som åpnes i nettleseren. Du merker ikke forskjellen under utviklingen. Men hvem som helst kan lese alt som når nettleseren ved å åpne utviklerverktøyene.

Grunnleggeren som fikk kunder belastet for $87,500, sa senere at én enkelt spørsmålstekst kunne ha forhindret det. Belastningene ble til slutt reversert, men de ikke-refunderbare gebyrene og den tapte sinnsroen var der fortsatt. Her er den spørsmålsteksten.

Kontroller hele prosjektet og sørg for at ingen hemmelige nøkler havner i nettleseren:

Finn alle nøkler til databasen, betalingssystemet og eksterne tjenester.

Sørg for at hver av dem bare lagres på serveren, i miljøvariabler, og ikke i sidekoden.

Kontroller prosjektets historikk – har en nøkkel ved et uhell havnet der tidligere?
Vis meg en liste over alle stedene der du fant hemmeligheter, og hva som må gjøres med hver av dem.

Den neste landminen i nærheten er å kontrollere tilgangsrettigheter bare på nettlesersiden. Hvis produktet avgjør i sidekoden om det skal «vise administratorområdet», kan hvem som helst omgå den avgjørelsen. Tilgangsrettigheter må alltid kontrolleres på serveren. Databasen skal bare sende data tilbake til dem som har rett til dem – det er dette row-level security (RLS) er til for, og den må aktiveres på hver tabell.

Før du selger tilgang eller slipper andre inn, bør du gjennomføre en generell sikkerhetsrevisjon av produktet.

Gå gjennom prosjektet som en angriper, og finn sikkerhetshull:

Ligger noen hemmelige nøkler i kode som sendes til nettleseren eller i prosjektets historikk?

Er row-level security (RLS) aktivert på hver databasetabell, og kontrolleres tilgangsrettigheter på serveren i stedet for bare i nettleseren?

Er det konfigurert automatisk sikkerhetskopiering av databasen, og har jeg noen gang kontrollert at jeg kan gjenopprette fra den?

Er produksjonsdatabasen isolert fra miljøet der AI-agenten kjører?
Fortell meg for hvert punkt om alt er i orden, eller nøyaktig hva som må fikses.

Det finnes en egen, fullstendig guide om sikkerhet ved vibe coding: Slik sikrer du en app bygget med vibe coding. Regelen er enkel: Behandle alt AI har gjort som usikret som standard, helt til du har kontrollert det.

Hvor bør du hoste produktet ditt: hostingstigen#

Du trenger ikke leie din egen server og konfigurere den manuelt med en gang – det er en komplisert oppgave i starten og vil spise av tiden din. Det finnes en stige du kan klatre opp etter hvert som produktet vokser:

1. Gratis hosting (for eksempel Vercel) – for deg selv, tester og små prosjekter. Det fungerer hvis plattformen er tilgjengelig for målgruppen din, og du ikke lagrer personopplysninger.
2. En plattform med deploy med én kommando (Railway) – når du har en backend og en database. Du deployer med én kommando og trenger ikke konfigurere en server. Terskelen for å komme i gang er minimal.
3. Din egen dedikerte server – når belastningen er høy og du trenger full kontroll. Gå over til dette senere, når du har nådd plattformens grense.

For en ikke-programmerer som nettopp har lansert, er det enklest å bruke en plattform med deploy med én kommando uten manuell serverkonfigurasjon. Gå over til din egen server senere. Hvis du vil følge denne veien med et konkret eksempel, kan du se guiden om å deploye et vibe-kodet prosjekt på din egen server med Coolify.

Når bør du skille appen, databasen og sikkerhetskopiene fra hverandre?#

Tre ting bør ikke ligge i samme kurv: appen, databasen og sikkerhetskopiene. Når det er få brukere, ligger alt sammen, og det er greit. Men det finnes et tydelig signal på når det er på tide å skille dem.

• Plasser appen og databasen på forskjellige maskiner. Signalet: Ved toppbelastning holder CPU- og minnebruken seg over 70–80 prosent, forespørsler går tregere, og appen og databasen kjemper om de samme ressursene. Når du har skilt dem, kan du styrke databasen uten å røre appen, og omvendt.
• Følg 3-2-1-regelen for sikkerhetskopier. Tre kopier av dataene, på to forskjellige typer medier, hvorav én oppbevares et annet sted. Dette beskytter mot maskinvarefeil og løsepengevirus. Det viktigste er at sikkerhetskopiene tas automatisk.

Hvor ofte du bør ta sikkerhetskopi, avhenger av hvor kostbart det er å miste data fra flere timer. For en nettbasert abonnementstjeneste der tap av én time med betalingsregistreringer er uakseptabelt, må intervallet være kortere enn én time, eller du trenger verifiserte transaksjonslogger og punktvis gjenoppretting (PITR). Velg intervallet fra maksimalt akseptabelt datatap, og test gjenopprettingstiden separat. Én gang om dagen er nok for en blogg. Logikken er enkel: Bestem hvor mye data du har råd til å miste, og konfigurer sikkerhetskopiene deretter.

Hjelp meg med å avgjøre om tiden er inne for at produktet mitt flytter til en mer robust infrastruktur. Kontroller hvert punkt og spør meg om det:

Hvor belastet er CPU og minne ved toppbelastning – holder bruken seg over 70–80 prosent eller ikke?

Ligger databasen og appen på samme maskin eller på forskjellige maskiner?

Er automatisk sikkerhetskopiering av databasen konfigurert, og har jeg testet å gjenopprette fra den?

Finnes det en separat kopi av miljøet (staging) for kontroll før deployment?
Gi meg en tydelig anbefaling basert på resultatene: hva som kan forbli som det er, hva som bør skilles ut først, og hvorfor.

Et annet spørsmål er om du skal bruke en administrert database eller din egen. For et lite team er en administrert database nesten alltid best: Din egen er billigere når det gjelder maskinvare, men den krever timer med vedlikehold. Hvis du jobber alene og produktet ditt ikke handler om infrastruktur, koster disse timene mer enn forskjellen i serverpris.

Hvordan setter du vedlikeholdet på autopilot?#

Manuelt vedlikehold er slitsomt. Du kan slippe det fra deg på to måter: overvåking og en patruljeagent.

Overvåking bruker to forskjellige verktøy til to forskjellige oppgaver:

1. «Er nettstedet oppe?» – en oppetidsmonitor (for eksempel UptimeRobot). Den pinger produktet med noen minutters mellomrom og sender et varsel hvis det går ned. Det finnes et gratis abonnement.
2. «Hva er det som faktisk gikk i stykker?» – en feilsporer (for eksempel Sentry). Den samler inn feil i appen og viser hvor og hvorfor noe feilet.

Det første verktøyet fanger opp at produktet har gått ned. Det andre viser hvilken funksjon som feilet og hvorfor. Sammen besvarer de spørsmålet: «Får jeg vite om en feil før en kunde skriver til brukerstøtten?»

Det andre nivået av autopilot er en patruljeagent. Se for deg et eiendomsmeglerkontor: Klokken sju om morgenen leser en AI-agent henvendelser på nettstedet, ser at bestillingsskjemaet er ødelagt, finner årsaken i koden og gir deg en ferdig løsning med en forklaring. Du går gjennom den og sier «ja» – så deployes den. Rekkefølgen er viktig: Løs først brukerens problem (gi tilgang, beklag), og undersøk deretter årsaken og pengene.

En regel til om AI-ens tilgang til produksjonsdatabasen: Gi den en bruker med skrivebeskyttet tilgang, og skjul personopplysninger bak et mellomlag slik at agenten ser «navn» i stedet for personens virkelige navn. Da vil den, selv om den gjør en feil, fysisk ikke kunne slette eller ødelegge produksjonsdata. Hendelsen i tabellen ovenfor, der en agent slettet produksjonsdatabasen, handler nettopp om at denne begrensningen manglet. Guiden Hva gjør du hvis AI slettet databasen din forklarer hva du skal gjøre hvis katastrofen allerede har skjedd.

Når er det på tide å legge ned et produkt?#

Den mest undervurderte delen av vedlikehold er å vite når du skal slutte å vedlikeholde. Alle som bygger mye, har en kirkegård av prosjekter: De bygde ett, fiklet med det og forlot det så. Det er normalt, og det er ikke et nederlag. Nederlaget er å dra med seg noe ingen bruker i månedsvis fordi man angrer på tiden man brukte.

Terskler du kan bruke når du skal ta avgjørelsen:

1. To uker – nok til å se om en idé fungerer. Hvis de første virkelige brukerne kommer tilbake, fortsett. Stillhet er også et svar.
2. Tre måneder – den absolutte grensen. Hvis den ikke har tatt av innen tre måneder, legg den ned. Med farten i vibe coding er det for lenge å bruke seks måneder på å teste én idé.

Det er psykologisk vanskelig å avslutte et prosjekt, så behandle det som en beslutning, ikke en følelse. Å gi slipp på et prosjekt du har investert i, er som å si opp en ansatt som ikke klarer jobben: Det er ubehagelig, men det koster mer å beholde vedkommende enn å la dem gå.

Vedlikehold er arbeidet med å holde et produkt i live og nyttig for folk. Alt annet – git, sikkerhetskopier, overvåking – er bare verktøy som hjelper deg fram til punktet der produktet begynner å jobbe for deg hver dag.

Å bygge et produkt med AI på én kveld er halve jobben. Å holde det i live og sikkert mens det vokser – det er det vibe coding for voksne betyr.

Neste steg for deg – Ailoot.