Parse first, prompt later: how reverse engineering, agentic AI, and on-chip inference are reshaping COBOL and IBM Z modernization
Written by Verona Ann Mariya and Ramana Sree KV, IBM Z Student Ambassadors
On February 23, 2026, IBM’s shares fell sharply, closing nearly 13% lower in a session where analyst commentary focused heavily on AI’s growing role in legacy modernization [1]. Roughly $31 billion came off IBM’s market cap that day. Market moves rarely have a single cause, and IBM’s own response was measured: new AI tools appear every week, but the core challenge of running mission-critical workloads at scale remains unchanged [3].
Whatever drove the sell-off, the episode reflects something real. Enterprise executives, procurement teams, and investors are now asking whether AI changes the economics of COBOL and IBM Z modernization, not in theory, but in production. This post examines what the evidence actually shows, where vendor claims outrun the data, and what the pipeline looks like when it’s built carefully.
A punched card from a real COBOL program written for a Univac 90/30 system. This card has no sequence numbers in columns 73–80, the space COBOL programmers used to re-sort a dropped deck. Credit: Erik Pitti, CC BY 2.0,via Wikimedia Commons, CC BY-SA 2.5.
“Get off the mainframe” is the wrong question now
For years, modernization meant migration. In 2026 the framing has shifted. Customers are less interested in leaving the mainframe and more interested in connecting its trusted data to cloud platforms, analytics, and AI without disrupting the systems that run the business [4].
The numbers back this up. In BMC’s 2026 survey, 94 percent of respondents saw the mainframe as a long-term platform or one that attracts new workloads, and 69 percent reported growth in general-purpose capacity. A note on that source: BMC sells mainframe management and automation tooling, and its annual survey reflects an audience of organizations already invested in the platform. The figures are useful as practitioner sentiment data, not as a neutral industry-wide sample, and that’s how they’re used throughout this post.
An earlier barometer from Advanced found that 92 percent of enterprises were adopting hybrid strategies. Even AWS’s own AI leadership expects a split, with some workloads staying on the mainframe while others move to the cloud.
The real question is which workloads should move, which should stay, and which should be wrapped in something smarter.
An IBM System/360 at the Computer History Museum. IBM introduced the System/360 in April 1964. Six decades later, its descendants still run core banking and payments. Credit: Rainer Gerhards, CC BY-SA 3.0,via Wikimedia Commons, CC BY 2.0.
The new pipeline: understand first, generate second
The hard part of legacy modernization was never typing new code. It was knowing what the old code does: undocumented logic, nested copybooks, JCL that stitches programs into batch flows, and decades of patches.
Gartner recently predicted that more than 70% of mainframe exit projects started in 2026 will fail to produce their intended benefits, largely because of overestimating what generative AI can do on its own. Deluxe Corporation is one of the exceptions worth examining. Its early-2000s attempt to decommission its mainframe failed because undocumented systems and limited subject-matter expertise made the scope unknowable until well into the migration.
Two decades later, the company completed the move to the cloud in about 12 months, using agentic AI tools from OpenAI, Anthropic, and GitHub to rewrite code, generate documentation, and regenerate test cases, according to independent reporting by CIO.com. CTO Yogaraj Jayaprakasam’s own framing is worth keeping: AI was “one of the missing tools” in the transformation toolset, not a replacement for the rest of it.
The best-known enterprise examples start in the same place, with understanding rather than generation.
Morgan Stanley built DevGen.AI in-house, running on OpenAI models. Rather than generating replacement code directly, the tool translates legacy COBOL into plain-English business specifications that developers then use to guide rewriting, an understand-first approach that mirrors the broader pattern described in this post. Morgan Stanley’s technology head, Mike Pizzi, stated in an interview with the Wall Street Journal that by 2025 the tool had reviewed approximately nine million lines of code and saved roughly 280,000 developer hours. These figures come from Morgan Stanley’s own reporting, as relayed through Pizzi’s public statements, and haven’t been independently audited or verified by a third party. The Wall Street Journal and Entrepreneur both covered the claim, but coverage isn’t the same as verification. What the figures do establish, even conservatively, is that a major financial institution found the understand-first approach worth sustained internal investment at scale, which is itself significant.
Toyota Motor North America’s modernization effort is the most frequently cited enterprise case for AI-assisted COBOL conversion, and it’s worth examining carefully because the figures involved are large enough to invite scrutiny. In the first phase, Toyota used Amazon Q agents to document approximately 400 COBOL programs, roughly 375,000 lines, in five hours, with AWS reporting up to 90 percent documentation accuracy. In the second phase, AWS stated that its Transform service modernized more than 40 million lines of COBOL to Java for Toyota, with a 50 percent reduction in overall effort and 75 percent less time spent on discovery and planning. All of these figures are vendor-reported by AWS and haven’t been independently verified or published in a peer-reviewed or third-party audit. AWS’s own launch documentation notes an important starting condition: using a general-purpose model directly, without the structured analysis pipeline that Transform provides, did not produce better results than traditional methods. That caveat is worth holding alongside the headline numbers: the gains are attributed to the pipeline design, not to model capability alone. If you’re evaluating a similar program, AWS’s published methodology is a more useful reference point than the productivity percentages.
Both cases, despite their different scales and vendors, converge on the same design principle: structured understanding of the existing system precedes any generative step. Morgan Stanley built a tool that produces specifications for humans to act on. Toyota’s AWS pipeline ran documentation and dependency analysis before transformation began. The pattern is consistent enough across independent implementations that it warrants treating it as a design principle rather than a vendor preference.
The tooling follows the same logic. AWS Transform categorizes JCL, BMS maps, COBOL programs, and copybooks, then identifies dependencies and missing artifacts. IBM watsonx Code Assistant for Z runs impact analysis before it generates code. IBM’s newer Bob Premium Package for Z goes further and gives the model a queryable static-analysis repository instead of asking it to reconstruct the system from raw source. In IBM’s own demo, a frontier model asked who calls one date utility answered 13, then 29, then 31, when the true count was 30, a useful illustration of why ungrounded analysis is risky at this scale.
Here’s the pipeline shape these tools share. It’s illustrative, not any one product’s exact flow.
Nine-step pipeline from parsing COBOL and JCL through dependency analysis, business-rule<br />
extraction, a retain/refactor/reimagine decision, code generation, static analysis, equivalence testing, and human approval.
Steps 1 to 4 are deterministic: parse, graph, extract, map. Step 5 is a decision, informed by that analysis. A generative model writes code only at step 6, and steps 7 to 9 exist to check it. The pattern is structured analysis first, generative AI second.
Three paths: retain, refactor, reimagine
Once a system is understood, the choice isn’t binary. In AWS’s terms, “refactor” is an automated, deterministic COBOL-to-Java conversion that preserves the original monolithic architecture. “Reimagine” reverse-engineers business rules and domain structure so you can forward-engineer a new cloud-native application on any target stack. A third option is to retain: keep the workload on the mainframe and add integration or AI around it.
Refactoring is the lower-risk path. Reimagining is where AI-assisted modernization gets ambitious, because you’re rebuilding the architecture rather than translating line by line. The right answer differs by workload, and the analysis from step 1 is what makes that choice defensible.
After reverse engineering, teams choose per workload between retaining, refactoring, and reimagining. Original diagram; refactor and reimagine as described in AWS Transform documentation.
AI is moving onto IBM Z
Modernization isn’t only about getting code off the platform. IBM is putting AI hardware into it. The z17 pairs the Telum II processor with its on-chip accelerator, and IBM says it enables more than 450 billion inference operations a day at one-millisecond response time. It claims
7.5 times the AI performance of the z16. The Spyre accelerator extends this to generative AI: each card has 32 accelerator cores and 128 GB of memory, and a z17 can hold up to 48 of them.
The design goal is scoring transactions where the data lives, for example flagging fraud in milliseconds, instead of shipping data to a separate AI stack. For banks and insurers with strict data-locality requirements, that’s a strong argument.
Looking further out, IBM announced a dual-architecture processor at Hot Chips on August 24, 2026, described in IBM’s own release as designed for future IBM Z and LinuxONE systems. It’s built on a 2-nanometer node with 11 cores above 5.7 GHz and includes AI inference accelerators for in-transaction fraud detection. Each core can natively execute both Arm and IBM Z instructions, so Arm-native Linux can run alongside z/OS. That’s a design announcement for future systems, not shipping hardware.
The IBM z17, built around the Telum II processor. Credit: IBM. Source: newsroom.ibm.com/z17.
Agents enter the development and operations loop
Beyond code generation, AI agents are beginning to enter daily mainframe development and operations workflows. At Think 2026, IBM previewed the Bob Premium Package for Z, the successor to watsonx Code Assistant for Z, and announced general availability on July 9, 2026 [18].
IBM’s published claims for Bob are significant: 20 to 40 percent faster delivery of complex engineering work, and 50 to 80 percent less effort for structured workflows. Early preview users were reported at Think 2026 to have seen productivity gains described internally as tenfold. All of these figures are vendor-reported, based on IBM’s own user studies, and haven’t been independently validated or replicated in published third-party benchmarks.
Analysts observing the launch noted that Bob’s competitive standing against general-purpose coding tools such as Cursor and GitHub Copilot remained unproven at the time. That doesn’t make the claims false; it makes them hypotheses worth testing in your own environment before committing to the toolchain.
What the broader survey data shows, more reliably, because it reflects practitioner preference rather than vendor measurement, is that mainframe professionals strongly prefer AI that recommends actions over AI that acts autonomously. BMC’s 2026 survey found this to be a consistent pattern: humans want to keep control of execution on critical transaction systems. That instinct is well-founded, and the better modernization tools are designed around it rather than against it.
The human bottleneck remains
Skills and institutional knowledge. BMC’s 2025 report, as summarized by Planet Mainframe, found that developers who understand critical mainframe applications are retiring, with 66% of the workforce now identifying as Gen Z or millennial. AI can help younger developers read unfamiliar code, but organizations still lack a consolidated view of application risk and of where knowledge is concentrated. AI works best as a way to capture and transfer that knowledge, not a substitute for it.
Validation. AWS itself says experts remain essential to validate business-logic interpretation, architectural boundaries, and requirements. Proving equivalence matters just as much.
Generated test plans and data should confirm that the modernized application produces the same outputs as the original.
Security and governance. Compliance and security ranked as the top survey priority in BMC’s data for the seventh consecutive year. More AI agents touching mainframe data means more certificates to manage. Separately, the CA/Browser Forum’s April 2025 ballot is shrinking maximum public TLS certificate lifetimes industry-wide, from 398 days today to 47 days by March 2029, which raises the operational bar for certificate management across any environment, mainframe included.
Data and lock-in. Data integration was the third-highest concern when implementing AI on the mainframe, per BMC’s survey, and some analysts warn that deeper vendor AI tooling pushes customers into infrastructure that’s operationally and legally hard to exit.
Where this is heading (our read)
These are our predictions, not sourced facts.
-
Discovery becomes table stakes. Executives already favor short diagnostic phases of two weeks or less that produce an inventory, cost model, and knowledge assessment before any major commitment. Automated code analysis makes that cheap, so the differentiator becomes decision quality.
-
The decision becomes workload by workload. “Migrate everything” and “touch nothing” both lose, and the Gartner failure rate above suggests that’s not a hypothetical risk.
-
The mainframe becomes a governed AI data source. Analysts increasingly describe IBM Z as a component of the enterprise AI stack rather than a platform to be replaced. Safe, auditable agent access to core enterprise data is likely to become a defining capability of the next generation of mainframe architecture.
-
“AI advises, human approves” is the design pattern. Autonomy will be earned use case by use case.
Takeaways
-
Build structured understanding (dependencies, data lineage, business rules) before you generate anything.
-
Choose retain, refactor, or reimagine per workload, and expect the choice to matter more than the tool.
-
Budget for equivalence testing, security, and governance, not just code conversion.
-
Treat vendor productivity claims as hypotheses to test in your own environment, not settled facts.
-
Invest in the people who know why the system works. AI makes their knowledge more valuable, not less.
Keep up to date with Open Mainframe Project:
- Connect with our LinkedIn page
- Subscribe to our Youtube Channel
- Bookmark our Flickr channel
- Follow us on X at @Openmfproject
- Sign up to get our quarterly newsletter
References
Market & business coverage (IBM stock, Feb 23 2026)
-
Bloomberg — IBM Shares Plunge as Anthropic Touts COBOL Modernization Efforts
-
Forbes — IBM Shares Plummet 13%
-
StockTwits — IBM Defends After 13% Stock Drop
Industry surveys and market analysis
-
BMC — State of the Mainframe in 2026 (BMC sells mainframe tooling; see bias note in post)
-
Okoone — What mainframe modernization really looks like in 2026 (cites the Advanced barometer)
-
CIO Dive — AI shifts mainframe modernization strategy
-
Planet Mainframe — AI, Modernization, and Mainframe Momentum (summarizes BMC’s 2025 report)
-
Software Reviews — The Mainframe Is the Story at IBM Think 2026
-
HyperFRAME Research — Mainframe Modernization in the AI Era
Case studies
(independent reporting; includes the Gartner 70%-failure-rate figure)
-
MSN (Wall Street Journal syndication) — How Morgan Stanley Tackled One of Coding’s Toughest Problems
-
Entrepreneur — Morgan Stanley Builds AI Tool That Fixes Major Coding Issue
-
AWS — re:Invent 2024 recap for the Automotive Industry (Toyota’s Amazon Q documentation phase)
-
CIO Dive — AWS Transform aims AI agents at legacy workloads (Toyota’s 40M-line figure)
AWS product documentation
-
AWS — Reimagine your mainframe applications with Agentic AI and AWS Transform
-
AWS — Reimagining mainframe applications with AWS Transform and Claude Code
IBM product documentation
-
IBM Bob (blog) — Bob meets the mainframe
IBM hardware (z17 and dual-architecture processor)
-
IBM Newsroom — IBM z17: The First Mainframe Fully Engineered for the AI Age
-
The Register — IBM z17 brings multi-model AI to transaction processing
-
TechChannel — Spyre and Telum II
-
IBM Newsroom — IBM Unveils Next Generation Dual-Architecture Processor for IBM Z and LinuxONE
Security / standards
-
DigiCert — TLS Certificate Lifetimes Will Officially Reduce to 47 Days (CA/Browser Forum Ballot SC-081v3, industry-wide, not mainframe-specific)
Images
-
Rainer Gerhards — Punch-card-cobol.jpg, Wikimedia Commons, CC BY-SA 3.0
-
Erik Pitti — IBM_System360_Mainframe.jpg, Wikimedia Commons, CC BY 2.0
-
IBM Newsroom — z17 press image, newsroom.ibm.com/z17
-
Pipeline and three-paths diagrams — original illustrations by the authors
