AI sin beste avkastning nå er å fikse gammel kode, ikke å skrive ny kode

Hver gang jeg ser en AI-produkt demo, starter det på samme måte: en tom prompt-boks, en forespørsel på vanlig engelsk, og en fungerende app noen minutter senere. Det er en virkelig imponerende ferdighet. Det er også, ville jeg argumentere, det minst interessante som skjer i bedriftens AI-bransje for øyeblikket.

Det mer betydningsfulle arbeidet skjer et sted langt mindre glamorøst: inne i femten år gamle kodebaserte systemer som ingen ønsker å berøre, skrevet av ingeniører som forlot selskapet for ti år siden, og som kjører forretningslogikk som ingen har fullstendig forstått på år. De fleste AI-omtaler får dette feil. Arv-kode er ikke teknisk gjeld. Det er akkumulert forretningsintelligens: årtier med beslutninger, kodet som programvare, med de personene som tok disse beslutningene lenge borte.

Grønne felt-utvikling får keynote-plassene. Den gamle koden får penger, motvillig, og vanligvis uten den forståelsen som trengs for å bruke dem godt.

Den virkelige mangelen er ikke utviklere, det er minne

Dette er ikke et isolert problem. En studie fra 2025 utført av Pegasystems, gjennomført av forskningsfirmaet Savanta over mer enn 500 IT-beslutningstakere verden over, estimerer at den gjennomsnittlige globale bedriften kaster bort mer enn $370 million årlig gjennom sin evne til å effektivt modernisere arv-systemer, med nesten $134 millioner av dette knyttet til langsomme, ressurskrevende transformasjonsprosjekter alene.

Vi arbeidet nylig med et batteridistribusjonsselskap som kjørte mer enn femten arv-applikasjoner, den type spredning som akkumuleres over tyve år med fusjoner, enkelt-integrasjoner og ingeniører som løser dagens problem uten mye tanke for morgendagens. Begravet i denne koden var priser, lagertrøskler og distribusjonsbegrensninger som representerte år med institusjonelle beslutninger, skrevet ned ingen steder enn i logikk som ingen hadde fullstendig kartlagt.

Det er fristende å kalle dette et talentproblem: anssett flere utviklere, migrer raskere. Men du kan ikke ansatte deg ut av faktum at personen som forstod hvorfor en modul fungerte på en bestemt måte, forlot selskapet i 2014. De fleste bedrifter lider av en minne-mangel, ikke et talent-mangel. Og før nylig var det ingen virkelig måte å løse dette på en skala. Du måtte betale en håndfull senior-ingeniører for å holde den institusjonelle kunnskapen i hodet deres uendelig, eller du mistet den dagen de forlot.

Hva AI faktisk endrer

Vi pekte ikke en kode-generering-verktøy mot den gamle kodebasen og sa til den å omskrive alt; det er omtrent hvordan du stille og quiett sletter forretningslogikk du ikke visste eksisterte. I stedet brukte vi AI-agenter til å gjøre det uglamorøse grunnarbeidet først: spore hvordan de femten-plus-applikasjonene faktisk var koblet til hverandre, overflate beslutningene som var innbygget i logikken som aldri var skrevet ned andre steder, og holde fast på den konteksten som noe organisasjonen kunne spørre om, ikke noe som bare bodde i en enkelt ingeniørs hode. Dette stemmer overens med hva andre AI-leverandører nå dokumenterer offentlig: Anthropics veiledning om å modernisere COBOL-systemer med Claude Code beskriver samme sekvensering, automatisering av utforsknings- og analysefasene først, i stedet for å hoppe rett til omskriving.

Agentene ble ikke karakterisert av hvor mye kode de genererte. De ble karakterisert av hvor mye institusjonell kunnskap de kunne overflate og bevare. Ingeniører arbeidet deretter sammen med dem på den faktiske migrasjonen og test-genereringen, og sjekket agentenes tolkning av forretningslogikk mot hvordan systemet oppførte seg i produksjon, ikke bare stole på det. Et nyttig signal vi så etter: om agentens forklaring av en regel matchet en mønster vi kunne uavhengig verifisere i produksjonslogger, eller om det var et plausibelt lydende gjetting? Gapet mellom disse to er nettopp hvor arv-moderniseringsprosjekter vanligvis går galt.

Den opprinnelige anslaget for prosjektet var åtte og en halv måned. Det ble avsluttet på fire måneder, en reduksjon på 53%. Men den mer varige utfallet var ikke tidsrammen. Institusjonell kunnskap som tidligere forsvant hver gang en ingeniør forlot selskapet, ble noe organisasjonen faktisk kunne beholde.

Programvare-ingeniører har brukt tiår på å skrive programvare. Det neste tiåret kan bli brukt til å grave det ut, med AI som fungerer mindre som en forfatter og mer som en arkeolog, som omsorgsfullt rekonstruerer begrunnen som er begravet i kode som overlevde personene som skrev det.

En grov ramme for å gjøre dette uten å bryte ting

Prosjektene som går bra, synes å følge omtrent samme sekvens, uansett om systemet er en pris-motor eller en krav-pipeline:

Oppdag: kart hvordan systemene faktisk er koblet til hverandre, ikke hvordan arkitektur-diagrammet fra 2016 sier de er koblet til.

Forstå: la agenten overflate forretningslogikken og antagelsene bak den, på vanlig språk en domene-ekspert kan sjekke.

Verifiser: sjekk at tolkningen motvirker virkelig produksjons-atferd, ikke bare mot kode-kommentarene.

Transformér: migrer eller bygg om bare når de første tre fasene holder, med mennesker som eier godkjenningen.

Hopp rett til Transformér, og du moderniserer ikke. Du gambler med logikk du ikke forstår ennå.

Hvorfor dette betyr noe utover ingeniør-team

Institusjonell minne forsvinner ikke bare stille og rolig når en senior-ingeniør går av med pensjon. Det blir en akutt skade når en bedrift kan minst ønske det: under en fusjon, når en ny eier må forstå hva de faktisk kjøpte; under en ERP-migrasjon, når gammel logikk må oversettes korrekt til et nytt system første gang; under en etterlevelse-undersøkelse eller hendelses-svar, når noen må forklare hvorfor systemet oppførte seg på en bestemt måte, under en tidsfrist, til en regulator som ikke vil akseptere “personen som bygget det forlot i 2014” som et svar.

Behandlet på denne måten, stopper arv-modernisering å være en ingeniør-post og begynner å se ut som en organisatorisk motstands-spørsmål, som betyr at det ikke bare er CTO-er som bør bry seg. Det er CIO-er som veier hva som skjer når nøkkel-teknisk personale slutter, M&A-team som prøver å pris hva de faktisk kjøper, og styre som tenker på hvor mye av selskapets operasjonelle kunnskap eksisterer ingen steder enn i kode som ingen nåværende leser.

Den viktigste forbeholdet

Ingenting av dette fungerer uten oppsyn. Den riskieste versjonen av denne tilnærmingen er en hvor en agents tolkning av gammel forretningslogikk blir stole på uten verifisering, fordi arv-systemer er nettopp stedet hvor en selv-sikker feil AI-antagelse koster mest. Full autonomi på din nyeste mikro-tjeneste er et rimelig valg. Full autonomi på prisen-motoren som ingen har berørt siden 2011, er ikke. Verdien er at AI gjør det mulig å bli, igjen, ingeniørene som forstår bedriften, på et system som ingen nåværende forstår. Det erstatter dem ikke.

Hvor jeg tror dette går neste

I tyve år har bedrifter behandlet arv-programvare som noe å flykte fra: en kostnads-post å finansiere motvillig og modernisere bort så raskt som budsjett tillater. Jeg tror AI er på vei til å avsløre at mye av denne koden faktisk var en av de mest verdifulle kunnskaps-repositoryer bedriften noensinne bygget. Det trengte bare noe i stand til å lese det. Forskere dokumenterer allerede den andre siden av denne løkken: en 2026 multivokal litteratur-gjennomgang om LLM-assistert utvikling finner at dagens forfølgelse av AI-akselerert hastighet skaper selv “rask-integrasjons-gjeld”, kode sendt raskere enn det kan forstås. Arv-modernisering er bare denne regningen som kommer for tidlig, en generasjon tidlig.

Jeg ville være nysgjerrig på om andre teknologi- og ingeniør-ledere ser samme skift: viser avkastningen på din AI-investering seg mer i hva du bygger, eller i hva du endelig kan forstå og bevare? Og for alle som har prøvd å kjøre AI-agenter mot et virkelig gammelt, udokumentert system, hvor holdt agentens forståelse under verifisering, og hvor falt det stille sammen?