Genskrive eller redde din AI-app? En beslutningsguide

Om du skal genskrive din AI-app eller redde den, afgøres mest af to ting: om datamodellen holder, og om du kan ændre én funktion uden at to andre går i stykker. Holder fundamentet, er det næsten altid billigst at rydde op i den kode du har, og er fundamentet forkert, er det billigst at genskrive tidligt.

Jeg tjener penge på både oprydning og genskrivning, så læs med det forbehold. Kriterierne nedenfor er dem jeg selv bruger, og de er skrevet så du kan bruge dem uden at kunne læse kode.

Den korte version: redd eller genskriv?

Min tommelfingerregel: er datamodellen sund, redder jeg koden, også selvom resten er rodet. Er datamodellen forkert og appen skal vokse, genskriver jeg, og jo færre brugere der er, jo billigere bliver det. Peger tabellen i begge retninger, er svaret oftest en gradvis udskiftning.

Skal din prototype i drift for første gang, så start med min guide til at gøre en AI-app klar til rigtige brugere. Denne guide tager det næste spørgsmål: hvad gør du når koden ikke kan bære det appen skal kunne?

Hvad det vil sige at redde og at genskrive

At redde en app betyder at du beholder koden og forbedrer den trin for trin. Det dækker typisk tre slags arbejde: at lukke sikkerhedshuller, at refaktorere koden (strukturere den om uden at ændre hvad den gør) og at skrive automatiske tests, så fremtidige ændringer ikke vælter noget. Appen er i drift hele vejen.

At genskrive betyder at du bygger appen igen i en ny kodebase, ofte i et etableret framework som Laravel eller Next.js, og flytter brugere og data over når den nye version er klar. Prototypen bliver ikke smidt ud. Den bliver specifikationen, fordi den viser hvilke skærme, flows og regler appen skal have.

Mellem de to findes en tredje vej, som mange overser: gradvis udskiftning. Du bygger en ny backend ved siden af den gamle og flytter én funktion ad gangen, fx login først og betaling bagefter. Martin Fowler kalder mønstret strangler fig efter en figenart der langsomt vokser rundt om sit værtstræ. Det tager længere tid end en ren genskrivning, men appen virker hele vejen, og du kan stoppe når resten er godt nok.

Seks kriterier der afgør om koden kan reddes

Gå kriterierne igennem i rækkefølge. De første fire handler om koden, de sidste to om din forretning.

Datamodellen

Datamodellen er måden appen gemmer sine data på: hvilke tabeller der findes, og hvordan de hænger sammen. Den er det vigtigste kriterium, fordi alt andet bygger ovenpå. En skærm kan skrives om på et par dage. En forkert datamodel smitter af på hver eneste forespørgsel, rapport og integration.

Typiske tegn på problemer: kundens navn står både på ordren og på kunden og er nu forskelligt de to steder, hele objekter er gemt som tekst i ét felt i stedet for i rigtige kolonner, eller der mangler en tabel til noget forretningen kredser om, fx abonnementer eller teams. AI-værktøjerne bygger datamodellen én prompt ad gangen, og ingen har tegnet den samlede model på forhånd.

En datamodel kan godt rettes uden en genskrivning, men så skal data migreres, og al kode der bruger tabellerne, skal tilpasses. Rammer problemet kernen af appen, er det tit her en genskrivning bliver billigst.

Ændringer rammer der hvor du forventer

Bed om en lille ændring, fx et nyt felt på en formular, og se hvad der sker. I sund kode bliver ét eller to steder ændret. I kode der er vokset prompt for prompt, ligger den samme logik ofte i flere varianter, og AI-værktøjet retter kun nogle af dem.

Det er den kendte prompt-løkke: du retter én fejl og får to nye. Den kan brydes med refaktorering og tests, hvis strukturen nedenunder er nogenlunde fornuftig. Er der ingen struktur at genkende, skal en udvikler alligevel forstå og omskrive det meste, og så er du tæt på en genskrivning uanset hvad du kalder det. Tegnene er beskrevet nærmere i 10 tegn på at du skal stoppe med at prompte og hyre en udvikler.

Hvor sikkerhedshullerne sidder

Regn med at en AI-bygget app har sikkerhedshuller. Veracode testede kode fra over 100 sprogmodeller og fandt at 45 % af kodeeksemplerne indeholdt sårbarheder fra OWASP Top 10, den kendte liste over de mest udbredte sikkerhedsfejl i webapps. Huller er altså forventelige og i sig selv ikke et argument for at genskrive.

Spørgsmålet er hvor de sidder. Lokale huller kan lukkes i den eksisterende kode: en Supabase-tabel uden adgangsregler (Row Level Security), en API-nøgle i frontend-koden eller en formular der ikke tjekker input. Supabases egen dokumentation advarer om at en tabel uden RLS kan læses og ændres via API'et. Det skal rettes med det samme, men det er en afgrænset opgave. Bruger du Lovable, så gå tjeklisten til Lovable og Supabase igennem først.

Strukturelle huller er sværere. Er det koden i browseren der afgør om en bruger må se en faktura eller ændre en pris, skal den logik flyttes til en server. I en lille app er det en oprydning. I en stor app er det reelt en ny backend. Du kan se de typiske fund i oversigten over sikkerhedshuller i AI-genereret kode.

Om koden kan køre uden for værktøjet

De fleste AI-værktøjer lader dig eksportere koden eller synkronisere den til GitHub, men det er ikke det samme som at den kan køre andre steder. Tjek om der er afhængigheder der kun virker inde i værktøjet, om miljøvariabler og nøgler er beskrevet, og om en udvikler kan starte appen på sin egen maskine ud fra en vejledning.

Kan koden flyttes og køres, er en redning realistisk. Er appen bundet til værktøjets egen hosting eller indbyggede tjenester på en måde der ikke kan løsnes, er du allerede halvvejs i en genskrivning.

Hvad appen skal kunne om et år

Kig 12 måneder frem. Skal appen mest have flere skærme og små forbedringer, kan næsten enhver kodebase bære det efter en oprydning. Skal den have abonnementsbetaling, roller og rettigheder, integrationer til andre systemer eller flere kunder i samme system, stiller det krav til fundamentet som en prototype sjældent er bygget til.

Her tjener en genskrivning sig ofte hjem. Du betaler mere nu, men hver af de kommende funktioner bliver billigere at bygge, fordi du ikke skal arbejde uden om gamle valg.

Rigtige brugere og data

Har appen ingen eller få brugere, er en genskrivning forholdsvis billig: der er ingen data at flytte og ingen der mærker overgangen. Har du betalende kunder, skal en genskrivning også dække datamigrering, flytning af brugerkonti og en plan for selve skiftet. Det gør skiftet dyrere og mere risikabelt. Med mange brugere peger jeg oftere på redning eller gradvis udskiftning, selv når koden er dårlig.

Hvad koster de to veje?

Første faktura er den mindste del af regnestykket. Sammenlign i stedet hvad hver vej koster over de næste 12 måneder, inklusiv den udvikling du alligevel skal lave.

En redning koster mindre nu og kommer hurtigere i gang. Til gengæld betaler du en løbende afgift, hvis strukturen stadig er svag: hver ny funktion tager længere tid, og flere fejl slipper igennem. Afgiften er lille i sund kode og stor i rodet kode.

En genskrivning koster mere nu. Du betaler for ny kode, datamigrering, test og en periode hvor to versioner skal holdes i live. Til gengæld bliver det billigere at bygge videre bagefter, og det er lettere at finde en udvikler der kan overtage en almindelig Laravel- eller Next.js-app end en kodebase som ingen har tegnet.

Som et groft skøn koster en grundig oprydning en brøkdel af en genskrivning af den samme app. Men hvis oprydningen kun er den første af mange, vender regnestykket hurtigt.

Én ting har ændret sig de seneste år: når en udvikler bruger AI-værktøjer, går selve kodningen hurtigere. Det der stadig tager tid, er afklaring, datamigrering og test. En genskrivning er derfor billigere end den var, men den er ikke gratis.

Sådan træffer du beslutningen i fem trin

1. Stop med at bygge nyt i en kort periode. Hver funktion du prompter ind nu, skal enten ryddes op eller genskrives senere. Det er billigere at vente et par uger end at bygge mere på et fundament du måske skifter ud.
2. Få koden ind i dit eget repository. Et repository er et kodearkiv med hele historikken. Synkronisér eller eksportér koden til en GitHub-konto som din virksomhed ejer. Så kan en udvikler læse den, og du er ikke afhængig af ét værktøj.
3. Få en afgrænset teknisk vurdering. Bed en udvikler gennemgå datamodel, sikkerhed, struktur, afhængigheder og om appen kan køre lokalt. For en typisk prototype er det et arbejde på dage, ikke uger. Resultatet skal være en skriftlig anbefaling med begrundelse.
4. Regn begge veje igennem over 12 måneder. Tag listen over det appen skal kunne det næste år, og få et skøn på redning plus den udvikling der følger, og på genskrivning plus den samme udvikling.
5. Beslut hvordan du skifter, ikke kun hvad. Vælger du redning, så start med sikkerhed, derefter tests og til sidst struktur. Vælger du genskrivning, så beslut om det sker i ét skift eller bid for bid, og hvordan brugere og data bliver flyttet.

Hvis du genskriver: sådan undgår du at starte forfra

Det klassiske argument mod genskrivninger kommer fra Joel Spolsky, der i år 2000 kaldte det at skrive koden forfra for den værste strategiske fejl en softwarevirksomhed kan begå. Hans pointe er at gammel kode rummer mange års fejlrettelser fra virkeligheden, og at de forsvinder når man starter forfra. Det gælder stadig for et system der har kørt i ti år. En prototype bygget på få uger med AI har langt mindre skjult viden, og den viden der findes, kan du se direkte i appen.

Sådan får du mest ud af den viden:

• Brug prototypen som specifikation. Gennemgå hver skærm og hvert flow, og skriv ned hvad der skal med, og hvad der kan droppes. Brugernes adfærd i prototypen er mere værd end nogen kravspecifikation.
• Vælg en kedelig og veldokumenteret stak. Laravel og Next.js har store fællesskaber og mange udviklere, så du ikke står alene bagefter. Jeg har sammenlignet dem i Laravel eller Next.js til dit projekt.
• Hold omfanget fast. Nye funktioner venter til den nye version er i drift. Ellers bliver genskrivningen aldrig færdig.
• Planlæg datamigreringen fra første dag. Test den med en kopi af rigtige data, ikke med testdata.
• Overvej at gøre det bid for bid. Starter du med de dele der volder flest problemer, får du værdi før hele genskrivningen er færdig.

Hvornår du ikke skal bruge penge på nogen af delene

Nogle apps skal hverken reddes eller genskrives. Har appen endnu ingen betalende brugere, og er du stadig ved at finde ud af hvad den skal kunne, så fortsæt med at prompte. Kodekvalitet er ikke din flaskehals endnu. Er du på vej til at skifte retning, så vent også. Der er ingen grund til at rydde op i en app du alligevel skal smide ud om tre måneder.

Det samme gælder et internt værktøj for en håndfuld kolleger. Virker det, kan rodet kode være god nok. Indsamler appen persondata eller betalingsoplysninger, skal sikkerhedshullerne dog lukkes.

Har du allerede en udvikler i huset der kender koden, er det ofte bedre at give vedkommende tid til en oprydning end at hente en ekstern ind, mig inklusiv.

Næste skridt

Vælger du at redde appen, bliver det løbende arbejde vigtigere end selve oprydningen, så læs også om hvad vedligehold af AI-genereret kode koster over tid. Vil du have hjælp til vurderingen eller selve arbejdet, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende apps.

Ofte stillede spørgsmål

Kan jeg selv rydde op i koden med Cursor eller Claude Code?+

Delvist, og det kan spare tid, men kun hvis nogen styrer arbejdet. AI-værktøjer er gode til afgrænsede omskrivninger, fx at samle dobbeltkode eller dele store filer op. Uden automatiske tests opdager du dog ikke hvad der går i stykker undervejs. Start med tests omkring de vigtigste flows, og lad en udvikler gennemgå ændringerne før de går i drift.

Skal jeg skifte væk fra Supabase hvis jeg genskriver?+

Ikke nødvendigvis. Supabase er bygget på Postgres, en almindelig database som både Laravel og Next.js kan bruge direkte. Det er ofte fornuftigt at beholde databasen, rydde op i tabellerne og flytte forretningsreglerne ind i en rigtig backend. Om du skal flytte helt, afhænger af pris, hvor dine data skal ligge, og hvor mange af Supabases egne tjenester du bruger.

Mister mine brugere deres login ved en genskrivning?+

Ikke hvis skiftet er planlagt. Brugerkonti og data kan som regel flyttes med, men login kræver mest omtanke, fordi adgangskoder er gemt som hash, en envejskodet værdi, som det nye system skal kunne genkende. Alternativet er at bede brugerne vælge en ny adgangskode ved første login. Beslut på forhånd hvilken løsning du vil bruge, og test den med en kopi af rigtige data.

Hvad skal en teknisk vurdering af en AI-app indeholde?+

Den skal som minimum dække datamodel, sikkerhed, struktur, afhængigheder og om appen kan køre uden for AI-værktøjet. Hvert fund skal have en vurdering af hvor alvorligt det er, og hvad det koster at rette. Til sidst skal der stå en klar anbefaling: redning, gradvis udskiftning eller genskrivning, med en begrundelse du kan vise til andre.