Den 23 februari 2026 föll IBMs aktiekurs med 13 procent på en enda dag, den brantaste nedgången på en dag sedan oktober 2000. Utlösaren var ett tillkännagivande från ett AI-labb som hävdade möjligheten att modernisera COBOL. Styrelser med stordatorer läste tillkännagivandet och frågade om AI nu kunde konvertera sin COBOL och låta dem stänga av stordatorn. IBMs svar, som publicerades samma dag, var precist: översättning fångar nästan ingenting av den verkliga komplexiteten, som ligger i dataarkitektur, runtime-ersättning, transaktionsintegritet och de icke-funktionella krav som är inbyggda i plattformen. Marknaden hade blandat ihop två olika problem och prissatt en lösning på det ena som om det vore en lösning på båda.
De två problemen är förståelse och översättning. De är inte faser av samma aktivitet. De är genuint olika tekniska utmaningar som AI hanterar med genuint olika kapacitet och genuint olika risker. AI har gjort COBOL-systemet dramatiskt billigare att förstå. Det har inte gjort det dramatiskt billigare att ersätta det. Skillnaden är viktig just för att organisationer som fattar beslut om moderniseringsinvesteringar behöver veta vilket problem de betalar för att lösa, vad AI faktiskt levererar på varje problem, och var det verifieringsarbete som återstår oavsett AI-verktyg kommer att förbruka den budget som besparingarna inom förståelse och översättning frigjorde.
De strukturella grundernas AI-behov
SMART TS XL identifierar oåtkomliga program innan AI-översättningen startar – så att du översätter det som körs, inte det som finns.
TA REDA PÅ MER…Skillnaden att marknaden hade fel
Förståelse och översättning är inte samma problem.
Förståelse är disciplinen att förstå vad kod gör och varför, genom att extrahera affärsintentionen från den tekniska implementeringen. I ett COBOL-sammanhang betyder förståelse: vilka affärsregler kodar detta program? Vilka villkor styr varje exekveringsväg? Vilken data läser och producerar det? Vilka nedströmssystem är beroende av dess utdata? Vad skulle en affärsanalytiker behöva veta om detta program för att skriva en specifikation för dess ersättning? Förståelse handlar om semantik, mening, inte syntax.
Översättning är disciplinen att konvertera kod från ett språk till ett annat samtidigt som dess beteende bevaras. I ett COBOL-sammanhang betyder översättning: producera Java (eller Python, eller Go) som gör vad COBOL gör, för alla indata, under alla förhållanden, med tillräcklig numerisk ekvivalens för de nedströmssystem som konsumerar utdata. Översättning handlar om strukturell och beteendemässig ekvivalens, den nya koden måste klara alla tester som den gamla koden skulle ha klarat, inklusive tester för edge-fall som den ursprungliga utvecklaren övervägde och som du kanske aldrig visste existerade.
| Dimensionera | Förståelse | Översättning |
|---|---|---|
| Fråga besvarad | Vad betyder den här koden? | Vad gör den här koden, exakt? |
| Utgångstyp | Naturligt språk, dokumentation | Körbar kod |
| Felkonsekvens | Kan korrigeras genom mänsklig granskning | Produktionsincident |
| AI-förmåga | Starka juridikexperter utmärker sig i prosa | Svag, determinism krävs |
| Skalbegränsning | Hanterbar med kontextfönster | Portföljskala misslyckas med kontextgräns |
| Riskprofil | Låg, fel kan granskas | Hög, fel är osynliga tills de utlöses |
| Människoroll | Validerare och berikare | Granskare och bevisare |
Dessa problem är relaterade, man behöver viss förståelse för att göra en bra översättning, men de är inte samma problem, och AI:s kapacitetsgap mellan dem är betydande. AI:s förståelse av COBOL-kod är verkligen imponerande. AI-översättning av COBOL-kod till produktionskorrekt Java är verkligen svårt, och marknadens sammanblandning av de två är anledningen till att Gartner förutspådde att mer än 70 procent av stordatorexitprojekt som initieras 2026 kommer att misslyckas med att producera sina avsedda fördelar.
Där AI-förståelse faktiskt levererar
Förståelseproblemet har en egenskap som gör AI väl lämpad för det: utdata är naturligt språk, och generering av naturligt språk är vad stora språkmodeller gör bra. När AI läser ett COBOL-program och producerar dokumentation, en beskrivning av vad programmet gör, en förklaring av dess affärsregler, en uppräkning av dess dataflöden, är utdata text. Fel i den texten kan åtgärdas: en mänsklig granskare kan upptäcka en felaktigt karakteriserad affärsregel och korrigera den utan några tekniska konsekvenser senare. Kostnaden för förståelsefel är en dokumentationskorrigering, inte en produktionsincident.
Dokumentation av affärsregler. En stor språkmodell presenterad med ett COBOL EVALUATE-block, potentiellt hundratals WHEN-villkor som ackumulerats under årtionden av regeländringar, kan producera en strukturerad beskrivning av vad varje villkor betyder i affärsmässiga termer. För program där den ursprungliga dokumentationen inte längre finns eller aldrig har existerat är detta verkligt värdefullt. Ett COBOL-program som implementerar skatteberäkningslogik i 63 jurisdiktioner har dessa jurisdiktionregler kodade i sin EVALUATE-struktur; AI kan extrahera och dokumentera dem snabbare än någon manuell process. Det som produceras bör valideras av en domänexpert, men experten validerar AI-output snarare än att rekonstruera kunskap från grunden, vilket är en mycket snabbare process.
Så här ser AI-förståelse ut i praktiken. Med tanke på denna COBOL-källa:
cobol
EVALUATE TRUE
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'CA'
COMPUTE TAX-AMT = GROSS-AMT * 0.0725
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'TX'
COMPUTE TAX-AMT = GROSS-AMT * 0.0825
WHEN CUST-COUNTRY = 'UK'
COMPUTE TAX-AMT = GROSS-AMT * 0.20
WHEN CUST-COUNTRY = 'DE'
COMPUTE TAX-AMT = GROSS-AMT * 0.19
WHEN OTHER
MOVE ZERO TO TAX-AMT
END-EVALUATE.
En välutbildad juristexamen producerar:
Business Rule: Tax Calculation
This paragraph applies jurisdiction-specific tax rates to GROSS-AMT:
- US/California: 7.25% (CA state sales tax)
- US/Texas: 8.25% (TX state sales tax)
- United Kingdom: 20% (UK VAT standard rate)
- Germany: 19% (DE MwSt standard rate)
- All other countries: tax-exempt (TAX-AMT = 0)
Note: No rate exists for other US states. Orders from NY, FL, IL
will be tax-exempt under current logic -- likely a gap requiring review.Den utdata är genuint värdefull: den dokumenterar fyra affärsregler, identifierar ett sannolikt gap (amerikanska delstater utan explicita avgifter) och gör det på några timmar. En domänexpert granskar den, bekräftar gapet och lägger till det i testfallen. Förståelseuppgiften slutfördes korrekt.
Beroendeberättelse. Statiska analysverktyg producerar beroendegrafer, vilka program som anropar vilka, vilka kopieböcker som delas, vilka datamängder som flödar mellan program. AI kan producera en berättelse i naturligt språk från den grafen: "CUSTPROC anropas av 14 program, främst i det nattliga batchfönstret. Den delar CUSTMSTR med 47 program och producerar utdata till CUST-REPORT-FILE, som förbrukas av arbetsflödet för regulatorisk rapportering." Denna berättelse är mer användbar för onboarding och arkitekturgranskning än enbart ett beroendegraf, och AI producerar den på några sekunder från de strukturerade beroendedata.
Generering av testfall från förstått beteende. När AI har dokumenterat programmets beteende kan den generera testfall som täcker de dokumenterade exekveringsvägarna. Detta är inte samma sak som att bevisa beteendeekvivalens, testfallen täcker vägar som AI:n förstod, vilka kan missa vägar den inte gjorde. Men att täcka 60 procent av exekveringsvägarna genom AI-genererade tester är bättre än den nollprocentiga täckning som många äldre program för närvarande har, och det ger en utgångspunkt för den manuella testförstärkning som validering av beteendeekvivalens kräver.
Mönsterigenkänning över liknande program. Stora COBOL-portföljer innehåller ofta många program som är strukturellt lika, samma bearbetningsmönster tillämpat på olika enheter, samma regulatoriska beräkningar parametriserade på olika sätt. AI kan identifiera dessa likheter över tusentals program och klustra dem efter mönstertyp, vilket möjliggör en migreringsstrategi som adresserar varje mönster en gång och tillämpar lösningen systematiskt snarare än att behandla varje program som unikt.
Den gemensamma nämnaren: AI-förståelseresultat är text, text kan granskas av människor och mänsklig granskning upptäcker fel innan de får tekniska konsekvenser. Riskprofilen för AI-förståelse är tillräckligt låg för att det värde den levererar är genuint och de fel den gör är hanterbara.
Där AI-översättning lovar för mycket
Översättning har en egenskap som gör det fundamentalt svårare för AI än förståelse: utdata är körbar kod, och den körbara koden måste vara exakt korrekt. En 95 procent korrekt översättning producerar ett program som misslyckas för 5 procent av indata, vilket i ett system för finansiell transaktionshantering kan representera ett fel i rapporteringsregler, en avvikelse i saldoberäkningen eller ett efterlevnadsfel. Kostnaden för översättningsfel är inte en dokumentationskorrigering. Det är en produktionsincident.
Det numeriska precisionsfelet. COBOLs packade decimalaritmetik (COMP-3) ger exakta decimalresultat. Javas double och Pythons float använda IEEE 754 binär flyttal, som inte exakt kan representera de flesta decimalbråk. Ett COBOL-program som beräknar 0.1 + 0.2 med COMP-3 producerar exakt 0.3Samma beräkning i Java med double producerar 0.30000000000000004För ett finansinstitut där denna beräkning körs 10 miljoner gånger per natt över olika regulatoriska inlämningar är det ackumulerade felet inte en flyttalskunskap, utan en avvikelse i finansiell rapportering. En AI-översättning som genererar Java utan att explicit hantera COMP-3-till-BigDecimal-mappningen introducerar detta fel systematiskt, och den gör det för varje fält som AI:n översätter som. double snarare än BigDecimal.
Skillnaden i kod är subtil; konsekvensen är inte:
cobol
* COBOL: COMP-3 packed decimal -- exact arithmetic
77 UNIT-PRICE PIC S9(7)V99 COMP-3.
77 QUANTITY PIC S9(5) COMP-3.
77 LINE-TOTAL PIC S9(11)V99 COMP-3.
COMPUTE LINE-TOTAL = UNIT-PRICE * QUANTITY.
* UNIT-PRICE = 19.99, QUANTITY = 3
* LINE-TOTAL = exactly 59.97 -- no rounding error
Java
// Java: naive AI translation uses double -- introduces error
double unitPrice = 19.99;
int quantity = 3;
double lineTotal = unitPrice * quantity;
// lineTotal = 59.96999999999999... not 59.97
// Correct translation requires BigDecimal:
// BigDecimal lineTotal = new BigDecimal("19.99").multiply(new BigDecimal(3));Vid en transaktion är felet osynligt. Vid 10 miljoner nattliga transaktioner, summerade i en rapport om regulatoriskt kapital, är det en väsentlig avvikelse. En AI-översättning som inte explicit tar upp COMP-3-fält kommer att göra denna ersättning varje gång.
Beroendet för kompilatoralternativ. Identisk COBOL-källkod kan ge olika beteenden under olika kompilatoralternativ. NUMPROC(MIG) kontra NUMPROC(NOPFD) ändrar hur numeriska undantag hanteras. RMODE-, AMODE- och DATA-alternativ påverkar adresseringen. En AI som översätter COBOL-källkod utan att veta vilka kompilatoralternativ som användes översätter programmets källkod, inte programmets beteende. Den översatta Java-koden kan matcha källkoden men inte produktionsbeteendet.
Hallucinationsproblemet i stor skala. Forskning visar att modeller i GPT-4-klassen uppvisar hallucinationsfrekvenser på 33 till 60 procent i allmänna kodöversättningsuppgifter, vilket genererar trovärdig kod som lägger till eller tar bort beteenden som inte finns i källkoden. För ett program med 847 EVALUATE-villkor innebär en hallucinationsfrekvens på 5 procent att cirka 42 villkor är felaktigt översatta. Dessa 42 villkor representerar affärsregler som översättningen tyst bröt mot. Utan en komplett testkorpus som utövar varje villkor är dessa avbrott oupptäckbara förrän den specifika inmatningskombinationen som utlöser dem når produktion.
Insatserna i siffror:
Error Type | Detection Point | Cost Range
--------------------|--------------------|------------------
Comprehension error | Human review | Hours to fix
Translation error | Test suite | Days to isolate
Translation error | Production | $10K-$500K+ incident
Equivalence gap | Regulatory audit | $50K-$5M+ penaltyAsymmetrin: Förståelsefel upptäcks innan de får tekniska konsekvenser. Översättningsfel överlever granskning och detonerar i produktion, eller ännu värre, i en regulatorisk inlämning.
Kontextfönstrets tak. IBMs Watsonx Code Assistant för Z uppnår 80 procent eller bättre strukturell noggrannhet vid COBOL-till-Java-översättning för enskilda program inom ett kontextfönster. En COBOL-portfölj på 5 miljoner rader består av tusentals program, med beroenden mellan program som sträcker sig över program som inte alla kan finnas i samma kontextfönster samtidigt. Ett program som anropar ett delprogram vars gränssnitt AI:n översatte annorlunda än det anropande programmets antaganden skapar en gränssnittsmatchning som ingen av översättningarna ensamma skulle avslöja. Översättning på portföljnivå kräver förståelse mellan program, inte bara inom dem.
Problemet med kontextfri översättning. Ett COBOL-program som bearbetar en specifik affärshändelse gör det med kontext som är inbäddad i systemet runt det, batchschemat som avgör när det körs, de dataset som måste vara tillgängliga när det startar, den ordning i vilken det bearbetar poster, de nedströmsprogram som läser dess utdata innan de körs. En AI som översätter programmet utan att förstå detta sammanhang översätter källan men inte rollen. Den översatta Java-filen kan vara internt korrekt och ändå misslyckas operativt eftersom den körs vid fel tidpunkt, i fel ordning, utan de dataförutsättningar som dess COBOL-föregångare förlitade sig på.
Beteendelikvärdighetsklyftan
Det viktigaste problemet som varken förståelse-AI eller översättnings-AI löser är bevis på beteendeekvivalens, demonstrationen av att det moderniserade systemet producerar samma resultat som det gamla systemet för alla indata som är viktiga för verksamheten och dess tillsynsmyndigheter.
Beteendeekvivalens är inte ett testproblem i ordets vanliga bemärkelse. Det handlar inte om att fråga "klarar det nya systemet testsviten?", eftersom testsviten för ett äldre COBOL-system ofta inte existerar, eller täcker en bråkdel av de exekveringsvägar som programmet innehåller. Det handlar om att fråga: för varje indata som produktionssystemet någonsin har mottagit, producerar det moderniserade systemet samma utdata? Och för varje indata som produktionssystemet kan komma att få i framtiden, inklusive edge-fall som endast inträffar under sällsynta marknadsförhållanden, regulatoriska rapporteringsperioder eller specifika kundförhållanden, producerar det moderniserade systemet motsvarande resultat?
Att besvara denna fråga kräver: en karakterisering av det befintliga systemets beteende härlett från faktisk produktionskörning (inte från dokumentation, inte enbart från källkoden), en testkorpus som utövar hela spektrumet av detta beteende, och ett jämförelseramverk som kan avgöra vad "ekvivalent" betyder för utdata där representationen skiljer sig (EBCDIC vs UTF-8, packad decimal vs BigDecimal, batchfil vs databaspost).
Inget av detta är vad AI-översättningsverktyg erbjuder. IBMs bedömning är direkt: översättning fångar nästan ingenting av moderniseringens verkliga komplexitet. Det är i arbetet med beteendeekvivalens, parallellkörningen, avstämningsramverket och det regulatoriska godkännandet som kostnaden och risken koncentreras, och det är där AI gör minst skillnad för den totala programkostnaden. AI komprimerar moderniseringsprojektets framsida: förståelse och initial översättning. Den komprimerar inte baksidan: verifiering, ekvivalenstestning och parallell validering.
Rätt modell: Statisk analysgrund, AI semantiskt lager
Den mest effektiva AI-förståelseförmågan är inte ensam AI, det är AI som arbetar utöver en strukturell grund som statisk analys tillhandahåller. Begränsningarna med AI-förståelse (begränsningar i kontextfönster, hallucinationer på komplex logik över flera program, probabilistisk snarare än deterministisk analys) åtgärdas av statisk analys. Begränsningarna med statisk analys (den producerar strukturella fakta men inte semantiska beskrivningar) åtgärdas av AI.
Rätt arbetsfördelning: Statisk analys ger strukturell säkerhet (deterministisk, fullständig, inga hallucinationer). AI ger semantisk rikedom (beskrivningar i naturligt språk, mönsterigenkänning, testgenerering). Ingetdera är tillräckligt ensamt. Tillsammans täcker de hela förståelsekravet.
Den strukturella grunden som statisk analys ger:
Komplett programinventering. Alla program i portföljen, inklusive program som dokumentationen missade och program som AI:s kontextfönster aldrig skulle kunna innehålla samtidigt. Statisk analys bearbetar hela portföljen utan kontextbegränsningar.
Noggrann beroendegraf. Varje CALL-relation, varje COPY-relation, varje dataflöde mellan program, härledd deterministiskt från källan, inte probabilistiskt från träningsdata. När ett AI-förståelseverktyg beskriver ett programs beroenden, bör den beskrivningen baseras på en beroendegraf som statisk analys producerat, inte på AI:ns probabilistiska återkallelse av vad program vanligtvis är beroende av.
Identifiering av död kod. Program som inte kan nås från någon produktionsexekveringsväg omfattas inte av modernisering. Statisk analys identifierar dem med säkerhet; AI kan inte det, eftersom AI inte har de körtidsexekveringsspår som krävs för att skilja aktiv kod från död kod enbart genom statisk analys.
Dataschemainventering. Varje FD-post, varje kopiebok, varje COMP-3-fält med dess precisionsspecifikation, extraherat från källartefakter snarare än rekonstruerat från AI:ns träningsdataminne av hur COBOL-fältdefinitioner vanligtvis ser ut.
Utöver denna strukturella grund lägger AI-förståelsen till det semantiska lagret: beskrivningar av vad varje program gör i naturligt språk, dokumentationen av affärsregler, berättelsen om dataflöden mellan program, mönsterigenkänningen som klustrar liknande program. Denna kombination, deterministisk strukturell noggrannhet från statisk analys, och semantisk rikedom i naturligt språk från AI, är den modell som producerar förståelseresultat som ett moderniseringsteam faktiskt kan lita på.
Vad detta innebär för ditt moderniseringsprogram
Praktisk fördelning av AI-investeringar baserat på denna analys:
Investera i AI-förståelse. Generering av dokumentation, extrahering av affärsregler, berättelser om beroenden, generering av testfall från dokumenterat beteende – dessa är högvärdiga och lågriskiga användningsområden för AI som komprimerar den dyraste traditionellt manuella fasen av moderniseringen. Gör dessa först, före översättning, eftersom förståelsen ligger till grund för varje efterföljande beslut.
Använd AI-översättning som en utkastgenerator, inte en slutbehandlare. AI-översättning producerar en Java- eller Python-utgångspunkt som en utvecklare granskar, korrigerar och validerar, inte produktionsklar kod som kan distribueras utan mänsklig granskning. Att behandla AI-översättningsutdata som ett utkast minskar översättningskostnaden samtidigt som det mänskliga ansvar som ekvivalensvalidering kräver bibehålls.
Räkna inte besparingar från AI-översättning mot verifieringskostnaden. AI komprimerar tiden det tar att producera ett översatt program. Den komprimerar inte tiden det tar att bevisa att det översatta programmet är likvärdigt med originalet. Budgetera verifieringsfasen oberoende av besparingar från AI-översättning, eftersom verifieringsomfattningen inte krymper när översättningen går snabbare.
Bygg först den strukturella grunden. AI-förståelseverktyg som saknar en strukturell grund, ett korrekt beroendediagram, en komplett programinventering eller en dataschemainventering producerar ofullständig förståelse där koden är som mest komplex. De program som mest behöver AI-förståelse är vanligtvis de mest komplexa, mest beroende mellan olika program och mest sannolikt överträffar vad AI korrekt kan analysera enbart från källan.
Hur SMART TS XL Stöder AI-förbättrad COBOL-förståelse
SMART TS XL ger den strukturella analysgrunden som gör AI-förståelsen av COBOL-portföljer korrekt snarare än probabilistisk.
Funktionen för statisk kodanalys producerar de strukturella data på programnivå som AI-förståelseverktyg behöver: varje uppräknat UTVÄRDERA-villkor, varje extraherad COMPUTE-formel, varje karakteriserat dataåtkomstmönster. När AI-dokumentationsverktyg arbetar med källkod med dessa strukturella data som kontext, producerar de beskrivningar baserade på vad koden faktiskt innehåller snarare än vad liknande program vanligtvis gör.
Mappningen av applikationsberoenden tillhandahåller den programövergripande kontext som AI-kontextfönster inte kan hantera samtidigt. Ett beroendediagram som visar CUSTPROCs 14 anropare, dess 47 kopieringsboksdelare och dess 3 dataflödesutgångar ger AI-förståelseverktyg en fullständig bild av ett programs roll i portföljen, utan att varje beroende program behöver vara i samma kontextfönster samtidigt.
Analysen av den äldre moderniseringen producerar den inventering av död kod och komplexitetsfördelning som AI-förståelse inte kan producera på ett tillförlitligt sätt på egen hand: vilka program är oåtkomliga från produktion (undantagna från omfattningen), vilka program har den högsta komplexiteten (där förståelsefel är dyrast) och hur datamigreringsomfattningen ser ut härledd från faktiska FD-poster snarare än från dokumentation.
Företagssökningsfunktionen gör det strukturella inventariet sökbart till stöd för AI-assisterad förståelse: hitta varje program som implementerar ett specifikt mönster, varje EVALUATE - block med fler än N villkor, varje program som åtkommer en specifik datamängd, frågor som grundar AI-förståelse i strukturella bevis snarare än i sannolikhet i träningsdata.
För organisationer där AI nu är en del av moderniseringsverktygskedjan, SMART TS XLs strukturanalys är det lager som gör AI-förståelse korrekt på portföljnivå, och tar itu med kontextfönstrets gräns, hallucinationsrisken vid programövergripande logik och determinismgapet som skiljer strukturanalys från probabilistisk generering.
AI förändrade kostnaden för förståelse. Inte kostnaden för att bevisa.
Det som förändrades 2026 är kostnaden för förståelse. AI har gjort det dramatiskt billigare och snabbare att förstå vad ett COBOL-program gör, dokumentera dess affärsregler, karakterisera dess beteende och beskriva dess plats i portföljen. Detta är ett genuint och betydande bidrag till moderniseringsekonomin. För program där förståelsefasen tidigare krävde veckor av specialistarbete kan AI producera ett utkast till förståelse på några timmar som specialister granskar och förfinar snarare än att konstruera från grunden.
Det som inte förändrades var kostnaden för att bevisa. Valideringen av beteendeekvivalens, den parallella körningen, det regulatoriska godkännandet, verifieringen av datamigrering, dessa ligger kvar där de var före AI och förbrukade 40 till 50 procent av moderniseringsbudgeten oavsett hur snabbt förståelse- och översättningsfaserna slutförs. IBM hade rätt den 23 februari 2026: översättning fångar nästan ingenting av den verkliga komplexiteten. Den verkliga komplexiteten ligger i verifieringen av beteendeekvivalens, och den komplexiteten minskar inte när översättningen blir snabbare.
De organisationer som använder AI väl i COBOL-moderniseringen är de som investerar i AI-förståelse, där AI verkligen är utmärkt, och behandlar AI-översättning som en utgångspunkt för mänsklig granskning snarare än en färdig produkt redo för driftsättning. De förstår att om projektets framsida blir billigare, gör det inte projektets baksida billigare. Och de bygger den strukturella analysgrund som AI-förståelsen behöver vara korrekt på den portföljskala där det viktigaste förståelsearbetet sker.
