Mars 2024. En kollega fra Rocksoft og jeg blir med i et prosjekt – en solid applikasjon som har kjørt i årevis. Det viser seg raskt å være bygget på Vue 2, hvis end of life var 31. desember 2023, et kvartal tidligere. Rammeverket er offisielt uten vedlikehold: det mottar ikke lenger sikkerhetsoppdateringer. Og likevel installerer det fortsatt, bygget passerer, "det fungerer." Det er 2026 nå, og prosjektet er fortsatt på Vue 2.
Det er kjernen i problemet: "det fungerer" er en midlertidig tilstand. Vi tar på oss teknisk gjeld i bytte mot en kortsiktig gevinst – en raskere lansering, én ny funksjon – men den bærer renter, og de rentene vokser med hver måned av forsinkelse. Denne artikkelen handler om hva den risikoen egentlig er, og hvordan AI endrer regnestykket for å betale den ned.
Hva det koster
Gjeld er ikke en budsjettpost noen bevisst godkjenner. Det er gapet mellom hva et system burde koste å vedlikeholde og hva det faktisk koster.
Omfanget er reelt: utviklere i gjennomsnittsbedriften bruker omtrent en tredjedel av tiden sin på å betjene gjeld i stedet for å bygge nye funksjoner. For et team på ti personer tilsvarer det mer enn tre heltidsstillinger i året, konsumert av usynlig overhead.
Hvorfor virksomheten utsetter det, og hvorfor det er en feil
En ny funksjon har et ansikt: du kan vise den til en kunde. Å migrere til en nyere rammeverkversjon har ingen. Når det er gjort, fungerer applikasjonen nøyaktig det samme – bortsett fra at det spiste uker med arbeid. Å utsette ser derfor rasjonelt ut, men det er feil på to nivåer.
For det første betyr "ikke rør det" ikke "ingenting skjer." Umaintained avhengigheter akkumulerer nye sårbarheter som ingen vil oppdatere, nettlesere pensjonerer API-er, og dokumentasjonen og svarene på nett refererer til versjoner to generasjoner nyere. Å vedlikeholde en død teknologistakk er programmering med en lommelykt i et arkiv.
For det andre vokser utsettelse selve gjelda. Hver funksjon lagt til på toppen av et utdatert fundament er ny kode som skal skrives om senere. Migreringsmålet venter ikke på stedet – det vokser med hver sprint.
Og til slutt venter et paradoks: det forsømte fundamentet begynner å blokkere de samme funksjonene det ble forsømt for. I prosjektet vårt var bibliotekene som trengs for å utvide én av funksjonene bare tilgjengelige for den nyere rammeverkversjonen. Så så lenge vi ble på Vue 2, forble den funksjonen utenfor rekkevidde.
To ansikter av risikoen
Når gjelda vokser for stor, kan regningen komme på én gang – og det gjør vondt.
Equifax (2017): angripere kom inn gjennom en kjent sårbarhet i Apache Struts som det hadde eksistert en oppdatering for i måneder, men som aldri ble distribuert. Rundt 147 millioner poster med persondata lekket. Det er den klassiske kostnaden ved å ikke oppdatere, og lite har endret seg siden – ettersom nesten alle Struts-nedlastinger fortsatt går til ikke-støttede versjoner i dag.
The axios-angrepet (2026) viser det motsatte ansiktet: "hold alt oppdatert" er heller ikke en fripass til sikkerhet. I et forsyningskjedeangrep kapret angripere vedlikeholderkontoen til ett av de mest populære JavaScript-bibliotekene og sendte ut ondsinnede utgivelser som lastet ned en fjerntilgangs-trojaner ved installasjon. Det som sviktet her var ikke passivitet, men automatisering. Pull requests fra avhengighetsoppdateringsroboter bærer en implisitt tillit og har en tendens til å bli vinket gjennom uten granskning – og den ondsinnede endringen spredte seg på tvers av offentlige repositorier på minutter.
Lærdommen fra begge tilfeller: oppdateringer krever oppmerksomhet, ikke bare hyppighet. Risikoen ligger like mye i å stå stille som i å rase fremover blindt.
End of life handler ikke bare om manglende funksjoner
End of support betyr fremfor alt ingen flere sikkerhetsoppdateringer. Og ikke bare for ramverkets kjerne, men for hele økosystemet av programtillegg rundt det, som dør sammen med det. Hver slik avhengighet er et separat, umaintained stykke angrepsflate.
Så kommer etterlevelse: mange team kan ikke lansere ikke-støttet programvare på grunn av klausuler i SLA-er og kontrakter, og "det fungerer, så vi lar det være" kan til slutt kollidere med en revisjon.
Betalt utvidet støtte er noen ganger tilgjengelig, men det er en krykke. Det kjøper bare tid for det uunngåelige: migrering.
Hvordan AI endrer regnestykket
Hovedargumentet for å utsette – "migrering er uker vi ikke har" – har nettopp sluttet å være sant.
Klassiske roboter (Dependabot, Renovate) oppdager utdaterte pakker og åpner PR-er, men de fikser ikke bruddsendringer. Ved større API-skifter etterlater de deg et rødt bygg å løse for hånd. Språkmodeller (Claude, Codex) går et skritt lenger: de utfører den faktiske transformasjonen av koden til den nye rammeverkversjonen. McKinsey anslår at generativ AI i applikasjonsmodernisering akselererer tidslinjer med 40 til 50 % og kutter gjeldsrelaterte kostnader med rundt 40 %.
Nøkkelen er verifikasjonsløkken, som lukker gapet mellom "koden kompilerer" og "koden fungerer i nettleseren." Ved å koble modellen til en nettleser gjennom MCP (f.eks. Playwright eller Chrome-servere), leser modellen, etter å ha skrevet om en visning, konsollen selv, fanger opp kjøretidsfeil og advarsler, og fikser koden før et menneske noensinne ser den.
Et motargument er nødvendig: AI er ikke en autopilot. Modeller kan "hallusinere" avhengigheter – noen ganger med navn som er ondsinnet registrert – og maskinegenerert kode faller i den samme implisitte tillitsfellen som robot-PR-er. Det er mye av det, det ser solid ut, så det er fristende å vinke det gjennom uten gjennomgang. AI senker kostnaden ved å gjennomføre migreringen, ikke kostnaden ved å forstå hva som kommer inn i prosjektet. Mennesket som gjør kodegjennomgang, forblir det viktigste elementet – særlig gitt forsyningskjederisikoen.
I praksis
Start med synlighet: en revisjon av avhengighetene dine og en fullstendig liste over hva som faktisk kommer inn i prosjektet (en SBOM), inkludert transitive avhengigheter.
Hold automatisering i bånd. Robot-PR-er går under menneskelige øyne, en nedkjølingsperiode for ferske utgivelser, automatisk sammenslåing høyst for små oppdateringer med testdekning. Behandle AI som en overvåket migreringsakselerator, ikke en uovervåket utfører.
Den vanskeligste delen er vanligvis samtalen med virksomheten – og det er her ingeniøren har en tendens til å tape, fordi de snakker om "oppdateringer" når de burde snakke om risiko og kostnad: et rammeverk uten sikkerhetsoppdateringer, kontraktuelle klausuler, en tredjedel av teamets tid tapt til gjeld.
Og siden kostnaden ved selve migreringen nettopp har falt, trenger det gamle "vi har ikke råd til det" å beregnes på nytt fra bunnen av.
Teknisk gjeld forsvinner ikke av seg selv. Men med de riktige verktøyene kan du endelig slutte å betale bare rentene og begynne å betale ned på hovedstolen – før den vokser utover hva du kan håndtere.
