The Anthropic Blog That Crashed IBM: What Both Sides Got Right, What They Missed, and What Comes Next

On February 23, 2026, Anthropic erased over $31 billion from IBM's market cap with a blog post about COBOL. IBM shares dropped 13.2% — the worst single-day loss since October 2000. Accenture and Cognizant fell with it. Bloomberg reported IBM was on track for its worst monthly slide since 1968.

Our founding team spent 2.5 years at FIS modernizing the systems that process over $9 trillion in payments annually. We lived inside the exact problem both Anthropic and IBM are now arguing about. The market's reaction was both entirely predictable and fundamentally wrong about why it matters.

The real story isn't that AI can now read COBOL. It's that neither side is building what actually determines whether a modernization succeeds or fails.

What Anthropic Actually Said

Anthropic's blog post, "How AI helps break the cost barrier of COBOL modernization," made a specific and well-constructed argument: the reason legacy modernization has stalled for decades isn't that rewriting code is hard. It's that understanding the code costs more than rewriting it. AI flips that equation.

The claim is that Claude Code can automate the exploration and analysis phases — mapping dependencies across thousands of lines, documenting workflows that haven't been touched since the original developers retired, surfacing risks that would take human analysts months to find. With this capability, Anthropic argues, teams can modernize COBOL systems in quarters instead of years.

They also released a Code Modernization Playbook — a gated download that walks through prompt engineering for migration, how to choose agentic coding tools, and a structured methodology for incremental modernization.

Anthropic isn't wrong about the economics. The exploration and documentation phases really are where most of the cost lives. When we were at FIS, we watched consulting teams spend months just mapping what a system did before anyone touched a line of code. If AI can compress that phase by even 60-70%, it genuinely changes the calculus for enterprises that have been sitting on modernization proposals for years.

But the blog post makes a critical leap: it conflates the ability to read code with the ability to understand a system. Those are not the same thing.

The IBM Response

IBM SVP Rob Thomas published a response the same day — "Lost in Translation: What the AI code debate keeps getting wrong." His core argument was surgical: translating code isn't modernizing a platform. The value of IBM's mainframe has nothing to do with COBOL specifically. It has to do with what sits underneath it.

Thomas laid it out precisely: enterprise COBOL on IBM Z runs inside a vertically integrated stack — z/OS, CICS, IMS, Db2, RACF, MQ, Parallel Sysplex. That stack delivers 25 billion encrypted transactions per day, 450 billion AI inferences per day at 1ms response time, up to eight nines of availability. Translating COBOL to Java doesn't move any of that.

His analogy was sharp: it's like the iPhone and iOS. Someone could build an alternative, but the performance comes from decades of hardware-software integration. You don't replicate that by porting an app.

Thomas is right. And his argument is also deeply self-serving. IBM's entire business model depends on that complexity remaining opaque and their consulting teams remaining the only trusted guides through it. When he says "translation captures almost none of the actual complexity," he's both telling the truth and protecting a revenue stream.

He also made a point that got lost in the coverage: roughly 40% of COBOL doesn't even run on mainframes. A huge portion of this conversation is actually about distributed systems — Windows, Linux, mid-range platforms — that got folded into a mainframe headline.

What the Market Got Wrong

The 13.2% crash was a panic reaction to a headline, not a reasoned assessment of what Anthropic actually built. As DevOps.com noted, AI-assisted COBOL analysis isn't new. IBM launched watsonx Code Assistant for Z in 2023. AWS has Transform for Mainframe. Every major systems integrator has been shipping some version of this capability for years.

What was new was that a consumer-facing AI company said it publicly, with a marketing push, during a market already rattled by AI disruption fears. This was Anthropic's second market-moving blog post in a week — their Claude Code Security announcement had sent cybersecurity stocks tumbling days earlier. The market was primed to overreact, and it did.

IBM's Z mainframe revenue was actually up 48% year-over-year at the time of the crash. Clients aren't fleeing mainframes. They're investing in them. The sell-off was about narrative, not fundamentals.

What Both Sides Are Missing

This is where our experience at FIS becomes directly relevant.

Futurum Group's analysis nailed the framing: "Choosing the right AI tool for code discovery while skipping the other dimensions does not produce a successful migration. It produces faster discovery of a program that still fails." Successful modernization requires business scoping, technical assessment, data migration planning, behavioral equivalence validation, observability, and organizational change management — in addition to code translation. Neither Claude Code nor IBM's Project Bob addresses that full scope today.

Thoughtworks published a nuanced response that crystallized the technical gap: "The assumption that AI can simply translate COBOL into Java treats modernization as a syntactic exercise, as though a system is nothing more than its source code. That premise is flawed." A system includes infrastructure, data models, operational processes, integration contracts, external dependencies, and people. Modernization isn't a coding exercise — it's a delivery challenge.

At FIS, we learned this lesson the hard way. When you translate COBOL to Java line-by-line, you get what the industry calls "JOBOL" — code that mimics COBOL's structure in Java syntax but inherits all of its architectural constraints, accumulated technical debt, and undocumented business logic. You haven't modernized anything. You've created a system that's harder to maintain than the original, because now you need engineers who understand both languages and neither architecture.

The missing piece — the thing neither Anthropic nor IBM is building — is the understanding layer. Not reading code. Not translating syntax. Actually understanding what a system does, why it does it, how its components interact, and what the business intent is behind decades of accumulated behavior. That understanding has to be verified, multi-modal (code, data, operations, business rules), and machine-readable so it can drive automated transformation.

Without that layer, you're either translating code and hoping nothing breaks (Anthropic's implicit approach), or you're paying consultants $500/hour to manually discover what the system does (IBM's explicit business model). Both paths fail at scale. Both paths have been failing at scale for twenty years.

The DOGE Proof Point

If you want to see what happens when you skip the understanding layer entirely, look at DOGE's attempt to rewrite the Social Security Administration's 60-million-line COBOL codebase "in months." Wired covered it under the headline "COBOL Is the Asbestos of Programming Languages" — the metaphor is apt. COBOL is everywhere, dangerous to remove, and there's no quick fix.

The DOGE effort stalled. It became a cautionary tale covered by Gizmodo, MSNBC, and Slashdot — proof that the most powerful government in the world couldn't brute-force a legacy rewrite, even with unlimited political will and no procurement constraints. The system was too deeply embedded, too poorly documented, and too interconnected to simply replace.

This is the reality that both Anthropic's blog and IBM's response dance around. The problem isn't that we lack tools to read COBOL. The problem is that reading code gives you maybe 30% of what you need to modernize a system. The other 70% lives in the space between the code — in operational patterns, data dependencies, implicit business rules that were never written down, and cross-system behaviors that emerge from decades of organic growth.

What Enterprise Leaders Should Actually Do

If you're a CTO or VP of Engineering sitting on a legacy modernization decision right now, here's what we'd tell you:

Use AI for analysis. It's genuinely useful. Claude Code, IBM's watsonx, AWS Transform — they all accelerate the discovery phase. Don't ignore them. But don't confuse discovery with modernization.

Don't translate without understanding. If someone proposes translating your COBOL to Java as the modernization plan, ask them one question: "What happens to the business logic that isn't in the code?" If they don't have an answer, they're proposing a JOBOL project.

Demand behavioral equivalence. Any modernization approach that can't prove the new system behaves identically to the old one under all conditions is a liability, not an upgrade. This isn't a nice-to-have — in regulated industries, it's a compliance requirement.

Build the understanding layer first. Before you transform anything, build a verified, machine-readable specification of what your system actually does. That specification becomes the foundation for everything else — transformation, testing, validation, and ongoing governance.

Where Glover Fits

This is exactly what we're building at Glover Labs. We spent 2.5 years inside the problem at FIS before starting this company. We watched every approach fail for the same reason: they started with code and hoped understanding would follow.

We start with understanding. Our platform builds a deep semantic model of legacy systems — what the code does, what the data means, how components interact, what the business intent is — and surfaces modernization paths aligned to the organization's actual objectives. From there, we drive an agentic, spec-driven development process end-to-end. Not line-by-line translation. Not consultant-led manual discovery. A verified, automated path from understanding to transformation.

Anthropic proved that AI changes the economics. IBM proved that translation alone isn't enough. The industry is converging on the thesis we were founded on: understand before you transform.

The question now is who builds the understanding layer. We think we have a head start.

Book a demo to see how the Living Spec builds the understanding layer.