Herman, did you see the headlines from late February? The ones where a single technical blog post from Anthropic deleted thirty billion dollars from I-B-M's market value in a single afternoon?
I was glued to the charts that day, Corn. It was February twenty-third, twenty twenty-six. Anthropic puts out this post about Claude Code and its ability to modernize legacy systems, specifically targeting COBOL, and suddenly the market treats IBM like it just found out its mainframes are made of cardboard. It was a thirteen point two percent drop for Big Blue. Investors panicked because Anthropic claimed they could reduce migration timelines from years to just a few quarters.
It's wild that a programming language first drafted in nineteen fifty-nine can still move the needle that hard on Wall Street in twenty twenty-six. Today's prompt from Daniel is about COBOL, and it's the perfect time to dig into this. He wants to know why this supposed dinosaur refuses to go extinct, what it's actually like to work with, and if this recent AI-driven modernization push is finally the end of the road or just another chapter in the "COBOL is dying" myth that's been running for forty years.
It's the ultimate load-bearing wall of the global economy. We're talking about two hundred twenty billion lines of code still in active use. When you swipe your card at an A-T-M, or buy groceries, there's a ninety-five percent chance a COBOL program is somewhere in that execution chain. It handles three trillion dollars in daily commerce. If COBOL stopped working tomorrow, the world economy would revert to the barter system by lunch. In the United States alone, forty-three percent of core banking systems are built on this stuff.
And yet, we treat it like an embarrassing secret. Like the tech world is this sleek, modern skyscraper, but the foundation is made of punch cards and vacuum tubes. Let's start with the history because people often forget how radical this was. You have Grace Hopper, a legendary figure and Rear Admiral in the Navy, who pushed for the idea that computers should understand English-like words instead of just mathematical symbols.
Grace Hopper was a visionary because she realized that for computers to be useful for business, you couldn't just have mathematicians writing code. She developed FLOW-MATIC in the late fifties, which was the direct precursor. She famously argued that we should be able to talk to machines in a language that a business manager could look at and have a vague idea of what was happening. This led to the Conference on Data Systems Languages, or CODASYL, in nineteen fifty-nine. The Pentagon got tired of every computer manufacturer having its own proprietary language, so they forced a standard. They told the manufacturers, if you want us to buy your hardware, it has to run COBOL.
That's the ultimate government mandate success story. The Department of Defense effectively forced the entire business world onto a single stack by pure administrative will. Because it was designed for business, it was built to be readable, which is where that famous verbosity comes from. But it's not just about the syntax; it's about the massive, invisible infrastructure behind it.
To understand why it's so hard to move, you have to look at what the code actually looks like. If you're used to Python or C-plus-plus, looking at COBOL is like reading a legal contract from the nineteenth century. It doesn't use terse symbols; it uses reserved words. There are over three hundred of them. Instead of an equals sign, you might see MOVE X TO Y. Instead of a plus sign, you see ADD TAX TO PRICE GIVING TOTAL. It was designed to be read aloud, almost like prose.
But that readability is a double-edged sword. It looks like English, but it has a rigid structure that feels like a straitjacket to a modern developer. Walk me through these divisions, because that's where it gets really strange for someone coming from a modern background.
Every COBOL program is divided into four mandatory sections called divisions. First, the Identification Division, where you name the program and list the author. Then the Environment Division, which defines the physical hardware the program is running on—a relic of the era when code was tied to specific machines. Then the Data Division, where every single variable must be declared in advance. There's no such thing as a local variable in the middle of a function in traditional COBOL. And finally, the Procedure Division, which is where the actual logic lives.
It sounds very bureaucratic. As if you have to fill out a three-page form just to tell the computer you're about to start working.
It really is. And it carries the ghost of the punch card era. Even today, if you're writing COBOL for a mainframe, the columns matter. Columns one through six are for sequence numbers. Column seven is for indicators, like an asterisk for a comment. Columns eight through eleven are the A margin, and twelve through seventy-two are the B margin. If you write your code in the wrong column, it won't compile or the compiler will just ignore it. We're in twenty twenty-six, and we're still dealing with formatting constraints inherited from physical cardboard cards.
That's the part that blows my mind. We're using ultra-powerful silicon to simulate the limitations of a nineteen fifties office. But there has to be a reason beyond just momentum that we keep using it. I've heard you mention how it handles numbers, and how modern languages actually struggle with financial math compared to COBOL.
This is a vital point that people miss when they say we should just rewrite everything in Java or Rust. Most modern languages use binary floating-point math. It's fast, but it's imprecise for currency because you get tiny rounding errors when converting between decimal and binary. COBOL uses decimal arithmetic. It treats numbers exactly the way humans do.
Is that where the PICTURE clause comes in?
The PICTURE clause, or P-I-C for short, is how you define data. You might see something like P-I-C nine, parenthesis seven, V nine nine. That tells the computer: this is a seven-digit number with two decimal places. It's not just a general "number" type; it's a fixed-width, precise template. When you add two of those together, you get the exact result you expect, down to the penny, every single time. For a bank processing billions of transactions, that lack of rounding error is the entire reason for existence.
So it's precise, stable, and battle-tested over sixty years. But the problem is the people. We have this dwindling pool of developers. I saw a figure that there are only about twenty-four thousand COBOL programmers left in the United States, and the average age is between forty-five and fifty-five.
We're facing a massive demographic cliff. These developers are retiring. For a long time, the strategy was just to pay them more to stick around. That's why senior COBOL salaries are hitting an average of one hundred fifty-two thousand dollars. Top earners in the ninetieth percentile are reaching over one hundred seventy-two thousand. In some cases, for a real emergency, you're seeing consulting rates that are double that.
It's a scarcity premium. It's one of the few fields where being older is a massive career asset because you're the only one who knows where the logic is buried in the code. But that brings us back to the Anthropic news. They're saying, "Hey, you don't need these retirees anymore. Our AI can read the COBOL, understand the business logic, and spit out modern Java or Python in a fraction of the time." Why did that cause such a panic for IBM?
Because I-B-M's entire business model for the mainframe is built on the idea that migration is too risky and expensive. If Anthropic can prove that an L-L-M can reliably refactor COBOL, it breaks the lock-in. But IBM fired back with a blog post called "Lost in Translation," and they have a strong point. The problem with COBOL isn't the syntax. It's the implicit logic.
Explain that. If the code is readable, why can't the AI just translate it?
Imagine a COBOL program that's been running at a bank since nineteen seventy-four. Over fifty years, hundreds of different developers have added patches and workarounds to handle specific regulatory changes or edge cases. Many of those business rules aren't documented anywhere except in that messy code. And COBOL often uses global state—everything can see everything.
So it's like a giant bowl of spaghetti, and if you pull one string in the Java translation, the whole thing might collapse in a way that isn't obvious until you're missing ten million dollars on a Tuesday morning.
Translation is the easy part; understanding the intent and the side effects is where it gets difficult. IBM is pushing their own solution called Project Bob, which is an AI-first I-D-E built on V-S Code. It's slated to replace their watsonx Code Assistant. Their argument is that you should use AI to help humans maintain and modernize the COBOL where it lives—covering R-P-G, C-L, S-Q-L, and COBOL on IBM i—rather than trying to perform a "big bang" migration to a new language.
It's a compelling clash of philosophies. Anthropic represents the disruptive AI view where we can leapfrog the legacy problem. IBM represents the incremental reality where these systems are too complex to move safely. For listeners who remember episode twelve twenty-three, we talked about agentic AI and legacy systems there too. We also touched on the "rewrite everything" trend in episode twelve twenty-two when we discussed Rust. The stakes have just gotten much higher now that the market is reacting to these claims.
What's really interesting is the sociology of it. These COBOL developers are often treated as maintenance people, but they're actually the guardians of the world's most important logic. There's a quiet pride in that culture. They see the flashy web developers moving fast and breaking things, and they're the ones who make sure the things that cannot break, don't.
It's the difference between building a sandcastle and maintaining a dam. The sandcastle is more fun, but if the dam fails, the city is gone. Back to the technical side for a second, you mentioned that COBOL doesn't have functions in the way we think of them?
It uses paragraphs and sections. You use a command called PERFORM to jump to a paragraph, execute it, and then come back. It's a very flat structure. To a modern developer used to object-oriented or functional programming, it feels incredibly primitive. There's no real encapsulation. If you change a variable in one paragraph, it stays changed for every other paragraph.
That sounds like a nightmare for debugging. How do they handle massive scale without the code becoming a total disaster?
Discipline and very strict naming conventions. But that's also why it's so hard to replace. The documentation is often just the collective memory of the team. When New Jersey's unemployment system was overwhelmed during the pandemic in twenty twenty, the governor had to go on television and ask for COBOL volunteers. They didn't just need people who knew the syntax; they needed people who understood how those specific, ancient systems were wired together.
It's a reminder that technical debt isn't just about old code; it's about the loss of institutional knowledge. If you have the code but no one who understands why a specific MOVE statement happens on line five thousand, you don't really own that system anymore. The system owns you.
And that's why I think the scarcity premium for these developers will stay high for a long time. Even if AI can do eighty percent of the translation, you still need that human expert to sign off on the last twenty percent. That's where the risk lives. If you're a young developer today, there's a strong case for learning COBOL as a secondary power skill.
It's like learning a dead language that happens to be the language of the people who hold all the money. It might not be "cool," but it's incredibly high-leverage. Looking forward, do you think we'll actually see a mass migration, or is this just another hype cycle?
I think we're moving toward encapsulation rather than replacement. Instead of rewriting the COBOL, companies are wrapping it in modern A-P-I-s. They use AI to build a sleek interface on top of the mainframe. The COBOL stays there, doing what it does best—moving numbers around with perfect precision—while the web apps talk to it through a translator.
So COBOL becomes the kernel of the financial world. You don't rewrite the Linux kernel every time you want to build a new app; you just build on top of it.
The mainframe becomes this high-performance black box. IBM is making sure their new Z-series mainframes can run Linux and AI models right alongside the COBOL. They're trying to make the mainframe a first-class citizen in the modern cloud world.
It's a smart move. It acknowledges the reality that the "big rewrite" almost always fails. We've seen so many projects where a bank tries to move to a modern stack, spends five years and a billion dollars, and then just gives up and goes back to the mainframe.
The complexity of these business rules is staggering. We're talking about fifty years of "if this, then that" logic. It's like trying to move an old-growth forest. You can't just dig up the trees and expect them to survive in a different climate with different soil.
So for someone sitting at home, wondering if their bank is about to collapse because of ancient code, what's the takeaway?
The takeaway is that the "ancientness" is actually a form of security. That code has been running correctly for longer than most of the people listening to this have been alive. It has survived every market crash and every technical shift. It's slow to change, yes, but in finance, slow to change is often exactly what you want.
It's the ultimate "if it ain't broke, don't fix it" scenario, except the cost of fixing it might actually break the world. I find it funny that in twenty twenty-six, with all our talk about A-G-I and quantum computing, we're still fundamentally dependent on a language designed before we put a man on the moon.
There's a beauty in that. It's a testament to how well Grace Hopper and that original committee understood the core needs of business. They built something so fit for purpose that it has outlasted almost every successor that tried to kill it.
And it puts the Anthropic versus IBM fight in a different light. Anthropic is betting on the power of the new to understand the old. IBM is betting on the permanence of the old to resist the new. So far, historically, the old has a pretty good track record.
I think we'll see AI making it easier to live with COBOL, but I don't think we're going to see the "COBOL apocalypse" headlines coming true anytime soon. The senior developers who know these systems are going to be in high demand until the day they decide to finally put down the keyboard.
It's a good reminder that in technology, "new" is not always "better," and "old" is not always "obsolete." Sometimes, "old" just means "proven."
And "proven" is worth thirty billion dollars in market cap, as IBM found out when people started to doubt it.
We've covered the full arc here. From Grace Hopper's vision to the market-shaking blog posts of last month. It's clear that COBOL isn't just a language; it's fundamental infrastructure, like the power grid or water lines. You don't notice it until someone tells you it might be failing.
And just like the power grid, we're constantly upgrading and patching it, but we're never going to just turn it off and start over from scratch. The stakes are just too high.
Let's move into some practical takeaways for the folks listening who might be in the tech world or just curious about how this affects them.
First, if you're a developer, don't look down on legacy systems. Understanding how to bridge the gap between "modern" and "mission-critical" is one of the most valuable skills you can have. Whether it's COBOL, or even older versions of Java, the world is full of load-bearing code that needs people who aren't afraid of it.
Second, for business leaders, the lesson of the Anthropic market dip is that AI modernization is a high-beta promise. It sounds great in a slide deck, but the market is still very sensitive to the reality of technical debt. Don't underestimate the complexity of your own business logic.
And finally, for everyone else, just have a little more respect for that A-T-M swipe. There's a sixty-year-old masterpiece of English-like prose making sure your balance is correct.
It really is a masterpiece in its own way. A very wordy, very rigid, very expensive masterpiece.
A very durable one, at that.
Well, this has been a deep one. I think it's time to wrap it up. Thanks as always to our producer Hilbert Flumingtop for keeping the gears turning behind the scenes.
And a big thanks to Modal for providing the G-P-U credits that power the AI research and generation for this show. They make this kind of deep dive possible.
If you found this exploration of the world's most durable language interesting, we'd love it if you could leave us a review on your favorite podcast app. It really helps other curious minds find the show.
This has been My Weird Prompts.
Catch you in the next one.
