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
Brooke Vibber 
@timbray it's cool how facts don't matter in the stock market. it's just vibe finance
Stewart Russell
Max 🏳️⚧️ 🍉 🪬 🔯 🏳️🌈 🖖🏻
IBBoard@brooke @timbray I was talking to a colleague about that recently. He was talking about his stock trading models and the issues he was having with training them.
I tried to tell him that stock trading is just vibe-coding for stocks. He then tried to explain how it wasn't, starting with "Okay, so think of a brand that you engage with every day…" and I just looked blankly at him because… why would I pay attention to the brands?!
The rest of the discussion was then "So, I've got an Apple phone, so I think other people will want one, so I think they'll do well, so I invest in them". Which is just Vibes. And nothing about when to sell to actually make a profit 😐
Pwassonchat the enby catboy
Azuaron@ibboard @brooke @timbray How the stock market USED TO work, a little bit better, was that you DIDN'T sell, generally. Companies that did well had dividends, which they paid out to their stock holders.
Then Ronald Fucking Reagan was like, "You know what should be legal? Stock buybacks."
And now the stock market's all "infinite growth, juice our stock numbers with stock buybacks while firing all your workers and bankrupting the company!!!!!!!"
Aristotelis Tzafalias
Franklin Delano Stallone@brooke Imo, we still have a hard time admitting that having money does not equal being smart.
Norm Tovey-Walsh@timbray "I hate this timeline."
@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!
CLT/Linux 
@ibboard @timbray Oh so that's what people meant when they said Artificial Intelligence is just a bunch of IF statements.
if it's able to """"""understand""""" the code
if it's able to maintain it
if it's able to modernize it
if it's able to replace it
if a bunch of other stuff it's not able to do
...
and most important of all
if my grandma had wheels, she would've been a bike.
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
Sandor Spruit 🇪🇺🇳🇱🇺🇦🇨🇦
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.