Når en app bygget med AI virker på skærmen, er det fristende at åbne for kunderne med det samme. Den sikre rækkefølge er en anden. Stop nye funktioner, og få koden over i egne konti. Gennemgå derefter login og adskillelsen mellem kunder, flyt hemmelige nøgler væk fra det, browseren kan læse, og få data og backup på plads. Først derefter tager I stilling til, om I skal bygge videre på koden, eller om prototypen skal bruges som specifikation til en ny version. Rækkefølgen betyder noget, for hvert trin bygger på det forrige.
Trin 1: Stop nye funktioner
Det sværeste trin er det første. Hver ny funktion lægger mere oven på noget, ingen endnu har set efter. Sæt en dato, hvor der kun rettes, og fortæl de første brugere, at der kommer en pause. En kort pause koster sjældent det, man frygter, og den giver ro til at se, hvad I faktisk har.
Skriv samtidig ned, hvad appen gør. Hvilke brugertyper findes, hvilke data opbevares, og hvilke andre tjenester taler den med? Listen bliver grundlaget for alt det næste, og ofte opdager stifteren her funktioner, der ikke længere bruges.
Trin 2: Få produktet over i egne konti
Koden skal ligge i et repository, altså et versionsstyret lager for kode, som virksomheden selv ejer. Det samme gælder database, domæne og konti hos betalingstjenester. Står noget i stifterens private navn, flyttes det nu. Hvad der kan flyttes ud af de enkelte værktøjer, står i at få koden ud af værktøjet. Fra nu af skal alle ændringer kunne ses og rulles tilbage.
Trin 3: Gennemgå login og adskillelse af kunder
Her ligger den største risiko. Autentificering er spørgsmålet om, hvem du er. Autorisation er spørgsmålet om, hvad du må. AI-værktøjer laver ofte en fin loginside og er dårligere til det andet. Spørg:
- Tjekkes rettigheder på serveren, eller kun i det, brugeren ser i browseren?
- Kan kunde A nå kunde B’s data ved at ændre et id i en adresse?
- Har databasen regler, der håndhæver adskillelsen, og har nogen læst dem?
- Hvad kan en bruger, der ikke er logget ind?
Lav prøven i praksis med to testkonti. De kendte svagheder er beskrevet i eftersyn af AI-genereret kode. I de fleste tilfælde skal en erfaren udvikler læse denne del af koden, hvis ingen hos jer kan det. Det er en opgave for en, der kan læse kode, og hvis I skal lede efter en, er freelancer, bureau eller eget team et godt sted at starte.
Trin 4: Flyt nøgler
En nøgle er en hemmelig tekststreng, der giver adgang til en tjeneste. Ligger en hemmelig nøgle i den kode, der sendes til browseren, kan den læses af alle. Nøgler skal ligge på serveren i en beskyttet opbevaring, og de nøgler, der har ligget åbent, skal udskiftes. At flytte dem er ikke nok, for I ved ikke, hvem der allerede har set dem. Fremgangsmåden står i nøgler og adgangskoder i koden.
Trin 5: Få data og backup på plads
Vælg, hvor data skal ligge, og tjek, at der tages backup. Prøv derefter at læse backuppen ind i et separat miljø. Først da ved I, at den virker. Tænk også på persondata: hvad gemmer I, hvor længe, og hvordan sletter I en kunde? Den tekniske side er beskrevet i persondata i produktet, og selve gendannelsen i kan I genskabe produktet.
Indfør samtidig et testmiljø, så nye ændringer prøves et andet sted end hos kunderne, og en simpel overvågning, der fortæller jer, at appen er nede, før kunderne gør det.
Trin 6: Byg videre, eller brug prototypen som specifikation
Når I kender tilstanden, kan I træffe den egentlige beslutning. Som generel viden taler disse tegn for at bygge videre på koden:
- Datamodellen passer til forretningen, og kundeadskillelsen kan rettes uden at lave alt om.
- En erfaren udvikler kan læse koden og finde rundt i den.
- Ændringer ét sted vælter sjældent noget andet.
- Teknologien er almindelig, så I kan finde folk, der vil arbejde med den.
Disse tegn taler for at bygge forfra og bruge prototypen som specifikation:
- Adgangsreglerne er spredt ud over hele koden og kan ikke rettes samlet.
- Samme logik findes mange steder i lidt forskellige udgaver.
- Hver rettelse skaber nye fejl, også for dem, der kan kode.
- Produktet er låst til en platform, der ikke passer til de krav, I møder.
At starte forfra er intet nederlag. Prototypen har svaret på, hvad kunderne vil have, hvilke skærmbilleder de forstår, og hvad der ikke virkede. En ny version bygges meget hurtigere, når de spørgsmål er besvaret. Pas på med at lade de samme tekniske beslutninger gentage sig: den nye version skal starte med datamodel og adgangsregler, som nogen har taget stilling til, se teknologivalg til MVP’en.
Beslutningen er ledelsens, og den bør tages på grundlag af det, de første trin har vist. Bed derfor den, der har læst koden, om at give begrundelser, I selv kan forstå, og vær opmærksom på, at en leverandør, der skal have opgaven bagefter, har en interesse i svaret.
Det skal I lade være med
· At bede AI’en om at gøre appen sikker og regne sagen for løst. Værktøjet kan hjælpe. Et menneske skal efterprøve resultatet.
· At flytte nøgler uden at udskifte dem. Gamle nøgler skal gøres ugyldige.
· At vente med backup til efter lanceringen. Data fra de første kunder er lige så vigtige som alle andre.
· At træffe beslutningen om omskrivning uden at have set koden. Mavefornemmelser er dyre i begge retninger.
Det skal I kræve af den eksterne
- ☐ En plan for trinene med ansvarlige og rækkefølge.
- ☐ Et overblik over konti, nøgler og data, og hvem der ejer dem.
- ☐ En begrundet anbefaling om at bygge videre eller starte forfra, skrevet uden fagord.
- ☐ Klare kriterier for, hvornår I må åbne for betalende kunder.
- ☐ Besked om, hvem der skal læse koden, hvis den eksterne ikke selv gør det.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Vibe coding: hvad er det? · Første version er leveret
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
