AI Tackles Aging COBOL Systems as Legacy Code Expertise Dwindles 73
US government agencies and Fortune 500 companies are turning to AI to modernize mission-critical systems built on COBOL, a programming language dating back to the late 1950s. The US Social Security Administration plans a three-year, $1 billion AI-assisted upgrade of its legacy COBOL codebase [alternative source], according to Bloomberg.
Treasury Secretary Scott Bessent has repeatedly stressed the need to overhaul government systems running on COBOL. As experienced programmers retire, organizations face growing challenges maintaining these systems that power everything from banking applications to pension disbursements. Engineers now use tools like ChatGPT and IBM's watsonX to interpret COBOL code, create documentation, and translate it to modern languages.
Treasury Secretary Scott Bessent has repeatedly stressed the need to overhaul government systems running on COBOL. As experienced programmers retire, organizations face growing challenges maintaining these systems that power everything from banking applications to pension disbursements. Engineers now use tools like ChatGPT and IBM's watsonX to interpret COBOL code, create documentation, and translate it to modern languages.
Oh what a chance! (Score:4, Insightful)
getting in as a contractor to try and understand and fix this disaster mess they are going to create is going to be so lucrative⦠Oracle, Accenture creaming themselves over this news.
Re:Oh what a chance! (Score:4, Insightful)
Wait until they find out today's Cobol programmer is 25, Indian, and had better offers everywhere else.
Re: (Score:2)
Re: Oh what a chance! (Score:1)
Re: (Score:2)
Oracle doesn't fix anything. They rip and replace. They they try to fix broken things they installed...
SAP (Satan's preferred means of interaction with our world) prefected this already. Run from both.
They are planning on doing this wrong. 3 years? Wrong. $1Billion? Wrong.
Start up the AI and let it rewrite Cobol into C++ and Rust. Iterate. Run in parallel. Cut over when the new system has less terrible than the old one.
And you can't let the people who never bother to think ahead and solve this lead this. Th
Re: (Score:1)
Re: (Score:2)
If you don't understand what's wrong with your proposal then you shouldn't go near one of these systems. If you were making a sarcastic joke then you deserve an upvote (sorry I have no modpoints).
Oh goodie! AI and technical debt all in one! (Score:3, Insightful)
Now the question is, does it cost more to train a human coder to understand cobol so he can rewrite the software or does it cost more to train a human coder so he can tell whether the AI rewrote the software correctly?
A more serious question I have is whether the AI tools can tell when they're out of their depth with domain-specific knowledge, whether they will simply translate cobol spaghetti into java or .net spaghetti, or whether they will produce garbage when faced with some "clever and subtle" logic in the source.
The Question Before That (Score:4, Insightful)
Now the question is....
No, that's the second question. The first question is: "Do you know that AIs hallucinate and that you cannot just trust the AI to recode everything by itself correctly?".
Re:The Question Before That (Score:4, Insightful)
As if you can trust your junior programmer to get it right the first, second, or third time. As if you can commit their code to production without testing first.
I hope you're not in charge of anything. I'm not, so I can pontificate based on what I've seen,
Re: The Question Before That (Score:2)
Re: (Score:2)
Re: (Score:2)
Your first question seemed to question that. Indeed, if I were leading a programming project, I could care less the source of method of generating the code. It all has to be evaluated, tested, and then tested again. Time pressure does not obviate the need.
Re:Oh goodie! AI and technical debt all in one! (Score:4, Insightful)
That is the wrong question. A rewrite in a different language is a really dumb thing to do unless there is no way to keep the old code working, as a rewrite will rarely fix problems but always will introduce new ones and will be expensive, slow and may completely faul. Now, I do not know how compatible COBOL is, but, for example, GNU COBOL is under active development and maintained and had its last major release ion 2023. That does not strike me as something that need to be abandoned.
The smart thing is to just get people that can maintain the old code and, if needed, learn COBOL in a reasonable amount of time. Yes, that means an attractive salary and working conditions. But these people exist. You just need to stop cheapening out when hiring real, experienced engineers.
As to AI, all it can do is make things worse and even harder to maintain. That approch is a completely dumb idea by people lacking insight and experience.
Re: (Score:2)
Older languages have a lower innovation velocity than newer, more popular languages.. They are reliant on a handful (often, one) of companies to keep up with new technology and new approaches.
I'm not just some punk techbro saying this: I have a lower user # than you.
Re: (Score:2)
Why the need for "higher innovation velocity" in a programming language as if it was an end by itself?
A stable well-defined language is good, as it allows multiple compiler/interpreter implementations, and the code will run unchanged for many decades. How old is the average COBOL code? 40-50 years old? Isn't it wonderful that code that old still runs?
Python is one of those "innovating" languages.
The language is constantly in flux, forcing code rewrites of perfectly good code because the Python language main
Re: (Score:2)
And "innovation velocity" matters how to software _maintenance_? You may have a lower ID than I, but you for sure do not understand what this discussion is about...
Re: (Score:2)
More importantly, offer long term job stability and a golden parachute. It's necessary, because otherwise a long stent of COBOL on a resume is an express ticket to the round file. If they're going to get developers to learn COBOL, they'll need to offer them the last job they'll even need.
Re: (Score:2)
I disagree on the "last job", but people that can do these things may require it nonetheless. We are not talking about average "coders" here.
Re: (Score:2)
My first reaction to "hey let's just feed this 800 million line codebase into an AI and cross our fingers" was "yeah, that's totally easier than just having some people learn COBOL. I mean, it's not like there are any books or study materials from the last 70 years of it existing..."
I remember having a COBOL college textbook in the late 90s. I doubt they are out of print.
Re: (Score:2)
An Amazon search for COBOL books lists about 300...
Re: Oh goodie! AI and technical debt all in one! (Score:3)
Re:Oh goodie! AI and technical debt all in one! (Score:4, Insightful)
Now the question is, does it cost more to train a human coder to understand cobol so he can rewrite the software or does it cost more to train a human coder so he can tell whether the AI rewrote the software correctly?
A more serious question I have is whether the AI tools can tell when they're out of their depth with domain-specific knowledge, whether they will simply translate cobol spaghetti into java or .net spaghetti, or whether they will produce garbage when faced with some "clever and subtle" logic in the source.
Now the question is, does it cost more to train a human coder to understand cobol so he can rewrite the software or does it cost more to train a human coder so he can tell whether the AI rewrote the software correctly?
We wouldn't have to do any of that if CIS and MIS programs would quit telling their students that COBOL is dead. COBOL has been "dying" all my adult life, according to the experts, and yet is so deeply embedded in certain sectors that it's never going away in our lifetimes. It's pretty much guaranteed work. Offer more COBOL classes and tell students that in major corporations and the federal government (especially the IRS) COBOL will be here until doomsday. Tell them that as long as mainframes exist, COBOL will be used. A paycheck is a powerful inducement to learn.
If you're smart, learn or get back in COBOL today (Score:3)
When AI is done fucking up everything, there will be a lot of money to be made fixing the disaster by hand.
Re:If you're smart, learn or get back in COBOL tod (Score:5, Interesting)
Nope, not a chance, it's not worth it. I wrote COBOL professionally for 5 years from 1988 to 1993. I then spent several more years helping customers migrate from COBOL to...anything else. There's no way I want to deal with that mess again, not even for good money.
Re:If you're smart, learn or get back in COBOL tod (Score:4, Insightful)
I'll do it. I spent 15 of my 30 years as coder deep in unpleasant legacy tech. I enjoyed it anyway, even when it was a giant pain in the ass. I don't need to be coding the new hotness to enjoy my work. I'll happily field a gigantic, thorny problem - especially if I'll make decent bank doing it.
Give me legacy any time. Love it. Nom nom nom...
Re: (Score:2)
Yep, different strokes for different folks!
Re: (Score:2)
100% agree. I even have a some DATABUS experience, if that helps. I'd honestly rather do that than pick up the newest wizbang framework and try to innovate - one of those codebases is a lot more likely to be around in 5 years.
Re: (Score:2)
I've honestly never understood this idea that someone is "better" than learning some language being used to do useful work. It all pays the god damn same whether you're shaking your fist at React being stupid or COBOL being old and archaic.
Re: (Score:2)
Re:If you're smart, learn or get back in COBOL tod (Score:4, Informative)
The sad thing is, COBOL programmers don't actually go for that much. According to Salary.com, about $93K on average. https://www.salary.com/tools/s... [salary.com] That would seem to indicate that, after all these years, the demand for COBOL developers is still lower than the supply.
Re: (Score:2)
I was a COBOL jockey on Wang VS systems in the late 80's and well into the 90's. Kinda hated it at first, but it grew on me. I'd be willing to come out of retirement for a few hundred bucks an hour.
No, there won't. That's not how contracting works (Score:3, Interesting)
For companies, not for individuals. The government will very likely never approve a labor rate that comes out to a well above market salary unless the SSA is blessed with contract officers who genuinely understand the difference between some garbage contractor from InfoSys or IBM consulting and a real COBOL SME.
As an individual, you would be better off not adding the black hole of "I did COBOL legacy development" to your resume and let the
Re: (Score:2)
I learned from the DOGE thing that the government has a special job class over the regular pay grades that starts at $150k or so. If Big Balls was worth it, so is a good COBOL hire.
Re: (Score:2)
And I'm sure Oracle and Accenture will be right there to bid on it.
mission critical code (Score:4, Insightful)
Good thing they are choosing mission critical code to apply new tools built on poorly understood technology that "hallucinates" as part of normal operation.
Re: mission critical code (Score:2)
So will government surveillance programs collapse?
Re: (Score:2)
No, the surveillance hides between the lines of source code. The language does not matter (though one-liners can help).
Re: (Score:2)
The people running the government surveillance programs wouldn't let these chuds within a city block of their code.
This is just the Heritage Foundation shitgibbons running the show really intent on fucking up Social Security so they can make an argument about how broken it is, and it would aaaaaalllll be better if it was privatized.
I mean, look at the stock market, and how awesome that's been for everyone's private retirement accounts lately, yeah?
Plenty of programmers, they don't want to pay. (Score:3, Insightful)
This is nothing more than the usual ITAA-style fear mongering designed to excuse the desire to not pay seasoned professionals what they are actually worth.
Re: (Score:2)
People are lazy and cheap. They would rather 1) not do the hard work and 2) spend the least money needed to replace systems. So where the Cobol code might get tricky to handle edge cases, the replacement code won't cover the edge cases and the people in charge might just say, "Welp?"
Re: (Score:2)
Indeed. Finding people that can maintain an old COBOL system is entirely possible. But you have to pay well and make it attractive.
the code itself is usually not the problem (Score:3)
Correct me as needed, but ... (Score:2)
My understanding is that there's nothing inherently wrong with COBOL for these types of use cases, so what's wrong with simply enticing more people to either (a) stay longer and/or (b) learn it and these systems. I mean, good pay and benefits, and not hassling people, usually goes a long way in job satisfaction. Also, they're going to need experienced and knowledgeable people to seriously check the AI conversion work, and probably more than a handful ...
Re: (Score:2)
What's wrong with enticing people to stay longer is that one's coding skill decline as one gets past 60. (Short term memory declines.)
What's wrong with teaching more people is that the jobs are limited AND declining. So new COBOL programmers can look forward to a short career, with only limited job prospects.
Technically, COBOL is a good language. But it's foul enough to work in that I chose PL/1. (Of course, I usually used Fortran, so I'm biased.)
Re: (Score:2)
Indeed. This is just new->better stupidity. The problem is that management does not want to pay for real engineers (that can learn any language given a reasonable amount of time) and make the jobs otherwise attractive.
Any idiot (Score:4, Insightful)
US government agencies and Fortune 500 companies are turning to AI to modernize mission-critical systems built on COBOL
Any idiot can do a good job of taking 1 COBOL program and convert it to something else. But putting these multiple converted programs together will always be a big fail. This goes for AI and any language to language conversion
What is needed is people who knows the full business processes to do this, that is what is always missing in these COBOL conversions. No one knows the "why" in these old processes.
For a good modern example, look at all the compaines that failed to implement SAP, if implemented, how it takes years to get it "right".
Using AI will not work anytime soon.
Re:Any idiot (Score:4, Insightful)
And there is also another little problem: Converted code does not get simpler. It gets more complex. And that means fixing all those problems the old COBOL code had would have been a lot simpler (or more possible) than doing that in the new code. Obviously, the new code will have all the old problems and thens ome new ones on top.
We can rewrite all the COBOL in C++ (Score:4, Insightful)
Depending on the project, it might be as cheap as $10m per project. But perhaps closer to $150m for more complex systems.
It would take months or years just to collect requirements before a single line of coding can begin.
This is just a ballpark estimated dollar amount on the technical debt an old COBOL system has. Turns out if you tweak something for 40 years, a lot of value accumulates there.
For some businesses, replacing your software stack would be like McDonalds deciding to start over on all their recipes for their menu. Without down time, and without losing any customers. It's theoretically possible, but let's be realistic, it's going to be ugly.
Re: (Score:1)
Depending on the project, it may well be impossible. In any case it comes with a huge risk of dailure. At some complexity, reimplementation is not anymore within what the human race can do. And you cannot just simulate those 40 years in another 40 years either, because that is also outside of what is possible at the current tech-levels.
Far better to actually continue to use that COBOL code and pay some people with the skills and aptitide to learn COBOL and maintain it. Yes, you may end up paying $250'000 or
Re: (Score:2)
It's always possible. Just not necessarily a net savings. Cutting corners like not creating a parallel system for a zero downtime migration strategy, for example using the old system for existing customer and provisioning new customers only on the new system, then migrate old customers over in batches.
At some complexity, reimplementation is not anymore within what the human race can do.
I don't accept that argument.
Far better to actually continue to use that COBOL code and pay some people with the skills and aptitide to learn COBOL and maintain it.
I'm happy to take the job. But my rate, just for a single person, is much higher than what hiring a NodeJS backend developer and DBA combined would be.
If the system you have meets
Re: (Score:2)
It's always possible. Just not necessarily a net savings. Cutting corners like not creating a parallel system for a zero downtime migration strategy, for example using the old system for existing customer and provisioning new customers only on the new system, then migrate old customers over in batches.
At some complexity, reimplementation is not anymore within what the human race can do.
I don't accept that argument.
Which simply means you are incompetent. Hence no reason to even talk to you, you have nothing to offer.
The Most Readable Computer Language Ever (Score:4, Insightful)
Today's software engineering graduates can't read what is arguably the most "readable" computer language ever invented? The challenge is not understanding what individual lines of code do (any junior can understand "add", "compute", and "perform), the problem is in understanding what the program(s) do, and how they interact. These are not a language-specific concerns. Automating the translation of "opaque" code with ChatGPT doesn't address the problem, because you're left with the same questions: What should this program do, and is it doing it correctly?
Goog luck with that (Score:2)
Incidentally, COBOL expertise is not dwindling. Any really good coder or CS type can learn it in a reasonable time-frame. Same as any other lamguage, whether old or new. The PHBs just do not want to pay for people on that skill-level, hence "shortage".
Re: (Score:2)
Sure, but I'd rather figure out what the program does (or is supposed to do) and recreate it in almost any other language, because whatever COBOL I learn isn't going to be the reality of these real-world COBOL programs. There are too much random shit and too many variants that any sense of a "standard" is thrown out the window.
The fact of the matter is, if you run an organization that uses custom made internal software, you should update that software's codebase every so often. Especially, if the one you ar
Re: (Score:1)
COBOL isn't a good language, technically or otherwise.
COBOL has a far better track record for backward compatibility than Python.
If you have zillions of lines of COBOL, you don't have to spend as much time and resources rewriting, redocumenting and retesting stuff just because some hipster broke backward compatibility for something.
Whereas if you have zillions of lines of Python, you might never finish rewriting and retesting stuff just because every few years Python breaks backward compatibility. It will be a while before AI is going to be able to automatical
I thought that the 1950s were so great? (Score:2, Interesting)
Why move away from a computer language that made america great in the first place?
Shouldn't they be making it great again by increasing COBOL use?
Wait! (Score:4, Insightful)
3 years? I thought Musk said 6 weeks to rewrite the system in Java?!?!
Re: (Score:2)
It's almost like he routinely underestimates the amount of time it takes to ship something by orders of magnitude!
Just say the silent part out loud (Score:3)
Most COBOL developers are older and know what they are worth to the market. They are also more likely to not be able to be replaced with a H1B or offshore company, as COBOL predates most of that workforce.
This is just trying to save a buck. And it will probably mess up a lot of stuff in the process.
And who maintains translated code? (Score:2)
If AI wrote the translated code, maybe it can be used to maintain it. My experience with code translated by tools from one programming language to another is that much is lost and the result is very difficult to understand. In particular the "gestalt" of the actual written code, the semantics of the language used by the code, and the associated comments gets lost in machine translation.
But maybe this would work, because AI can either establish/maintain, or sufficiently reproduce, sufficient understanding.
Re: (Score:2)
But maybe this would work, because AI can either establish/maintain, or sufficiently reproduce, sufficient understanding. But of course, HOW WILL WE KNOW? Or do we just have to trust that the AI got it right?
Any reasonable effort would be run in parallel to the existing production system with the same inputs, in order to verify each and every one of the outputs to be the same. And then you would go back and run the last 20 years of data and make sure it's 100% accurate.
That at least would give a chance at believing it was done properly.
Deep learning should be easy (Score:1)
COBOL... the hill AI will die on (Score:2)
Re: (Score:2)
I almost wonder if they could feed it every rule and regulation on the books for the Social Security Administration and all relevant statutory law and regulations in the Federal Register in addition to any internal documentation or specs they have (even if from archives) while also training it on COBOL, and then see what you get?
At the very least it could gin up a nice test suite off of all of that for the CI pipeline...
Re: COBOL... the hill AI will die on (Score:2)
COBOL is not hard to learn (Score:3)
What the fuck, just hire a good software engineer and they'll learn COBOL fine, exactly how they learned every other language they know, and then they'll maintain the code for you. It's so weird how people treat is like ancient magic as if people can't just learn it. The ACTUAL problem is multi-billion dollar corporations don't want to spend a single dime on a dedicated COBOL maintainer's salary because that would be less money for stock buybacks.