We're Speedrunning the Next COBOL Crisis

AI made me a faster engineer and a worse one. Meanwhile the industry stopped hiring juniors and started shipping code nobody understands. I modernise legacy…
On this page
How a COBOL crisis is madeStep one: generate code nobody readsStep two: stop hiring juniorsStep three: let the seniors rust"Just let AI translate the mainframe"What I actually doThe billCommentsI modernise legacy systems for a living. Big companies, decades-old mainframes, millions of lines of code that nobody alive fully understands, and clients who'd like the whole thing replaced without anyone noticing.
It's a good business. And thanks to AI, I'm fairly sure it's going to be an even better one in about ten years.
How a COBOL crisis is made
The recipe is simple, and the industry followed it perfectly the first time.
You write a lot of code quickly, under pressure, measured on delivery. You don't write down why it does what it does, because the people who wrote it know. Then those people retire, and the knowledge goes with them to the farm they always dreamed of, as every software engineer does.
Thirty years later the documentation describes a system that was replaced in 2003, the running system is the only specification, bugs included, and somewhere in there is a special case, hard-coded for one client in the nineties, that nobody knows about until that client calls. Companies now pay millions to dig themselves out, and a fair number of those digs end up as big-bang rewrites that run out of budget before they run out of surprises.
That took decades. We're about to do it in a couple of years.
Step one: generate code nobody reads
With the old systems, the knowledge left when people retired. With generated code, it often never arrives in anyone's head in the first place.
Here's a perfectly normal workflow in 2026. Someone asks an AI for a feature. The AI writes the code, then writes the tests, then the tests pass, because the same thing that wrote the bug also wrote the test that checks the bug does what the bug does. The PR gets approved by someone skimming a 2,000-line diff between two meetings. Everybody's velocity chart goes up and to the right.
Six months later, ask who understands that module. You'll get a link to a chat history. That's your documentation now. Good luck reading it in 2040.
Vibe coders call this shipping. I call it writing legacy code with extra steps.
Step two: stop hiring juniors
This is the part that genuinely worries me.
Companies have discovered that an AI does roughly what they used to pay a junior for, so they stopped hiring juniors. Stanford researchers found employment of 22 to 25 year olds in the most AI-exposed jobs dropping noticeably since generative AI arrived, with software developers among the hardest hit. It looks great on this year's budget.
Small problem: every senior engineer you'll ever hire was a junior once. Somebody let us break things, fix them, get yelled at about a deadlock, and slowly grow the instincts we're paid for now. Skip that step for a few years and the pipeline doesn't slow down. It empties.
So here's the plan the industry has accidentally signed up for: produce more code than ever, understood by fewer people than ever, and stop training the people who'll have to clean it up. Way fewer juniors hired today means way fewer seniors to handle the mess tomorrow.
I'd call that a strategy if anyone had chosen it on purpose.
Step three: let the seniors rust
And the seniors? We're fine, right? We have the experience.
I write a lot less code than I used to, and I can feel it. On migration projects where I worked almost entirely with AI, my reflexes changed. When something didn't add up, my first instinct used to be to open the code and read. Now it's to ask. When I do sit down and read old code line by line, I'm slower than I used to be. It feels like a language I was once fluent in and now mostly use to order coffee.
There is data behind the feeling. In January, Anthropic itself published a randomised study: developers learning a new library with AI help scored 50% on the follow-up quiz, against 67% for those without, and the biggest gap was in debugging. Developers who used the AI to understand things kept their skills. The ones who handed over everything did worst.
When the company selling the tool publishes that, I'd listen.
The industry's comfortable story is that AI takes the typing and seniors "move up" to review and architecture. Lovely. But judgement is compressed experience. I distrust a "simple" date calculation because month-end batch runs have burned me. I get nervous around a transaction boundary because I've debugged one at night. Stop doing the work and the judgement stays for a while, running on old data, approving diffs it would once have caught.
You can't review what you can no longer write.
"Just let AI translate the mainframe"
My favourite pitch of the year: AI will finally modernise legacy systems automatically. Point it at the COBOL, get Java back, fire the consultants.
When we tried AI on a legacy system in a pilot, it was genuinely useful as an analyst. It read old programs, followed the data, and pulled out business logic faster than we could. The code it generated was unusable, and not in a way more polishing would fix.
The split makes sense. Explaining what code does is reading. Building a replacement that behaves the same on decades of real data, including the rules nobody wrote down, requires knowing what the code is for. AI will explain a hard-coded exception with total confidence and invent a business reason for it. Sometimes the invention is right. In a system that moves real money for real clients, "sometimes" is how you end up on the evening news.
Use it to understand the old system. Keep people in charge of building the new one. Ignore anyone selling you the opposite, especially if their slide deck has a robot on it.
What I actually do
I'm not anti-AI. I use it every day, and boilerplate, scaffolding, test data and the fortieth form are exactly what it's for. As a lead, though, I draw a few lines.
Business rules belong to humans. Anything AI extracts from legacy code is a hypothesis until a person who knows the business confirms it.
Parity before trust. Nothing replaces the old system until old and new produce the same results on real data. Green tests are where that check starts.
Nobody merges what they can't explain. Including me.
And for my own rust: I read the code and the logs before I ask the AI, and I check every AI explanation of legacy code against the code before I believe it. I'm slower than the robot. That's the point.
The bill
Speed is a loan. The interest gets paid in skills that fade, teams that no longer understand their own systems, and codebases that grow faster than anyone's mental model of them. The loan always comes due at the worst moment: an incident at night, an audit, or the next migration.
I'll probably be the one invoicing that migration in 2035. Business-wise, I should thank you all. Engineering-wise, please hire a junior.
Software Archaeology: Modernising Code Older Than Me
When you modernise a system older than you are, everyone's first instinct is to open the code. Mine isn't. How I dig a business out of its data and its people instead, and why the code is the last place I look.
12 May · 4 min How This Blog Works (or: More Infrastructure Than Posts)
Jekyll, WordPress, a static site, Strapi, and now Obsidian plus Nuxt. Years of rebuilding a blog that had almost no posts, and how the current setup works.


Comments use GitHub Discussions through Giscus. Nothing loads until you ask for it.