Eric S. Raymond, well-known computer systems author and commenter, recently commented on the potential usefulness of artificial intelligence to detect and fix errors in computer software. He observed on X:
I have to agree with him: if we turn a blind eye to the capacity of AI to fix past errors, we basically give in to cybercriminals who will have no hesitation in using AI to find such errors, and then to exploit them rather than fix them.
The scale of the problem was recently revealed.
The prevalence of COBOL is hard to overstate. Created in 1959, the “common business-oriented language” is still widely used today. According to IBM, COBOL underpins over 40 percent of online banking systems, facilitates 80 percent of in-person credit card transactions, and manages 95 percent of ATM transactions. It also supports various government systems, including Social Security and IRS operations. One estimate suggests that COBOL’s inefficiencies cost the US GDP around $105 billion annually.
However, replacing COBOL is no easy task. The same goes for other legacy programming languages like Fortran, which are still utilized in scientific computing, weather forecasting, and critical nuclear security codes. These systems are often too vital to risk breaking, and many of the programmers who once understood them have retired or passed away.
. . .
In its latest update, OpenAI shared encouraging results in migrating COBOL code to more contemporary programming languages such as C++, Java, Kotlin, Python, and Rust, all while preserving the original software’s functionality ... “These evaluation results demonstrate progress toward more accurate, affordable code migration for teams modernizing the software their businesses depend on,” OpenAI stated.
. . .
Experts ... caution that the advancements highlighted by OpenAI are still far from enabling the safe replacement of critical legacy systems ... When dealing with systems as critical as those running on COBOL, experts stress the need for absolute certainty that replacements function correctly. “In many cases, even minor differences in system behavior before and after migration are unacceptable,” Zaytsev noted. While AI can certainly provide efficiencies and speed, the complexity of legacy systems means that partial automation isn’t sufficient.
“Suppose you have a magic AI wand that handles 99 percent of your code,” Zaytsev said. “What do you do with the remaining 1 percent? That 1 percent can be a million lines of code, scattered throughout the system and potentially failing in ways you can’t even imagine.”
There's more at the link.
I couldn't agree more, particularly given that "legacy" code - originally written years or even decades ago, and since then updated and maintained in operation because of various pressures that made it uneconomic to replace - can now be almost impossible to update any further, because of the myriad internal cross-references and patchings over the years. Let me give you an example.
Way back when, I wrote the main computer program for BP South Africa's Price Book system. Every day, this program ran in batch mode to update the price charged for every single item sold by BP - engine fuels, lubricants, chemicals, whatever. When I was given the task to write it, I recommended that I do so in modular fashion: one program for fuels, one for lubricants, one for chemicals, one for specialized products, and so on. That way, if any one category needed a major update, its specialized program could be modified and updated without affecting the rest of the Price Book system. However, I was told that wasn't acceptable. I had to write one program covering every product in BP's catalog. Rolling my eyes a little, I set to work.
By the time I finished, if I recall correctly, the program was 6-7,000 lines of COBOL code. It called in dozens of computer files, moved data around through hundreds of working-storage entries to hold interim calculations and results, and had a test data file of over 5,000 product entries. It took almost a year to write, test, correct, re-test, etc. and get it into production.
By the time I left South Africa in the mid-1990's, I was told that the program now had a team of three programmers permanently assigned to it; a lead analyst/programmer designing the updates and fixes, and two programmers to implement them. It had grown to more than twice the original size, and all of the documentation I had left with it was so far out of date it was almost useless. The source code and diagrams of section activity were filled with handwritten notes, exclamation points, and even a few profanities. That wasn't due to anything lacking in the program as I'd handed it over: it was because so many modifications and changes had come down the pike that one single, monolithic program could not cope with their rapidity. It wasn't unusual for one fix to be in preparation (design), one to be in the implementation phase (programming and testing), and one going into production - simultaneously. If it was that bad then, I shudder to think what it's like today . . . assuming it's still in use, of course.
Now, imagine trying to analyze a program like that using AI. It's comparatively small compared to some very large systems out there, yet I think most AI agents and systems would battle to follow all the convolutions of the design, the code and the output. Whether authorized or malicious, they'd have a doozy on their hands!
Unfortunately, there are a lot of systems like that out there. As Mr. Raymond says, "the only way out is through". We have to gain control of the mess of our legacy systems, because if we don't, malicious actors will use them to rob us blind. Let the battle begin!
Peter
