jarkko
Tim BrayIBM crashes because we’re gonna YOLO a replacement for banking and credit-card back-ends, replacing billions of lines of COBOL with vibe code. Uh…
https://www.techbuzz.ai/articles/ibm-crashes-11-as-anthropic-threatens-cobol-empire
Norm Tovey-Walsh@timbray "I hate this timeline."
IBBoard@timbray "If Anthropic's Claude or other large language models can understand, maintain, modernize, or even replace COBOL systems…"
That "If" is doing a LOT of heavy lifting!
Todd Knarr@ibboard @timbray If it could do that, why isn't Anthropic keeping Claude to themselves and making a fortune doing all that for the Fortune 500 companies, global banks, governments and militaries, all those entities that rely on systems dating back to the 60s and 70s that can't be maintained because they're too complex and can't be replaced or rewritten likewise? Think the FAA's many failed modernization efforts.
Yes, I ask this same question of every "make money fast" scammer.
Ivor Hewitt@timbray JFC... The "efficient-market hypothesis" proving it's worth. 🤦♂️
Nathan Lowell (he/him) 📎What could possibly go wrong.
I worked on those COBOL systems for much of my programming career. Made good living maintaining 60s and 70s spaghetti code (literally. the comments were all in Italian. I'm not kidding).
Having AI guessing what the code might look like should give chills to everybody who uses money.
Wouter@nukleos
The Orange Theme@nlowell @timbray First of all, thank you for the work that you did. I'm sure it benefitted countless people. :)
At this point, I'm just trying to be resilient for when the system collapses. If the people running society are hellbent on ruining it, all we can do is try our best, and coordinate with each other for when it happens.
Danthis jokers me every time it comes up. every single bank and many large corps that do similar settlement processes have looked at this every five to ten years. for fifty years.
the architecture is specialized to perform huge numbers of tiny processes. every single time something new is stood up they find the same thing: COTS hardware and "modern" languages significantly underperform what's already in place.
i wish this lesson stayed learned.
BenderIsGreat34
Chris Mackay 🇨🇦
Worik> COBOL systems are so old that any viable alternative becomes immediately attractive.
A tech journalist said that. We're doomed, if we cannot build IT infrastructure that can last for decades.
Good news is we can.
Bad news is there is more profit in new crap than in maintaining the existing infrastructure
Software, generally, socks mostly for that reason. And they are laying off all the computer programmers...
zbrown
mike805@zbrown @worik @timbray Last time they laid off all the COBOL programmers, Y2K happened and they had to go hat in hand to the retired people. A lot of older programmers got a serious upgrade to their retirement.
The fact something lasted decades is good, not bad. If software is going to be infrastructure then it needs to be built like infrastructure.
What are the AI vibe coders going to do when they have to maintain a code base and the AI model that "wrote" it is discontinued? 1/2
@zbrown @worik @timbray Everyone is worried about programmers losing their jobs to AI. From what I am seeing (and I support both kinds of code) there is going to be lots of work for humans fixing what the AIs broke.
One of the basic problems with this technological era is that production is automated and efficient. Repair is still a medieval craft. Look at current generation cars which are nearly unfixable if they get in an accident. AI is making programming like making cars. 2/2
AJ Sadauskas@mike805 @zbrown @worik @timbray Really great points.
And there's a couple of really important points I'd make to the AI boosters and investors who mightn't have a great deal of knowledge about enterprise IT. (By enterprise, I'm talking top-100 corporations, government departments, major research universities, etc.)
First point.
Where you'll often tend to find COBOL is in core business systems. In many cases, these are green screen applications that were custom written for a particular organisation, and were often originally written for something like a VAX system or an IBM 360 mainframe.
They typically store and manage the most critical, business can't operate without it data. They encode the most critical business logic that underlies the company's systems.
In a bank, that might be the system that holds the bank's account and loan balances, and calculate interest payments.
In an electrical utility, that might be the database of all the properties that are connected to the grid, what part of the grid, what equipment is at the substation, etc.
Many of the other systems in the enterprise are either front ends, or integrate with these core systems.
So the clunky web interface the helpdesk staff use or the shiny new mobile app are basically a front end for this system. Your bank's new loan application wizard or your power company's new connections system integrates with it through an API.
Someone just going in there who doesn't know what they're doing and vibe coding on a live, in-production core business system is just a catastrophically stupid idea.
Second point.
You're right. The costs of software are not limited just development and deployment.
I'd break the ongoing costs into five broad buckets.
The first is maintenance. That's everything to just maintain the status quo, such as your regular bug fixes and security patches.
The second is upgrades. The organisation begins offering a whole new category of product or changes its business model. How does its systems evolve to meet those business needs?
The third is catastrophic failures. When shit goes wrong in an unexpected way, how easy and quick is it to troubleshoot and fix?
The fourth is the cost of daily use. This is a biggie that gets overlooked a lot. If your software is buggy and unreliable, and requires a lot of manual workarounds, that puts costs on everyone else in the business.
And the fifth is decommissioning. This one gets overlooked until the time comes to replace the system.
The savings business leaders are often chasing with AI are in development and deployment.
But that's often not where most of the total lifetime costs of the software are.
And there's a couple of really important points I'd make to the AI boosters and investors who mightn't have a great deal of knowledge about enterprise IT. (By enterprise, I'm talking top-100 corporations, government departments, major research universities, etc.)
First point.
Where you'll often tend to find COBOL is in core business systems. In many cases, these are green screen applications that were custom written for a particular organisation, and were often originally written for something like a VAX system or an IBM 360 mainframe.
They typically store and manage the most critical, business can't operate without it data. They encode the most critical business logic that underlies the company's systems.
In a bank, that might be the system that holds the bank's account and loan balances, and calculate interest payments.
In an electrical utility, that might be the database of all the properties that are connected to the grid, what part of the grid, what equipment is at the substation, etc.
Many of the other systems in the enterprise are either front ends, or integrate with these core systems.
So the clunky web interface the helpdesk staff use or the shiny new mobile app are basically a front end for this system. Your bank's new loan application wizard or your power company's new connections system integrates with it through an API.
Someone just going in there who doesn't know what they're doing and vibe coding on a live, in-production core business system is just a catastrophically stupid idea.
Second point.
You're right. The costs of software are not limited just development and deployment.
I'd break the ongoing costs into five broad buckets.
The first is maintenance. That's everything to just maintain the status quo, such as your regular bug fixes and security patches.
The second is upgrades. The organisation begins offering a whole new category of product or changes its business model. How does its systems evolve to meet those business needs?
The third is catastrophic failures. When shit goes wrong in an unexpected way, how easy and quick is it to troubleshoot and fix?
The fourth is the cost of daily use. This is a biggie that gets overlooked a lot. If your software is buggy and unreliable, and requires a lot of manual workarounds, that puts costs on everyone else in the business.
And the fifth is decommissioning. This one gets overlooked until the time comes to replace the system.
The savings business leaders are often chasing with AI are in development and deployment.
But that's often not where most of the total lifetime costs of the software are.
Richard Penner@aj @mike805 @zbrown @worik @timbray
#SoftwareCosts don't end at deployment.
2001: An engineer adopts a French #OpenSource bulk mailer, running on mostly unsecured SMTP. Over the years it's extended ad hoc — eventually managing security group permissions. The company grows; the #software (now at 100× planned #capacity) falls over daily.
2009: After the original engineer leaves, a contractor-turned-hire inherits it. Memory leaks fixed, algorithms rewritten that had pre-cached the universe for "efficiency." Redundancy established and tested. Deployment documented. The upstream package has been rearchitected twice since 2001, and after being pulled off the project twice to restart, the replacement engineer maps all integrations to the new architecture with a proper API — replacing direct database queries. The max supported mailing groups turns out to be tied to filesystem limits: 32k+ groups (now at 300× original capacity thanks to fixing the memory leaks and hourly restarts) each with a directory, capped by hardlink counts on the inode. A campaign encourages responsible use and better security. Archiving aligns with retention policy. And nearly daily, a manager insists someone didn't get their email, so the engineer traces it by SMTP ID.
Then the company moves to Gmail, which won't tolerate internal mailers forging external domains. Data and management migrate to Google Groups with a new front-end preserving the old permission controls. Legacy API users are tracked and urged to migrate before "the end." And the heart of corporate communication for 15+ years is decommissioned.
Every stage has real costs:
• #Maintenance
• #Upgrade
• #CatastrophicFailure
• #DailyOperations
• #Decommissioning
Svavar the Neurospicy
Flaming Cheeto
a kilo of saucepans (rakslice)
🪬🍄🌈🎮💻🚲🥓🎃💀🏴🛻♓🧿It had to be done someday
Thijs
Michael Ormsby@timbray I wonder if there are deeper issues not mentioned in the article? I have heard anecdotally that one of the problems of the COBOL culture is that the practitioners are literally dying off without fresh talent replacing them. Which leaves billions of lines of rock solid but terribly obscure and hard-to-maintain COBOL code. Not to mention the proprietary nature of the underlying hardware architecture.
René SeindalThe main probe with Cobol is that it takes at least three years just to get into Environment Division.
mark@timbray the a ary bit is that Claude "understands" available code, in whatever language is popularly used amd available. So its not ever going to know cool and collect any collective solutions. This will cause the owners of the code to have Claude convert working old stuff that costs money to maintain into new vibe slop that the stupid AI can "debug" and "fix"
Everything will suddenly become average to bad python
Bill Seitz
Dan Connolly@timbray how many COBOL codebases have good test suites? I suspect none.
How well do LLMs do without tests / types / guardrails?
Best practice AFAIK is to run in parallel with prod. I guess they could try that, but it would take like a monthly billing cycle or a quarter to test one change.
Arthur van der Harg
Soldier of FORTRAN 
@timbray finally ending the shackles of evil big COBOL
cratermoon
Helge
Eric LawtonBig financial institutions have spent a lot of money on really intelligent people trying to replace these old systems, over decades.
We've built many automated systems to translate COBOL to more modern languages.
Billions of dollars are at stake if things go wrong.
Have bank executives been replaced by clowns, with an “anything for laughs” mandate?
John Timaeus@EricLawton @timbray @bonaventuresoft
I used to know a guy whose primary job was maintaining/carefully refactoring COBOL code for a large retail corp. He had two apprentices whose college was being paid off by the corp.
They worked for a good 3-4 months on breaking up one chunk into manageable functions that weren't dependent on hardcoded values. It was initially >100k LoC. If they buggered it up, 10k & 10q reports couldn't be submitted to the SEC.
I'm wondering how large a context window this LLM has. Can it even hold 100 thousand lines of code?
I know it can't understand it. They spent a week on one little bit with seemingly arbitrary math happening for unexplained reasons. They finally figured out that it was a cute trend reporting trick that wasn't actually referenced by any of the surrounding code.
jessica@timbray webdev vibecoders and llm industry have one thing in common: they're both at the very end of a massively complex and fragile network of interdependant components/processes, and have seemingly no understanding of its complexity. that's how you get "we're just going to build a million datacenters in a year and then the agi will just rewrite everything in rust, simple🚀 "
@timbray this is also an affliciton that plagues crypto/web3 people. the plumbing of interbank transfers is also massively complex. if you have rock solid code that has been in production for decades, why would you want to fuck with it. "solana is so much faster and cheaper🚀 🚀 🚀 ." yes, banks would be a lot faster and cheaper if they didn't have to care who/where your money was going to or what they're using it for. finance people generally do not view this as a "feature"
Giflian@timbray lol, so AI companies are going to impale themselves on the sword of a real one? cool.
Mx. Eddie R@timbray
What's ironic is, as I understand it, IBM is still barred from announcing future products, because they used to kill competitors by announcing competing products. Like, who's gonna but $widget from Daryl, Inc when they can wait a year and buy it from IBM instead? Daryl goes out of business and IBM never has to actually develop the product.
What's ironic is, as I understand it, IBM is still barred from announcing future products, because they used to kill competitors by announcing competing products. Like, who's gonna but $widget from Daryl, Inc when they can wait a year and buy it from IBM instead? Daryl goes out of business and IBM never has to actually develop the product.
Franklin Delano Stallone@timbray I asked it to write me a function in Cobol to get the contents of a URL. It just shells out to curl to do the real work.
I don't know Cobol and it might work but I'm guessing that's not the correct solution. I can see if you search google there is at least one message board comment where someone admits to not knowing much but suggest calling wget or curl. I think the old folks writing Cobol are going to be fine.
tuban_muzuru
0px auto@fds @timbray I had COBOL as part of my curriculum. Granted, getting information from an external webbased end-point wast not yet 'the new thing', it was getting closer by the day.
The way I would solve this to do the fetching in parallell. Have a cron+curl job fetch the data at regular intervals, do any pre-processing on the data to make it more palatable to COBOL, throw in a freshness indicator, and then suck into the actual application the way you would do with other input files.
Jay Deiman@timbray This is just more "AI is going to solve all of the world's problems" BS. Most of the marketing around AI is somewhere between ok and complete nonsense. I always think of this classic Tom Waits song whenever some AI hawker pulls some BS out of their ass.
Tom Waits- Step Right Up
@timbray Hah. They (like DOGE when it ran rampant) overlook that COBOL is a DSL. You may map the AST of a COBOL program to a different language, but you cannot machine translate the way COBOL programs are written and maintained. Not for the use cases that COBOL is used in, anyway. A programmer would have to specify the requirements for a change so elaborately, in such detail, so precisely, that they would be quicker using COBOL for the spec. Nothing vibey about that.
illogical
Ricardo Klein@timbray and our bank accounts crash later when we find out that the numbers are all hallucinating vibecode generated
Cosmo
Mark Struberg@timbray The fun part is that IBM consultancy branch is currently pretty aggressive in selling 'migration via AI' to customers :D