Monday Morning Moan - messing with our safest IT systems might be the worst thing the AI vandals have come up with...so far!

Anthropic's had a busy week, of course, but there's been more going on than just spats with the US Department of War. To my count, the firm has disrupted Wall St tech stock valuations at least twice already this year (Claude Cowork plugins shaking up legal tech stocks, then Claude Code Security doing the same for cybersecurity firm market caps), spawning the so-called SaaSpocalypse. 

So, one more time for luck shouldn't really come as a surprise, I suppose. The victime this time - the huge legacy COBOL market, as in all the infamously (and allegedly) ‘spaghetti code’ written in the 1960s but which still persists, for no good reason, it seems, in all those banks, insurance company back offices, transactional stacks, airline booking system and more than a few central government systems.

With breezy confidence, this time Dario Amodei’s airstrike is on what the company’s official announcement blog calls all that code sitting out there being un-modernized. Which should be grievous, it seems, to every right-thinking person as all the ‘hundreds of billions of lines of COBOL run in production every day’ can’t be brought up to standard as the language is now only ‘taught at only a handful of universities,’ and finding engineers who can read it gets harder every quarter.

What’s obviously better is to take away all the money flagrantly wasted on ‘armies of consultants spending years mapping workflow’ and instead leave it to Claude Code, which can ‘automate the exploration and analysis phases’ that, the vendor believes, consumes most of the effort in COBOL modernization.

So, by harnessing this latest Claude advance you will be able to modernize your COBOL codebase in ‘quarters’ instead of years… and so decide which components are safe to move, and which need careful handling.

To which the red-braces-clad diviners of the future from entrails on Wall St immediately said, ‘IBM’s toast’—wiping 13% off its stock price in one day, a mere $31 billion.

To which I have to say out loud - W. T. A. F!?!?!

And to which i will add, "You say disruptive visionary, I say hubristic viciousness". 

Er...

Now, I have no doubt at all that Claude Code is anything less than amazing and will for sure deliver on promises like it will work on "COBOL systems of any size" (!) and really will give your team "the comprehensive understanding they need to plan and execute migrations confidently".

But… just for a second, guys, consider this, as you yourself say, there’s a lot of COBOL out there. Sure, a lot of it was messy.

But the reason we still have it isn’t laziness or lack of interest in modernity. For the same reason a lot of banks still use PL/1 alongside their COBOL decks, a lot of nuclear power stations and research scientists still use FORTRAN, and maybe a bomb brain or too in a Minuteman in a Montana rocket bunker still use Ada, for Gawd’s sake, these billions of lines of code instantiate fiendishly complex, important things we don’t want to stop working. Like, now, tomorrow, or ever!

Given how fragile the world is right now, do you really want your ATMs to stop working? A plane or two to fall out the sky?

The arrogance of telling us we’ve been sloppy and not done our work here is astonishing. Banks have been peering into this for decades - I was talking to them about this in the 1990s and we still are! - but they know that blundering in and trying to live without them until a shiny new thing was slotted in would be like trying to perform a simultaneous heart-lung transplant but still go to the office.

Dare we remind ourselves of the engineer’s dictum, ‘If it ain’t broke, don’t fix it?’

Is this ‘fixing’ a non- or even already-solved problem?

Without a doubt—without a doubt—there is unknown inelegant ghastliness in some big COBOL engines.

But here's the thing - it works. 

That’s all that matters. In 1989, I was told a priceless anecdote that one of the UK’s biggest insurers had a COBOL system that did all it wanted in the pre-1971 Imperial British currency of pounds, shillings, and pence, so all it had done to ‘modernize’ in 18 years was to write a three-line program at the top that translated the results into decimal currency.

You either see that as very smart and a true engineer’s practical solution, or you throw your hands up in jejune horror because it isn’t now in Python or Golang. Old does not mean broken. Unaltered does not mean irrelevant. Mature code does not, in itself, equal computer science wickedness.

Talking of which, the Anthropic post says we can’t find these guys anymore, with these careless and silly older coders hopefully all either pushing up daisies or not bothering us cool young folks any longer. Well, sorry: there are quite a few silver-haired types earning $100,000 to $160,000 a year off wrangling the old COMMON Business Language stuff.

Capitalism ueber alles

Which brings us to the real point. We’ve hobbled the careers of quite a few classes of engineers with AI, so why not take down this highly-paid, highly-skilled cohort too?

Dear reader, I implore you - whatever else it is, and it mostly isn’t anything, AI is Capitalism on Crack. It’s the perfect gift for the one percent to strip out as much earning potential in the last holdout against the computer, the skilled class of priests who were grudgingly kept on to make it work.

AI says we can get rid of you, too… even these strange old people who keep driving up to the office in suspiciously nice cars, whistle away doing something unknowable in the corner for two weeks, then disappear again.

This is why they want this stuff. But they truly don’t know what they have wished for and shall surely get if we really do let this stuff loose on our core ICT heritage. We’ve done the economics, now let’s do the risk management.

Why it’s bad to use AI like this

John Bates is CEO of Enterprise Content Management player Doxis. He warns,

We tend to assume that LLMs will keep improving indefinitely, becoming ever more reliable. But many are now being trained on data generated by earlier generations of bots, which can degrade them very rapidly. In a similar way, but on an amplified scale, agents interacting with other agents, whether coding or non-coding, can produce unintended side effects. In development, do we really want multiple coding agents assigned to different but overlapping tasks, and even checking each other's code?

There’s a clear risk that an enterprise’s knowledge ecosystem could degrade due to the influence of random, competing, and black box agents, some of which may be operating largely unnoticed within core systems. One agent might ‘clean up' or overwrite artefacts produced by another, even when those outputs are valid and valuable, leading to subtle erosion of institutional knowledge over time.

That's before we consider, who is it who says AI code is even ‘better’? By what standards? Werner Heijstek, Senior Director at Software Improvement Group, notes,

AI-generated code often contains more security vulnerabilities and is being merged into systems with very little formal review [Veracode has reported 45% of AI-generated code it analyzed contained security flaws].

Yes, y​​ou can absolutely use AI to help modernize COBOL and core banking systems, but you shouldn’t trust an AI on its own with production code!

If anything, de-fenestrating all your costly old-timers here might actually end up creating more work: developers will soon have to start designing architectures, tests, and guardrails to ensure that AI-generated code can be effectively managed—especially important in heavily regulated environments, where failures in core banking systems could potentially lead to widespread issues.

And who says AI can do it anyway? Last word to Simon James, Managing Director of Data and AI Strategy at Publicis Sapient:

Any LLM can convert COBOL syntax, but that's not the hard part: the real challenge is understanding how the code actually works, so you can modernise the functionality itself rather than just translate it line by line.

Yes, AI has unlocked a genuine opportunity for banks to reduce technical debt on legacy core banking systems—but it will still require human sign-off at every stage. DevSecOps, regulatory compliance, the high-stakes decisions: those remain human-led.

One last thing, have we all forgotten Y2K and the Millennium Bug? Is it just possible a lot of the really ‘bad’ stuff was cleaned up, ooh, a mere 25 years ago? And what about all the effort that went into Object COBOL, all a waste of time, huh?

Sorry, but looking at last week's panic it just seems to me to be people necking a nakedly opportunistic, greedy, irresponsible gulp of AI snake oil designed to convince fast-headed bean counters they don’t need smart people anymore.

My AI fear is these people are like arrogant children who don’t know any better, but will, like John Hammond’s team in Jurassic Park, just do it anyway. And now that image is out there, consider this - the Samuel L Jackson character is a COBOL man to his last cigarette. He's experienced, cautious, wise, doesn’t want to do anything stupid, gets the system back up. 

But he still gets eaten by an automated nightmare. 

There's a lesson there somewhere, surely?