Yes IBM license for mainframe are expensive but it never fails.
I worked on a migration project where only the tests would take a few thousand days.
Yes they could be automated, but the regulations in place required that a human sign that all the test were executed at least once by a human.
Did running the test suite take 10 years? Like literally what exactly do you mean?
The main thing that makes this difficult is that in most cases the new system is supposed to be more capable. Transactional batch processing systems are replaced with event-based distributed systems. Much more difficult to get right.
Now, 4 million people can write it.
A model being able to ingest the whole codebase (maybe even its VCS history!) and take you through it is almost certainly the most valuable part of all.
Not to mention the inevitable "now one-shot port that bad boy to rust" discussion.
One year from zero to senior doesn't sound that hard, does it? Try that with a Java codebase.
Often, understanding the code or modifying it is the easy part! I'm sure a decent amount of people on this website could master COBOL sufficiently to go through these systems to make changes to the code.
However, if I understand from my own career enough, knowing why those things are there, how it all fits together in the much broader (and vast) system, and the historical context behind all of that, is what knowledge is being lost, not the ability to literally write or understand COBOL.
I'm pretty sure they're talking about converting COBOL to Python or Go and that is the benefit. That doesn't require knowing the architecture and system design. I'm not familiar with COBOL and COBOL systems so I could be wrong... but Python programmers who can then study the system are easy to find.
I've never worked on COBOL systems specifically, but just going from my experience working on fintech problems in dense legacy stacks of various languages (java is common), that are extremely hard to understand at times, the language itself is rarely if ever the problem.
"Just need to convert it to Go or Python" is kind of getting at the fallacy I am trying to describe. The language isn't the issue (IME). I do have my gripes about certain java frameworks, personally, but the system doesn't get any easier to understand from my POV as to simply rewrite it in another language.
Even let's say it was this simple in the case of COBOL - these are often extremely critical systems that cannot afford to fail or be wrong very often, or at all, and have complex system mechanisms around that to make it so that even trying to migrate it to a new system/language would inevitably involve understanding of the system and architecture.
How big is your context window? How big is Claude's context window? Which one is likely to get bigger?
I think this is a game changer for trying to migrate secondary services like tools or batch jobs
Their company no problem grinding older developers into retirement for the sake of padding their quarterly numbers, work-life balance is hell there. They refuse to try to compete with the modern developer market, senior level pay tops out around $125k. Despite what you may have read about experienced COBOL developer pay, know that is not the average experience. The talent pool was not replenished because they did not want to pay, overseas contracting firms also stopped training COBOL developers because their contractors could earn more building modern infra on AWS, so now they're between a rock and a hard place.
I have little doubt that we are going to see a massive payments infra failure as a result of this. Not because the AI is inherently bad, but because the promises of the tech combined with terrible management practices will create the perfect conditions for a catastrophe.
I was about to comment we should all closely watch those bank statements and balances...
While I'm OK with the use of AI to understand the COBOL codebase, I understand it's a single prompt away from transformation and production. Just one executive approval away ha.
Feb 13: IBM tripling entry-level jobs after finding the limits of AI adoption
https://news.ycombinator.com/item?id=47009327
Jan 28: IBM Mainframe Business Jumps 67%
this has been going on all Feb.
And then win the contracts to do this and have sufficient bankroll that they can be successfully sued and recover damages if they screw up?
No.
Someone like accenture might eat their lunch though
If all Anthropic is offering is some kind of smart language translation, I'm not sure they will have many takers. And whatever you think about mainframes, it is quite nice that our credit card networks work as efficiently and reliably as they do.
Oracle is trying (and mostly failing) at frontier model training
The threat is that nobody is going to be asking "we did it because we could do it, but nobody asked if we should do it" about almost any change coming down the line.
> Yes, the computer did arrive "just in time." But in time for what? In time to save--and save very nearly intact, indeed, to entrench and stabilize--social and political structures that might have been either radically renovated or allowed to totter under the demands that were sure to be made on them.
- Joseph Weizenbaum, Computer Power and Human Reason (1976) pp 29-30
That number sounds enormous. If the same code runs on 10,000 ATMs, are they counting that 10,000 times?
Cobol is an extremely verbose programming language, and it was used in an era when the practice of programming was much less developed. Calls into libraries were often not used, and instead any re-used code was copied, essentially inlined by hand. (With all the obvious problems that caused.)
The combination of automating complex processes, requiring embarrassing amounts of code to do simple things, re-use by copy and the fact that it was dominant in it's field for such a long time (4 decades!), the amount of COBOL code that exists out there is just staggering.
The main problem with these code bases are they predate modern coding practices, so the sheer size, incomprehensability and untestability will crush you. You can easily spend your whole carreer reading the source code and reach pension age before you finish. Also, the organisational difference between 2 code bases is much bigger than modern code bases, as every company invented their own practices, and people rarely switched companies so didn't know what others were doing.
Of course, nobody these days asks "why?"
If it ain't broke ...
Banks have tons of money (OPM!) and IMO, could rewrite legacy code, but
why?
There’s hardly any room remained for LLM.
IF, and it’s a big if, Claude make it possible to migrate off of COBOL, this would be a massive blow to IBM.
IEEE 754-2008 defines decimal floating point arithmetic that is compatible with COBOL and is usually implemented using the Intel Decimal Floating Point Math Library on commodity hardware.
For a typical core banking ledger application, the performance cost of a software implementation of DFP (vs. having DFP hardware instructions) is pretty low, and greatly outweighed by the benefits of being able to use commodity hardware and more maintainable languages.
If a change of platform is the real objective, why not compile the COBOL for the ARM or Intel server?
I’m porting my whole codebase to cobol!
I write SAAS suites for archeological sites.
I have trouble getting people to even look at C code these days. I don’t understand why devs are so afraid of old things.
Times are a changin'
Imagine all your data is Reddit threads and now I ask you what follows “goto”, how would Reddit help you?
The opposite is likely true - there isn’t a ton of publicly available cobol code compared to e.g React, so an LLM will degrade.
If it looks as all like the company might be a victim, not a benefactor, of AI - they’re going to take a hit. Especially when they’ve all been selling AI and layoffs as their source of growth.
These tech stocks can’t all be AI winners. And sorting out winners / just another boring tech company will be how the “AI bubble” pops.
Consider that back in the day, we once had a situation where the shared runtime library supporting a programming language on Megabank's PROD cluster was updated from something like 4.1.1 to 4.1.2 after months on its TEST cluster, plus lots of formal meetings, planning, pages of signatures, contingencies, extra ops people onsite, etc. --and Megabank still proceeded to loose more than ten grand per minute after pressing [Return] on that update. At least a dozen people lost their jobs at the following Friday morning meeting. It turned out that a subtle change in the vendor's implementation of a floating point function was not caught because testing didn't consider enough digits of precision. Mind you NO CODE WAS CHANGED, only a dynamically linked runtime library SUPPLIED BY THE COMPUTER MANUFACTURER --not a third party. Point being (no pun intended), when you go monkeying around with stable production systems that are doing On Line Transaction Processing (OLTP), "bad things" happen, treasure and careers are in jeopardy --and COBOL Life is all about what goes on inside of those systems.
Anthropic is great at gorilla marketing with all their PuRe BS and AI hype. Bottom line for the young peeps here:
1. There is really NO WAY IN HELL that any CIO at a credible Financial Institution will ever authorize a hallucinating chatbot to convert their core logic from COBOL to Python and Go.
2. The only way such institutions "escape" COBOL is through M&A (data --not code-- exported to the new entity's system).
3. As far as COBOL devs tapping out, that happened a very long time ago. (How many of you knew that COBOL was codeveloped by the late mathematician US Navy Rear Admiral "Amazing" Grace Hopper who also invented the first compiler?) COBOL is a simple computer language from a simpler time that enabled non-tech professionals from adjacent fields (like Accounting) to become application programmers (or "implementors" in the parlance of that era). Making minor changes to COBOL code such as PIC layouts and COMPUTE statements is no big deal that requires waking up a 95 year old, the problem is strictly related to production change control (like what version of the compiler and runtimes are you using to rebuild the production binary, etc.) and that isn't even specific to COBOL, except that it is better understood with more modern languages like C (but still remains an alien concept to almost an entire generation that entered the trade after 1997 due to all of the senior level people outside of a handful of tech companies being forced to crack open their 401Ks and move on to other fields during the dot-com crash).
----
Ken Lay died an innocent man --he had a heart attack before his sentencing. He was brought down by whistleblowers. Hang tough peeps. Fight. Back. Against. AI. Bullshitters. https://youtu.be/qJiALpiqpk8
https://www.zerohedge.com/news/2025-06-11/israeli-lawmakers-...
https://www.zerohedge.com/political/black-fatigue-goes-viral...
