AI-genereret kode om 12 måneder: hvad koster vedligeholdet?

Vedligehold af AI-genereret kode koster typisk meget lidt de første måneder og mere for hver måned der går uden en plan. Det skyldes tre problemer der vokser stille i baggrunden: dubleret logik, manglende automatiske tests og pakker der går ud af support. Efter 12 måneder er regningen for en samlet oprydning ofte større end et års løbende vedligehold ville have været.

Jeg sælger selv vedligehold, så læs med det forbehold. Derfor skriver jeg også hvornår du ikke har brug for en aftale.

Den korte version: sådan udvikler de 12 måneder sig

Tabellen viser et typisk forløb, ikke en lov. Hvor hurtigt det går, afhænger af hvor meget appen bliver ændret. En app som ingen rører, forfalder langsomt, mens en app der får nye funktioner hver uge, kan nå måned 12 på et halvt år.

Min tommelfingerregel: har appen rigtige brugere, eller gemmer den data du ikke vil miste, skal den have en fast vedligeholdsrytme fra den dag den går i drift. Er den ikke i drift endnu, så start med guiden til at gøre en AI-app klar til produktion. Denne guide handler om det der sker bagefter.

Hvorfor AI-genereret kode bliver dyrere at eje over tid

Et AI-værktøj som Lovable, Bolt eller Cursor løser den opgave du beder om lige nu. Det er netop styrken. Men hver prompt bliver løst for sig, og ingen holder det samlede billede af koden. Skal værktøjet bruge en funktion der minder om en eksisterende, skriver det ofte en ny i stedet for at genbruge den gamle.

Det kan måles. GitClear analyserede 211 millioner ændrede kodelinjer fra 2020 til 2024. Andelen af kopieret kode steg fra 8,3 % til 12,3 %, mens andelen af flyttet kode, der typisk er et tegn på oprydning, faldt fra 25 % i 2021 til under 10 % i 2024. Tallene står i GitClears rapport om AI-assistenter og kodekvalitet.

Googles DORA-rapport for 2024 peger samme vej. Øget brug af AI fulgtes af et anslået fald i leveringsstabiliteten på 7,2 %, ifølge Googles opsummering af DORA-rapporten. Rapportens forklaring er at AI ikke erstatter det grundlæggende: små ændringer ad gangen og ordentlige tests.

Begge undersøgelser handler om professionelle udviklere, der læser og godkender koden før den går i drift. I en app der er bygget med prompts alene, er der ingen der gør det, så efter min vurdering er effekten større der. Koden kan sagtens være fin fra start. Problemet er at den bliver dårligere for hver ændring hvis ingen rydder op.

De tre problemer der vokser måned for måned

De tre problemer følges ofte ad, og de forstærker hinanden.

Dubleret logik

Dubleret logik betyder at den samme forretningsregel findes flere steder i koden. Det kan være beregningen af en fragtpris, reglen for hvem der må se en ordre, eller hvornår et abonnement udløber. Den første måned er det ligegyldigt, for alle versionerne gør det samme.

Problemet opstår når reglen skal ændres. Du beder AI-værktøjet om en ny fragtpris, og det retter de steder det kan se. Kurven viser nu den nye pris, mens fakturaen bruger den gamle. Sker det samme med en adgangsregel, er det ikke længere en fejl, men et sikkerhedshul.

Det er mekanismen bag den kendte prompt-løkke, hvor én rettelse skaber to nye fejl. Jeg har beskrevet tegnene i 10 tegn på at du skal stoppe med at prompte og hyre en udvikler.

Ingen automatiske tests

Automatiske tests er små programmer der kontrollerer at appen stadig gør det den skal, fx at en bruger kan logge ind, og at en betaling bliver registreret. De kører på få minutter, hver gang koden bliver ændret.

AI-værktøjer skriver sjældent tests af sig selv, og når du bygger med prompts, tester du ved at klikke rundt. Det holder så længe appen er lille. Efter et år er der for mange flows til at nogen tjekker dem alle i hånden før hver ændring, så det bliver ikke gjort. Fejlene bliver i stedet fundet af dine brugere.

Manglende tests gør også de to andre problemer dyrere. Uden tests er det risikabelt at samle dubleret logik og at opdatere pakker, så begge dele bliver udskudt.

Forældede pakker

En moderne webapp er bygget af pakker: færdige kodebiblioteker til login, datoer, betaling og brugerflade. Tæller du pakkernes egne afhængigheder med, er det ofte flere hundrede. De udgiver løbende nye versioner, og de gamle holder op med at få rettelser.

Frameworks har faste udløbsdatoer. Ifølge Laravels supportpolitik får hver hovedversion fejlrettelser i 18 måneder og sikkerhedsrettelser i 2 år. Mange JavaScript-pakker udgiver nye hovedversioner endnu oftere. På 12 måneder når en del af pakkerne i en typisk app nye hovedversioner, og nogle kan få offentlige sikkerhedsadvarsler.

AI-værktøjer kan desuden foreslå versioner der var aktuelle da modellen blev trænet, så appen kan være bagud allerede den dag den går i drift. Og da der ikke er tests, tør ingen opdatere, så springet vokser for hver måned. Forældede og opdigtede pakker er også et sikkerhedsproblem, som jeg gennemgår i oversigten over sikkerhedshuller i AI-genereret kode.

Hvad koster vedligeholdet? Et groft regneeksempel

Min tommelfingerregel for traditionelt udviklet kode er at budgettere med 10-20 % af udviklingsprisen om året til vedligehold. Den regel holder dårligt for en AI-bygget app fordi udviklingsprisen var lav. Har appen kostet et abonnement og nogle aftener, siger procenten ingenting om hvad den koster at holde ved lige. Regn i stedet i timer.

Timeprisen for en freelanceudvikler i Danmark ligger ifølge Lønradars oversigt over freelancetimepriser i 2026 typisk på 600-900 kr. for en udvikler med nogle års erfaring og 800-1.200 kr. for en senior, ekskl. moms. Med det udgangspunkt ser to forløb for en mindre app med betalende brugere groft sådan ud:

Timetallet er en antagelse til regneeksemplet, ikke en pris. En lille app med få integrationer kan klares med mindre, mens en app med betaling, roller og flere integrationer kræver mere. Det der især trækker op eller ned:

• Hvor ofte appen bliver ændret. Hver ny funktion øger behovet for tests og oprydning.
• Persondata og betaling. Et brud på persondatasikkerheden skal efter GDPR artikel 33 som udgangspunkt anmeldes til Datatilsynet inden for 72 timer, og oprydningen koster langt mere end forebyggelsen.
• Antal integrationer. Hver forbindelse til et andet system kan ændre sig uden varsel.
• Hvor langt appen allerede er bagud. Starter vedligeholdet efter et år, skal oprydningen betales først.

Den skjulte del af regnestykket er tiden. Uden vedligehold bliver hver ny funktion dyrere at bygge, og det tager af det budget du havde sat af til at udvikle produktet.

Sådan forebygger en retainer problemerne

En retainer er en fast månedlig aftale hvor en udvikler reserverer et antal timer til din app. Det du betaler for, er rytmen: små ting bliver gjort løbende før de vokser sig store. Sådan ser forløbet typisk ud i en god aftale:

1. Start med en gennemgang. Udvikleren laver en liste over pakker og versioner, kendte sårbarheder, de steder hvor logikken er dubleret, og de flows der ikke må gå i stykker. Det er grundlaget for resten.
2. Skriv tests omkring de vigtigste flows. Login, betaling og oprettelse af data kommer først. Målet er at de flows der tjener penge, bliver kontrolleret ved hver ændring. Fuld testdækning kan vente.
3. Sæt automatiske advarsler op. Værktøjer som Dependabot på GitHub foreslår selv opdateringer når nye versioner udkommer. Udvikleren gennemgår dem, og testene kører før noget går i drift.
4. Opdatér i en fast rytme. Små opdateringer hver måned, sikkerhedsrettelser med det samme og hovedversioner efter en plan med dato.
5. Ryd op der hvor du bygger. Hver gang en funktion bliver ændret, bliver den dublerede logik samlet ét sted. Så bliver koden bedre der hvor den faktisk bliver brugt, uden et stort oprydningsprojekt.
6. Gør status hvert kvartal. En kort skriftlig status over versioner, hændelser, kendte svagheder og næste skridt, så du ved hvor appen står.

Du kan godt blive ved med at bygge nye funktioner med AI-værktøjet undervejs. Forskellen er at koden ligger i et repository (kodearkiv) som din virksomhed ejer, og at en udvikler gennemgår ændringerne før de går i drift.

Hvad selve aftalen skal indeholde, fx responstider, pris og ansvar ved nedetid, har jeg samlet i guiden til en serviceaftale med en udvikler.

Hvornår du ikke har brug for en vedligeholdsaftale

Ikke alle AI-apps skal have en fast aftale, og det siger jeg gerne selvom jeg sælger dem.

• Prototypen har ingen rigtige brugere endnu. Er du stadig ved at finde ud af hvad appen skal kunne, så byg videre. Kodekvalitet er ikke din flaskehals.
• Det er et internt værktøj for få kolleger. Virker det, og indeholder det ikke persondata, kan rodet kode være god nok. Opdatér dog pakker med kendte sikkerhedshuller.
• Du skal alligevel genskrive appen. Der er ingen grund til at betale for at holde kode ved lige som du skifter ud om få måneder. Står du foran det valg, så brug beslutningsguiden til at genskrive eller redde en AI-app først.
• Du har en udvikler i huset. Så er det oftest bedre at give vedkommende tid til vedligehold end at hente en ekstern ind, mig inklusiv.

Næste skridt

Er din app allerede et stykke inde i de 12 måneder, så start med et overblik frem for en stor plan. Tjeklisten viser hvor du står.

Mangler du mere end to af punkterne, er det tid til en gennemgang. Du kan se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende apps, også dem der er bygget med AI.

Ofte stillede spørgsmål

Hvad er forskellen på en retainer og en timebank?+

En retainer er en fast månedlig aftale med reserverede timer og faste opgaver, fx opdateringer, overvågning og en kvartalsstatus. En timebank er forudbetalte timer som du bruger når du har brug for dem. Retaineren sikrer rytmen, mens timebanken giver fleksibilitet. Til en AI-bygget app i drift anbefaler jeg typisk en retainer det første år fordi problemerne netop opstår når ingen holder øje.

Hvor mange timer om måneden skal jeg aftale?+

Det afhænger af appen, og det bedste svar får du efter en gennemgang. Start med et forsigtigt skøn, og justér efter tre måneder når du kan se hvad tiden faktisk går til. Bliver timerne brugt på akutte fejl i stedet for forebyggelse, er aftalen for lille, eller der mangler tests. Står timerne ubrugte hver måned, kan du skrue ned.

Kan en anden udvikler overtage vedligeholdet senere?+

Ja, hvis koden ligger i dit eget repository, har tests og en kort beskrivelse af hvordan den sættes i drift. Det bør en vedligeholdsaftale efterlade dig med. Hos mig ejer kunden koden fra første dag, så du kan skifte uden at spørge om lov. Tjek også at alle adgange til hosting, database og eksterne tjenester står i virksomhedens navn.

Gælder det samme for kode som en udvikler har skrevet med AI?+

Mekanismen er den samme, men risikoen er mindre når en udvikler læser, tester og godkender koden før den går i drift. Mange professionelle udviklere bruger AI-værktøjer i dag. Spørg din udvikler hvordan AI-genereret kode bliver gennemgået, og om der bliver skrevet tests til den. Et konkret svar er et godt tegn, mens et vagt svar er en grund til at spørge mere.