The Code That Never Died
A language built during the Eisenhower administration still runs your airline. AI just made that everyone's problem.
On February 23rd, a blog post erased $30 billion.
Not a earnings miss. Not a fraud scandal. Not a geopolitical shock. A blog post, from Anthropic, the AI company behind Claude, explaining that artificial intelligence could now modernize a programming language most people have never heard of, written by people who are no longer alive, running systems that were designed before the first Boeing 747 ever left the ground.
The language is COBOL. The Common Business-Oriented Language. And if you work in airline operations, it is closer to your daily reality than you probably realize.
SABRE, incidentally, stood for Semi-Automated Business Research Environment. Anyone who has received a modernization quote recently might prefer: Semi-Automated But Really Expensive.
1964
IBM and American Airlines had been working together since 1957. The project they were building had a name that would become legendary in the history of computing: SABRE. Semi-Automated Business Research Environment.
It went live, fully, operationally live, in 1964.
To understand what that meant at the time, consider the alternative. In the early 1950s, American Airlines was managing reservations manually. Agents with card files. Telephones. Human memory. As jet aircraft began filling routes and passenger volumes climbed, the system was breaking under its own weight. A single transatlantic booking could require seventeen phone calls.
SABRE changed that. It could process over 7,000 bookings per hour with near-zero error rates. It ran on two IBM 7090 mainframes, connected to thousands of terminals, and for the first time in aviation history, a reservation system could store passenger information in memory and update seat inventory in real time.
American Airlines spent $40 million on it. In today’s money, roughly $350 million. It was, at the time, the largest private real-time data processing system in the United States. Only the U.S. government had a larger working system.
IBM, seeing what they had built, didn’t stop there. They signed contracts to develop similar systems for Pan Am and Delta. By the mid-1960s, DELTAMATIC and PANAMAC joined SABRE in production. IBM then generalized the underlying technology into PARS, the Programmed Airline Reservations System, and by the early 1970s, nine of the ten largest U.S. carriers were running on it.
In 1970, United Airlines launched Unimatic. It was still in service for operations management in 2010.
The architecture that underpins how airlines manage passengers, inventory, crew records, and financial transactions was built between 1964 and 1980. It was built in COBOL. It was built on IBM mainframes. And it was built for a world where the complexity of a flight operation was a fraction of what it is today.
That was sixty years ago.
The Iceberg
Here is the thing about COBOL that surprises people who encounter it for the first time: it did not fail.
That is the paradox at the center of this entire story. COBOL systems did not collapse under their own weight. They did not get replaced because they stopped working. They persisted, layer by layer, decade by decade, precisely because they were reliable in ways that their successors often were not.
Hundreds of billions of lines of COBOL code are believed to be active today. At least nine out of ten ATM transactions in the United States run through it. The majority of global financial transaction processing runs through it. And in aviation, the reservation, ticketing, and passenger service systems at virtually every major carrier have COBOL in their ancestry, and in many cases, still in their active codebase.
The IBM mainframe business that grew around this reality became one of the most defensible franchises in enterprise technology. COBOL modernization, updating decades-old code to integrate new technologies, comply with new regulations, meet new security standards, eliminate obsolete logic, became a pillar of IBM’s consultancy division. Morgan Stanley estimated that Mainframe and Transaction Processing made up almost one-fifth of IBM’s total revenue.
The business model was, in essence, the following: the code is too complex and too critical to touch without us. The switching cost is too high. The risk is too great. We have spent decades understanding this stack. You need us.
It worked. For decades, it worked.
February 23rd, 2026
Anthropic published a blog post.
It was not subtle about its implications. “Modernizing a COBOL system once required armies of consultants spending years mapping workflows,” Anthropic wrote. “This resulted in large timelines and high costs that few were willing to take on. AI changes this.”
Claude Code, Anthropic’s agentic coding platform, could now map COBOL workflows, translate legacy logic, identify obsolete code, and accelerate modernization projects that previously required years and eight-figure budgets.
IBM’s stock fell 13% the same day. Its worst single-day performance in 25 years. Thirty billion dollars of market capitalization, gone before close of trading.
“A blog post just wiped $30 billion off IBM’s market cap,” one business consultant noted on LinkedIn. It was not an exaggeration.
IBM responded quickly, as it should have. Two executives published their own COBOL modernization blogs within days. The company drew a clear distinction between translating COBOL and truly modernizing it. Translation is the mechanical conversion of code from one language to another. Modernization is the deeper work: data architecture redesigns, runtime replacements, the rebuilding of business logic that has been accreted across decades by people who are long retired. IBM argued, not unreasonably, that AI can do the first part. The second part still requires what they have spent forty years building.
UBS analyst David Vogt supported the thesis. “We do not expect mainframe disintermediation over the next several years given strong customer stickiness, customer data sovereignty and complex vertically integrated stack that provides quantum-safe encryption.”
Morgan Stanley was more ambivalent. Smaller organizations with fewer mission-critical workloads could move faster with external AI tools. Major government and corporate clients, the airlines, the banks, the insurers, would likely stay closer to IBM for the foreseeable future. “Sell first and ask questions later,” was how they characterized investor sentiment.
By the end of the week, IBM had recovered most of the loss. But the question the market was actually asking had not gone away. It will not go away.
What This Has to Do With Your Operation
Here is where I need to make a distinction that the financial press almost entirely missed.
The COBOL conversation is about the transaction processing layer, reservations, ticketing, passenger records, financial settlements. That is the layer SABRE and PARS and Unimatic were built to handle. That is what IBM’s mainframe business is built around. That is what Claude Code is now targeting.
It is not the same layer as operational decision-making.
Crew management. Disruption recovery. Aircraft swaps. Pairing optimization. Duty legality in real time across multiple AOCs. The logic that answers the question: what do we do now, with these people, in this situation, under these constraints?
That layer was also built in the same era. It inherited the same architectural assumptions. But it was not designed for scale, for speed, or for the complexity of modern irregular operations. And unlike reservation systems, which primarily need to be fast and reliable, operational systems need to be intelligent. They need to support decisions that are made under cognitive load, at three in the morning, with incomplete information and fifteen variables changing simultaneously.
The Southwest Airlines collapse of December 2022 was not a COBOL translation problem. Their crew scheduling system could not recover because it was built for a different era of operational complexity, one where disruptions were local, not cascading; where the network was simpler; where a human coordinator with a spreadsheet and a telephone could, eventually, work through it.
Nearly 17,000 flights were cancelled during peak holiday season. Not because the weather was uniquely severe. Because the architecture of the system matched the architecture of 1979, not 2022.
That is not a legacy code problem. That is a legacy thinking problem, the assumption that the system your grandfather’s operations team built is adequate for the operation your team runs today.
The Deeper Pattern
What the Anthropic announcement surfaced, beneath the market reaction and the IBM rivalry and the LinkedIn commentary, is something that aviation operations professionals have known for years but rarely say out loud.
The systems we run on are not fit for the decisions we are asked to make.
IATA’s data is unambiguous: 80% of airlines now identify legacy IT as a major obstacle to operations, up from 65% in 2019. Downtime from failed system upgrades costs up to $400,000 per hour. Nearly half of all digital transformation efforts fail, not because the new technology doesn’t work, but because it cannot integrate with what exists beneath it.
The airline industry spent the 1960s and 1970s building extraordinary systems for the problem it had then. It has spent the five decades since patching, extending, and layering those systems to handle problems they were never designed for.
AI is now doing two things simultaneously that have not happened before at the same time:
First, it is genuinely reducing the cost and risk of modernizing the transaction processing layer. COBOL translation is not full modernization, IBM is right about that — but it changes the economics of the conversation in ways that will compound over the next several years.
Second, and more importantly for operations professionals: AI is beginning to offer a fundamentally different answer to the question of how decisions get made during disruption. Not faster versions of the same logic. A different architecture entirely, one built around decision support, pattern recognition across irregular operations history, and the kind of anticipatory intelligence that experienced controllers develop over decades but cannot transfer to the next generation before they retire.
The Anthropic announcement was about code. But the implication is about architecture. And in aviation operations, architecture is everything.
The Outlook
I have visited over 128 Operations Control Centers across more than 80 countries. I have watched controllers navigate disruptions on systems that look, functionally, like they were designed in the same decade they were.
What I have observed, consistently, is not a lack of capability in the people. The people are often extraordinary, holding complexity in their heads that no system adequately supports. What I observe is the cost of that capability. The cognitive load that comes from fighting the tool while trying to solve the problem. The sixty to seventy percent of mental capacity that goes into navigating the system, leaving thirty to forty percent for the actual operational decision.
That is not a COBOL problem. But it is the same root cause: architecture designed for a different era, still running the most time-critical decisions in the operation.
The next five years will produce, I believe, a genuine bifurcation in the industry.
Airlines that treat the Anthropic moment as a licensing opportunity, a cheaper way to patch the existing stack, will modernize their code without modernizing their thinking. They will have newer-looking systems with the same architectural assumptions underneath.
Airlines that treat it as a signal, that the economics of fundamental change have shifted, that the era of “too expensive and too risky” has a shorter shelf life than it did twelve months ago, will make different choices. They will ask not “how do we maintain what we have” but “what would we build if we were building it now.”
The second question is harder. It requires confronting decisions made in 1964 that nobody alive at your airline made, but that everyone at your airline works around every day.
It also might be the most important question aviation operations has asked in fifty years.
The 3 AM Reading List covers the ideas, architectures, and decisions that shape airline operations, for the professionals who are still thinking about them when everyone else has gone to sleep.
If this piece made you think differently about something you work with every day, share it with someone who needs to read it.
