Banks remain with COBOL because it's unsexy and stable. And then they say... let's just YOLO some vibe code into the next release sight unseen! Logic checks out.
They stick with COBOL because it runs well on the mainframe. The mainframe and sysplex architecture gives them an absurd level of stability and virtualization that I don't think the rest of the market has nearly caught up to yet. Plus having a powerful and rugged centralized controller for all of this is very useful in the banking business model.
This is the reason. IBM Mainframe business grew 60%. The modern mainframe is the best state of the art platform for computing, in both reliability and efficiency.
Also, IBM mainframes are wonderfully isolated from physical hardware. They could change processors in the next model, and users would notice a small delay as binaries were recompiled on-the-fly the first time it was used.
They surely could extract more performance from the hardware by shedding layers, but prioritized stability and compatibility.
I don't think learning how to write COBOL was ever a problem. Knowing that spaghetti codebase and how small changes in one place cause calamity all over the place is. Those 4 people's job is to avoid outages, not to write tons of code, or fix tons of bugs.
In my experience, learning COBOL takes you a week at most, learning the "COBOLIC" (ha ha) way of your particular source base will take you a couple of months, but mastering it all including architecture will take you a year, half a year if you're really good.
One year from zero to senior doesn't sound that hard, does it? Try that with a Java codebase.
I would say more significantly, 4 million people can read it. The changes required for any given quarter are probably miniscule, but the tricky part is getting up to speed on all those legacy patterns and architectural decisions.
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.
This seems to make the classic mistake that everyone makes when they conflate two things as the same - programming and business logic/knowledge (and I'd also throw in complex systems knowledge there too).
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.
This is fintech - I've not worked in banking specifically, but fintech (or fintech adjacent) most of my career, and from my POV these things can get insanely complicated in very unintuitive ways because the financial world is messy and complicated.
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.
> 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
How big is your context window? How big is Claude's context window? Which one is likely to get bigger?
Sure yet admin vs engineering in terms of jobs ... one is now on the decline either slowly or quickly. Now it requires 1/4 to 1/2 of the engineers once employed in the profession. I dont see how that's a good thing for any economy.
I think I've seen 2 initiatives to move off of AS/400 to a something else in my lifetime and neither one completed. One was at a bank another at an insurance company. Not to mention that a typical COBOL programmer is more interested in retiring than learning to vibe code. At this point I think the software stocks have reached peak panic and hysteria. There is just no rhyme or reason for sharp declines like this.
the COBOL migration part is probably the least of IBM's moat tbh. what's sticky is that the actual risk of a migration is 5% technical and 95% organizational -- regulatory sign-offs, audit trails, test coverage for systems that haven't had tests written in 40 years. AI can generate the Rust/Java equivalent but it can't own the migration project. that's still IBM consulting's territory for a while.
LOL, anyone who thinks an LLM is smart enough to untangle 50+ years of cobol spaghetti has obviously never worked at a bank or insurance or railroad or.....
Off the shelf, sure. On the other hand, I wonder if domains that require the strictest rigor may have retained a high degree of good change documentation and tests that could be included in training.
What are you implying 5 years of experience as a Product technical delivery architect influencer and some basic web development skills don't transfer to writing critical software?
So curiously I wonder if it's not that Anthropic/Claude can do this magically. More like can individuals at IBM who are heavy hitters just leave and create their own company and effectively provide these services because AI gives them the productivity to do so?
Relevant to Colombia's payment infra fragility: Bancolombia outage blocks transfers to Nequi/other banks since Feb 22 (IBM machine failed in maintenance).
~70% of national txns (100M+ /6mo, 600K interbank/mo). Daily USD flows: $50M+ A la Mano + Nequi peaks $100M+.
Single-vendor risk in billion-scale retail payments? Details: https://www.bloomberglinea.com/latinoamerica/colombia/caidas...
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.
This makes no sense. If IBM supposedly gets a significant amount of revenue from COBOL (a dubious proposition) then wouldn't this actually help them as COBOL programmers are getting rarer and rarer?
IBM makes a lot of money selling mainframes to companies that have COBOL codebases dating back to the 70s or earlier. The main reason said companies still buy mainframes to run said COBOL programs is because it’s too risky to try to port them to more standardized, cheaper platforms. THEORETICALLY, a COBOL-proficient Claude could make it feasible to port these old COBOL codebases to something more modern that can run on bog-standard x86 servers, and it’s unlikely customers would buy them from IBM.
IF, and it’s a big if, Claude make it possible to migrate off of COBOL, this would be a massive blow to IBM.
Nothing is so difficult about COBOL. It’s just old-fashioned and everything surrounding it is legacy. Most people seem to think it has a negative value when placed on a resume. Maybe that’s true, I don’t know.
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.
I have a close relative at one of the biggest COBOL shops in the US, and something tells me we're about to find out how we take the stability of our payments infrastructure for granted.
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.
> how we take the stability of our payments infrastructure for granted.
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.
"After all, if Dario Amodei had bought puts on IBM, and the dozens of companies that have plunged more than double digits in recent weeks, he would have made billions, certainly enough to fund his company for months if not years. "
Anthropic put out another blog post about modernizing/migrating away from COBOL several months ago IIRC, it is surprising that this was not priced in already
It's quite the contrary, the less interpretative the language, the better. And no, LLMs were not trained on English to begin with. And they don't perform best in English.
Please expand more on the idea that LLM's are not trained on English to begin with. Not sure what you mean by this as clearly many LLM's are trained on data that contains a lot of English. For instance GPT-1 seems to have been trained on a purely English corpus.
That’s not how it works. Being trained a ton of human text doesn’t mean you can complete the next token for a program that needs to be logically coherent.
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.
Banks remain with COBOL because it's unsexy and stable. And then they say... let's just YOLO some vibe code into the next release sight unseen! Logic checks out.
Banks remain on COBOL because of the quantity of code that's been tested in real life situation for decades.
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.
What do you mean "only the tests would take a few thousand days"?
Did running the test suite take 10 years? Like literally what exactly do you mean?
They stick with COBOL because it runs well on the mainframe. The mainframe and sysplex architecture gives them an absurd level of stability and virtualization that I don't think the rest of the market has nearly caught up to yet. Plus having a powerful and rugged centralized controller for all of this is very useful in the banking business model.
This is the reason. IBM Mainframe business grew 60%. The modern mainframe is the best state of the art platform for computing, in both reliability and efficiency.
Also, IBM mainframes are wonderfully isolated from physical hardware. They could change processors in the next model, and users would notice a small delay as binaries were recompiled on-the-fly the first time it was used.
They surely could extract more performance from the hardware by shedding layers, but prioritized stability and compatibility.
Banks remain with COBOL because they have a fuckton of COBOL code and 4 people can write it. There's nothing more to it.
Now, 4 million people can write it.
I don't think learning how to write COBOL was ever a problem. Knowing that spaghetti codebase and how small changes in one place cause calamity all over the place is. Those 4 people's job is to avoid outages, not to write tons of code, or fix tons of bugs.
In my experience, learning COBOL takes you a week at most, learning the "COBOLIC" (ha ha) way of your particular source base will take you a couple of months, but mastering it all including architecture will take you a year, half a year if you're really good.
One year from zero to senior doesn't sound that hard, does it? Try that with a Java codebase.
I would say more significantly, 4 million people can read it. The changes required for any given quarter are probably miniscule, but the tricky part is getting up to speed on all those legacy patterns and architectural decisions.
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.
You also need "make no mistakes"
Run both systems side by side for 9 months. Banks have patience.
I would have you nnowhere near my production
Or production for the bank with my savings.
It's got to be a lot more than 4. Global Shop (ERP) is written in Visual COBOL.
This seems to make the classic mistake that everyone makes when they conflate two things as the same - programming and business logic/knowledge (and I'd also throw in complex systems knowledge there too).
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.
> knowing why those things are there
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.
This is fintech - I've not worked in banking specifically, but fintech (or fintech adjacent) most of my career, and from my POV these things can get insanely complicated in very unintuitive ways because the financial world is messy and complicated.
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.
> 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
How big is your context window? How big is Claude's context window? Which one is likely to get bigger?
RAM had been sold out so…
I call it the "how hard could it be" fallacy.
Right in the "it takes 15 minutes to do it" category.
Sure yet admin vs engineering in terms of jobs ... one is now on the decline either slowly or quickly. Now it requires 1/4 to 1/2 of the engineers once employed in the profession. I dont see how that's a good thing for any economy.
I think I've seen 2 initiatives to move off of AS/400 to a something else in my lifetime and neither one completed. One was at a bank another at an insurance company. Not to mention that a typical COBOL programmer is more interested in retiring than learning to vibe code. At this point I think the software stocks have reached peak panic and hysteria. There is just no rhyme or reason for sharp declines like this.
I've seen a successful one where COBOL was converted to ".Net" and heard they were applying the same process to another client a few years ago.
I think this is a game changer for trying to migrate secondary services like tools or batch jobs
It does seem like a good time to buy IBM stock.
Yeah it’s exhausting. Part of me wants the bubble to pop but another part realizes a lot of my stock is now tied up in it lol
the COBOL migration part is probably the least of IBM's moat tbh. what's sticky is that the actual risk of a migration is 5% technical and 95% organizational -- regulatory sign-offs, audit trails, test coverage for systems that haven't had tests written in 40 years. AI can generate the Rust/Java equivalent but it can't own the migration project. that's still IBM consulting's territory for a while.
LOL, anyone who thinks an LLM is smart enough to untangle 50+ years of cobol spaghetti has obviously never worked at a bank or insurance or railroad or.....
Off the shelf, sure. On the other hand, I wonder if domains that require the strictest rigor may have retained a high degree of good change documentation and tests that could be included in training.
What are you implying 5 years of experience as a Product technical delivery architect influencer and some basic web development skills don't transfer to writing critical software?
It's not even "Our product can write COBOL", it's "Our product can analyze your COBOL codebase and generate a plan for migrating to a new tech stack".
So curiously I wonder if it's not that Anthropic/Claude can do this magically. More like can individuals at IBM who are heavy hitters just leave and create their own company and effectively provide these services because AI gives them the productivity to do so?
Step 1. sell your shares Step 2. freak out retail investors Step 3. buy the dip Step 4. back to Step 1.
this has been going on all Feb.
Relevant to Colombia's payment infra fragility: Bancolombia outage blocks transfers to Nequi/other banks since Feb 22 (IBM machine failed in maintenance). ~70% of national txns (100M+ /6mo, 600K interbank/mo). Daily USD flows: $50M+ A la Mano + Nequi peaks $100M+. Single-vendor risk in billion-scale retail payments? Details: https://www.bloomberglinea.com/latinoamerica/colombia/caidas...
"Hundreds of billions of lines of COBOL run in production every day, powering critical systems in finance, airlines, and government."
That number sounds enormous. If the same code runs on 10,000 ATMs, are they counting that 10,000 times?
No.
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.
Surprised IBM and Oracle have not started on their own frontier models. Or maybe they have?
Granite is not very good
Oracle is trying (and mostly failing) at frontier model training
At the end of the title, you see this bit: (zerohedge.com) ?
Click it.
This makes no sense. If IBM supposedly gets a significant amount of revenue from COBOL (a dubious proposition) then wouldn't this actually help them as COBOL programmers are getting rarer and rarer?
Plus it's not like there aren't cobol environments for more commodity hardware. Hell GCC just got a new cobol frontend last year!
IBM makes a lot of money selling mainframes to companies that have COBOL codebases dating back to the 70s or earlier. The main reason said companies still buy mainframes to run said COBOL programs is because it’s too risky to try to port them to more standardized, cheaper platforms. THEORETICALLY, a COBOL-proficient Claude could make it feasible to port these old COBOL codebases to something more modern that can run on bog-standard x86 servers, and it’s unlikely customers would buy them from IBM.
IF, and it’s a big if, Claude make it possible to migrate off of COBOL, this would be a massive blow to IBM.
What's so difficult about COBOL anyway? How come in these conversations there's never any examples?
Nothing is so difficult about COBOL. It’s just old-fashioned and everything surrounding it is legacy. Most people seem to think it has a negative value when placed on a resume. Maybe that’s true, I don’t know.
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.
Finally!!
I’m porting my whole codebase to cobol!
I write SAAS suites for archeological sites.
Code is less and less the scares resource.... Good documentation is.
Blog post influencing this: https://claude.com/blog/how-ai-helps-break-cost-barrier-cobo... (https://news.ycombinator.com/item?id=47127565)
In the last month:
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%
https://news.ycombinator.com/item?id=46802376
I never in a million years thought I would see zero hedge on the front page of HN.
Times are a changin'
I have a close relative at one of the biggest COBOL shops in the US, and something tells me we're about to find out how we take the stability of our payments infrastructure for granted.
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.
> how we take the stability of our payments infrastructure for granted.
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.
"After all, if Dario Amodei had bought puts on IBM, and the dozens of companies that have plunged more than double digits in recent weeks, he would have made billions, certainly enough to fund his company for months if not years. "
Anthropic put out another blog post about modernizing/migrating away from COBOL several months ago IIRC, it is surprising that this was not priced in already
Feels like a rip from Matt Levine who has been saying the same thing for a while now.
It's not so original an idea that we need to be worrying about who came up with it, I think.
Next up:Epic and MUMPS
COBOL is the perfect language for LLMs because it looks just like the English text they were trained on to begin with.
It's quite the contrary, the less interpretative the language, the better. And no, LLMs were not trained on English to begin with. And they don't perform best in English.
Please expand more on the idea that LLM's are not trained on English to begin with. Not sure what you mean by this as clearly many LLM's are trained on data that contains a lot of English. For instance GPT-1 seems to have been trained on a purely English corpus.
Interesting, where do you think LLMs perform the best?
According to some studies, Polish is top performing, while English wasn't near the top.
SVGs that represent birds on foot powered conveyance devices.
That’s not how it works. Being trained a ton of human text doesn’t mean you can complete the next token for a program that needs to be logically coherent.
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.
Context window required grows though.
Jesus Christ the comments on that Zero Hedge blog
The site is junk and the comments are racist.
zerohedge is absolute trash, do not look to it for information.
[dead]