A COBOL program has been operating continuously since about 1978 somewhere in a government data center that is rarely visited. At the moment, no one at the agency has a thorough understanding of how it operates. The author passed away in 2011 after retiring in the middle of the 1990s. Benefit payments are processed by the program. Every night, it operates. It hasn’t broken yet. In the sentence, the word “so far” does a lot of work.
The developers developing AI systems or delivering new cloud infrastructure are not the ones preventing the collapse of the world’s legacy code. They are a completely distinct group; they are older, more reserved, less well-known, and frequently work alone.

When a bank’s nightly batch processing encounters an error that no one else can read, they are the COBOL experts who step in. They are the open-source maintainers who oversee a library that is downloaded by millions of apps, who release security updates at midnight after a vulnerability is discovered, and who work on their own time without receiving payment or official recognition. They are the systems engineers who have maintained an aircraft routing system for twenty-seven years despite four hardware generations and three ownership changes. Since no one ever documented the system’s actual operation, they carry the institutional knowledge of how it functions in their minds.
It is simple to underestimate the extent of the dependency. Approximately 95% of ATM transactions and 80% of in-person financial transactions worldwide are still processed using COBOL, a language created in 1959. Many nations’ power grid control systems are powered by software built in early C, sometimes even before the internet. Underneath the contemporary dashboards and user interfaces are layers of code that are frequently older than the people attempting to maintain them. Examples of these systems include government benefits administration, insurance policy processing, and air traffic control handoff systems.
The knowledge crisis develops gradually at first, then all of a sudden. This software was written by programmers who are retiring. Not in ten years, but right now. Many have already left the company, and when they do, they take with them a detailed grasp of why a certain piece of code was created the way it was, what edge cases it handles, and what would break if you touch it. Because the authors did not foresee that anyone would need to read the documentation forty years later, some of this knowledge was never recorded. By then, they anticipated that the program would have been replaced.
Although it has a different character, the open-source dimension is just as unstable. According to a study on software supply chains, a sizable portion of popular open-source libraries—components found in government software, banking apps, and healthcare systems—were maintained by a single person, frequently for free, and frequently on the weekends and evenings. The library stops getting security patches when the individual burns out, changes jobs, or just ceases responding to issue reports. Applications that rely on it continue to function. The vulnerabilities remain unresolved. The clock is running.
When questioned about this, the industry points to the Knight Capital Group incident from 2012 as a warning. During a software deployment, a long-dormant legacy code component was unintentionally reactivated. Before anyone realized what was going on, it sent erroneous trading orders for forty-five minutes. The company suffered a $440 million loss. It was obtained in a matter of months. The breakdown was precisely the kind of thing that occurs when modifications are made to systems that are not completely understood; it was not unusual nor unexpected.
This problem is truly challenging to handle because it defies conventional methods. The COBOL cannot just be rewritten. Attempts to convert outdated banking systems to more current code have been costly and publicly unsuccessful; the migration initiatives that do succeed typically take years longer than planned and cost several times as much as anticipated. The pipeline of COBOL programmers is aging in tandem with the code itself, so you can’t just hire more of them. Additionally, the economics of open-source development have never adequately paid the most important maintenance work, making it difficult to incentivize open-source maintainers.
