Den største barriere for modernisering er ikke at skrive ny kode – det er at forstå den gamle

Historisk har valget næsten givet sig selv. At erstatte betød mere arbejde, mere risiko og mere ukendt terræn end at bygge videre, så det rationelle svar var at bygge videre. Igen. AI er ved at ændre det regnestykke.

At kode kan skrives hurtigere, er en del af forklaringen - men det er ikke dét, der for alvor rykker balancen mellem de to valg.

Det samme valg, gentaget

En tilpasning er sjældent en fejl. Ofte er den netop det rigtige valg: en afgrænset ændring på kendt grund med lav risiko og hurtig levering.

Problemet er gentagelsen. Hver ændring gøres så lokal som muligt for at holde risiko og omkostninger nede, og over tid vokser kompleksiteten og den tekniske gæld, mens arkitekturen glider væk fra de behov, systemet skal understøtte i dag.

Slutstadiet kender de fleste. Den dag hele systemet skal erstattes bliver det ikke noget, I vælger, men noget, I tvinges til - på det tidspunkt hvor systemet er sværest at forstå, og hvor de mennesker, der byggede det, måske for længst er videre.

Jeres billede af et system kommer primært fra to kilder.

Dokumentationen beskriver systemet, men er delvist forældet: hver tilpasning har flyttet systemet, uden at dokumentationen fulgte med.

Menneskers viden blegner og forsvinder med dem, der skifter job. Selv tilsammen dækker de to kilder kun en del af systemet.

Resten findes kun i systemet selv: forretningsregler, dataafhængigheder og historiske beslutninger, ingen længere kan redegøre for. Det er vidensgabet - skjult viden, der hverken er beskrevet eller husket.

Figur 1: Dokumentationen og menneskelig viden dækker kun en del af systemet og rager samtidig ud over det – den del, der rager ud, er ikke længere korrekt. Resten af systemet er vidensgabet: skjult viden, der hverken er beskrevet eller husket.

Ved en lille, lokal ændring kan man leve med gabet. Ved en stor erstatning er det projektets største risiko, for det er her, overraskelserne kommer fra. Jo større ændring, desto dyrere bliver manglende forståelse.

Vil I erstatte systemet uden overraskelser, er den første opgave at gøre den skjulte viden synlig. Det er et styret analysearbejde - AI er motoren, et erfarent team sætter retningen.

AI kan systematisk gennemgå det materiale, løsningen faktisk består af: kildekode, database, logfiler, konfiguration, integrationer - og versionshistorikken, hvor hensigten bag en ændring nogle gange stadig kan findes. Analysen udleder forretningsregler, afhængigheder og funktionalitet og beskriver dem i en form, forretningen kan forstå og efterprøve. User stories og regler frem for endnu et teknisk dokument.

Formen afgør, om analysen kan bruges til noget. Konklusionerne skal kunne lægges på bordet foran forretningen og udfordres, for AI erstatter ikke forretningens vurdering - den kvalificerer dialogen. Undervejs dukker der typisk steder op, hvor systemet ikke gør det, alle troede. Dem vil I hellere finde nu end efter go-live.

Synlig viden gør først nytte, når den bliver til krav. Kæden ser sådan ud:

Figur 2: Forstå, verificér, fastfrys, erstat – den gamle løsnings opførsel bliver krav til den nye.

Først verificerer mennesker den udledte viden - især forretningsreglerne og den forventede adfærd. Det er her, forretningen skiller tingene ad: regler, der skal bevares; fejl, der skal rettes; og regler, der er korrekte, men ikke længere relevante og derfor skal ud. Ellers ender gamle fejl - og døde regler - som krav i den nye løsning.

Derefter fastfryses den gamle løsnings opførsel: Ud fra den validerede viden genererer AI automatiske tests og golden masters, altså referencekørsler der dokumenterer, hvordan systemet faktisk svarer i dag.

Testene er ikke dokumentation. De er krav til den nye løsning. AI bygger den nye løsning med dem som rettesnor, og de kører løbende under udviklingen, så I opdager det med det samme, hvis noget vigtigt går tabt.

Logikken er enkel: Jo bedre forståelse, desto bedre specifikation og tests - og desto mere selvstændigt kan AI arbejde inden for de rammer.

Testene dækker den kendte adfærd; nye krav og undtagelser kræver stadig, at mennesker tager stilling.

Hos os består opsætningen af Claude Code som motor, styret af en erfaren udvikler. Modellen får adgang til systemet gennem værktøjer og MCP-integrationer (Model Context Protocol) - kodeanalyse, opslag i databasen, søgning i logs - så den kan undersøge løsningen, ikke kun læse den. Analyserne kører efter en fastlagt plan med specialiserede skills til fx domæneafdækning og testgenerering, og alt dokumenteres i samme struktur med sporbarhed tilbage til kilden.

Værktøjerne skifter i takt med, at feltet udvikler sig. Det blivende er rammerne: faste formater, en plan for analysen og mennesker, der vurderer resultatet.

Først og fremmest adgang til det materiale, analysen skal bygge på: kildekoden, databasen og helst også logs, konfiguration og versionshistorik. Og skal adfærden fastfryses som tests, skal systemet kunne køres i et kontrolleret miljø, hvor referencekørslerne kan gentages.

Derudover skal indsatsen passe til opgaven. Tilgangen er et rammeværk, ikke en fast pakke: Handlinger og værktøjer skaleres efter løsningens størrelse og kompleksitet. Et lille, overskueligt system kræver en let analyse, mens et stort system med forretningslogik, ingen har det fulde billede af, kræver hele værktøjskassen.

Skal løsningen erstattes af et standardsystem, er situationen en anden - dér er det de fremtidige processer, ikke den gamle adfærd, der skal styre kravene.

AI fjerner ikke risikoen ved at erstatte, og tilpasning er stadig ofte det rigtige valg. Men når den skjulte viden i systemet kan hentes frem, fastfryses den nuværende adfærd som test og hver konklusion kan føres tilbage til kilden, skrumper afstanden mellem de to valg.

Figur 3: Afstanden mellem tilpas og erstat – før og nu

Det ændrer på, hvornår I kan modernisere. I behøver ikke vente på, at den tekniske gæld træffer valget for jer - I kan foretage større ændringer tidligere, mens I stadig har handlefrihed.