AI:s bästa avkastning just nu är att fixa gammal kod, inte skriva ny kod

Varje AI-produkt-demo jag går igenom börjar på samma sätt: en tom prompt-ruta, en begäran på vanligt språk och en fungerande app efter några minuter. Det är ett riktigt imponerande party-trick. Det är också, skulle jag argumentera, det minst intressanta som händer inom företags-AI just nu.

Det mer betydelsefulla arbetet sker någonstans mycket mindre glamoröst: inuti femton år gamla kod-baser som ingen vill röra, skrivna av ingenjörer som lämnade företaget för ett decennium sedan, som kör affärslogik som ingen har fullständigt förstått på år. De flesta AI-omdömen får detta bakvänt. Äldre kod är inte teknisk skuld. Det är ackumulerad affärs-intelligens: årtionden av beslut, kodade som programvara, med de personer som fattade dessa beslut långt borta.

Grönfält-utveckling får keynote-platserna. Den gamla koden får pengarna, motvilligt, och vanligtvis utan den förståelse som behövs för att spendera dem väl.

Den verkliga bristen är inte utvecklare, det är minne

Detta är inte ett isolerat problem. En studie från 2025 av Pegasystems, genomförd av research-företaget Savanta över mer än 500 IT-beslutsfattare världen över, uppskattar att den genomsnittliga globala företaget slösar bort mer än 370 miljoner dollar per år genom oförmågan att effektivt modernisera äldre system, med nästan 134 miljoner dollar av det bundet till långsamma, resurs-intensiva transformationsprojekt ensamma.

Vi arbetade nyligen med ett batteridistributionsföretag som körde mer än femton äldre applikationer, den typen av spridning som ackumuleras under tjugo år av fusioner, enstaka integrationer och ingenjörer som löser dagens problem utan mycket tanke för morgondagen. Begraven i den koden fanns prissättningsregler, lagertrösklar och distributionsbegränsningar som representerade år av institutionella beslut, skrivna ner någonstans utom i logik som ingen hade fullständigt kartlagt.

Det är frestande att kalla detta för ett talangproblem: anställ fler utvecklare, migrera snabbare. Men du kan inte anställa dig ur faktum att personen som förstod varför en modul fungerade på ett visst sätt lämnade företaget 2014. De flesta företag lider av en minnesbrist, inte en talangbrist. Och tills nyligen fanns det ingen riktig lösning på detta i stor skala. Du antingen betalade en handfull seniora ingenjörer för att hålla den institutionella kunskapen i sina huvuden för alltid, eller så förlorade du den dagen de lämnade.

Vad AI faktiskt förändrar

Vi pekade inte en kod-genereringsverktyg mot den gamla kod-basen och sa åt den att skriva om allt; det är ungefär hur du tyst raderar affärslogik du inte visste existerade. Istället använde vi AI-agenter för att göra det oglamorösa grundarbetet först: spåra hur de femton plus-applikationerna faktiskt anslöt till varandra, yta de beslut som var inbäddade i logiken som aldrig hade skrivits ner någon annanstans, och hålla fast vid den kontexten som något organisationen kunde fråga, inte något som levde bara i en ingenjörs huvud. Detta stämmer överens med vad andra AI-leverantörer nu dokumenterar offentligt: Anthropics vägledning för modernisering av COBOL-system med Claude Code beskriver samma sekvensering, automatiserar utforskning och analys-faser först istället för att hoppa rakt in i om-skrivning.

Agenterna bedömdes inte utifrån hur mycket kod de genererade. De bedömdes utifrån hur mycket institutionell kunskap de kunde yta och bevara. Ingenjörer arbetade sedan bredvid dem på den faktiska migrationen och test-genereringen, kontrollerade agenternas tolkning av affärslogik mot hur systemet betedde sig i produktion, inte lita på det på tro. Ett användbart signal vi tittade på: matchade agentens förklaring av en regel en mönster vi kunde oberoende verifiera i produktions-loggar, eller var det en trovärdig-ljudande gissning? Gapet mellan de två är exakt där legacy-moderniseringsprojekt vanligtvis går fel.

Den ursprungliga uppskattningen för projektet var åtta och en halv månad. Det stängdes på fyra, en minskning med 53%. Men den mer bestående resultatet var inte tidsramen. Institutionell kunskap som tidigare försvann varje gång en ingenjör lämnade företaget blev något organisationen faktiskt kunde behålla.

Programvaru-utvecklare har tillbringat årtionden med att skriva programvara. Det kommande decenniet kan komma att ägnas åt att gräva upp den, med AI som fungerar mindre som en författare och mer som en arkeolog, noggrant rekonstruerande den resonemang som är begravd i kod som överlevde de personer som skrev den.

En grov ram för att göra detta utan att bryta saker

Projekten som går bra verkar följa samma sekvens, oavsett om systemet är en prissättningsmotor eller en anspråks-pipeline:

Upptäck: karta hur systemen faktiskt ansluter, inte hur arkitektur-diagrammet från 2016 säger att de ansluter.

Förstå: låt agenten yta affärslogiken och antagandena bakom den, i vanligt språk som en domän-expert kan kontrollera.

Verifiera: kontrollera den tolkningen mot riktigt produktions-beteende, inte bara mot kodens egna kommentarer.

Transformera: migrera eller bygga om endast när de första tre stegen håller, med människor som äger godkännandet.

Hoppa rakt till Transform, och du moderniserar inte. Du spelar hasard med logik du inte förstår än.

Varför detta är viktigt bortom ingenjörsteam

Institutionell minne försvinner inte bara tyst när en senior ingenjör går i pension. Det blir en akut skuld vid exakt de ögonblick en affär kan minst ha råd med det: under en förvärv, när en ny ägare behöver förstå vad de faktiskt köpte; under en ERP-migration, när gammal logik måste översättas till ett nytt system korrekt första gången; under en efterlevnads-granskning eller incident-svar, när någon behöver förklara varför systemet betedde sig på ett visst sätt, under en tidsgräns, till en regulator som inte accepterar “personen som byggde det lämnade 2014” som ett svar.

Behandlat på detta sätt slutar legacy-modernisering att vara en ingenjörs-post och börjar se ut som en organisations-resiliens-fråga, vilket betyder att det inte bara är CTO:er som bör bry sig. Det är CIO:er som väger vad som händer när nyckel-teknisk personal vänder, M&A-lag som försöker prissätta vad de faktiskt förvärvar, och styrelser som tänker på hur mycket av företagets operativa kunskap existerar ingenstans utom i kod som ingen för närvarande läser.

Varningen som betyder något

Ingenting av detta fungerar oövervakat. Den riskfyllda versionen av denna metod är en där en agentens tolkning av gammal affärslogik får förtroende utan verifiering, eftersom legacy-system är exakt den platsen där en AI-antagande som är felaktigt på ett trovärdigt sätt kostar mest. Full autonomi på din nyaste mikrotjänst är en rimlig insats. Full autonomi på prissättnings-motorn som ingen har rört sedan 2011 är inte. Värdet är att AI gör det möjligt att bli, en gång till, de ingenjörer som förstår affären, i ett system som ingen för närvarande förstår. Det ersätter dem inte.

Där jag tror detta går nästa

Under tjugo år har företag behandlat äldre programvara som något att fly från: en kostnad som man finansierar motvilligt och moderniserar bort så snabbt som budgeten tillåter. Jag tror att AI är på väg att avslöja att mycket av den koden faktiskt var en av de mest värdefulla kunskaps-repositorierna som affären någonsin byggt. Det behövde bara något som kunde läsa den. Forskare dokumenterar redan den andra sidan av denna loop: en 2026 multivocal litteratur-översikt av LLM-assisterad utveckling finner att dagens jakt på AI-accelererad hastighet i sig skapar “snabb-integrerings-skuld”, kod som levereras snabbare än den kan förstås. Legacy-modernisering är bara den fakturan som kommer före, en generation tidig.

Jag skulle vara nyfiken på om andra teknik- och teknologi-ledare ser samma skift: visar sig avkastningen på din AI-investering mer i vad du bygger, eller i vad du slutligen kan förstå och bevara? Och för alla som har försökt köra AI-agenter mot ett riktigt gammalt, o-dokumenterat system, var höll agentens förståelse under verifiering, och var föll den tyst samman?