The loudest use of AI is building new things. The most valuable is understanding the old ones.
Before the year 2000, I was part of an army nobody talks about anymore. Our job was to read old code. Not write it. Read it. Millions of lines of it, a lot of it in languages that were already considered legacy, running on systems that had been in production for decades. We went through it by hand, function by function, looking for every place a two-digit year could break something when the calendar rolled from 99 to 00.
Nothing broke on January 1, 2000. That’s the part people remember, and they remember it as proof the whole thing was hype. They’re wrong. Nothing broke because of the army. The work was invisible because it worked, which is the first thing worth knowing about understanding old systems. When you do it well, it looks like nothing happened.
I’ve been thinking about that year a lot lately, because the single most valuable thing AI can do for a company with real history behind it is the exact job we did by hand back then. And it’s getting almost none of the attention.
The loudest voices are pointed at the blank page
Read the AI conversation today and you’d think the whole game is generation. Vibe-code a prototype over the weekend. Point an agent at an empty repository and watch a feature appear. Spin up five versions of an app before lunch. It’s genuinely impressive, and it makes for a great demo.
It also assumes a world most of the economy doesn’t live in.
Most companies aren’t a clean repository. They’re decades of accumulated software, written by people who left years ago, documented in comments that stopped being true around version four, layered with workarounds for problems nobody remembers having. A lot of the people writing confidently about AI and software have never worked inside a stack like that. They came up in startups and greenfield projects. They’ve never inherited a system with components that went into production before they started school.
That’s not a knock on them. It’s a blind spot. And it’s the reason the most valuable use of this technology is getting the least airtime.
Generation gets the demo. Comprehension does the work.
Here’s the asymmetry. Writing new code from a clean prompt is the flashy capability. Understanding code that already exists, and working out what a change will touch before you make it, is the boring one. The boring one is worth far more, because the boring one is where the business already runs.
The installed base dwarfs the blank page. For every greenfield app being vibe-coded this quarter, there are countless older systems quietly processing orders, claims, payments, and records, carrying the actual weight of the business. The payoff isn’t in what gets built next weekend. It’s sitting in what’s already running and barely understood.
The job I did in 1999 took an army and the better part of two years. Read the system. Work out what it actually does. Trace how one change ripples through everything wired to it. That same job is now something one person can do with an AI agent in an afternoon. Same work. The cost of it fell through the floor while everyone was watching the generation demo.
If you run technology at a company with history behind it, that should stop you for a second. The thing that used to need a budget line and a team is now something a curious product manager can do before their second coffee. We don’t yet act like that’s true.
It isn’t only the code
The same pattern runs through process, not just software.
Companies that have been around a while accumulate manual workflows that exist because someone set them up a long time ago and nobody ever asked whether they still made sense. A person copies a value off one screen and pastes it into an email. A team re-keys data between two systems that were supposed to be integrated three years ago. These processes are undocumented in exactly the way the old code is undocumented. They live in people’s heads and their muscle memory.
Understanding them is the same kind of work. Before you can automate or modernize a manual process, you have to know what it really does, including the exceptions and the quiet reasons it’s shaped the way it is. AI is good at that investigation too, if you aim it there instead of at a fresh idea.
”Too complicated to change” usually means “nobody has read it lately”
Anyone who’s spent time in an older system has heard some version of this: that part is too complicated to touch. Sometimes it’s true. More often, “too complicated” means the logic is undocumented and the last person who held it in their head is gone. The complexity is real to the team because nobody could afford the days it would take to read it carefully.
That excuse is getting harder to make. When understanding a tangled subsystem costs an afternoon instead of a sprint, “too complicated to change” turns back into what it usually was. Too expensive to understand. Until now.
This is also where the rewrite trap begins. A lot of big rewrite pitches rest on the claim that the current system is too complex to extend. Take that claim seriously and investigate it, and a surprising share of the time the complexity is smaller than advertised. You don’t have to rewrite what you can finally read.
Where to point it first
If you lead technology at a company with a long history, or you’re an operator sizing one up from the outside, the move is easy to say and uncomfortable to adopt. Spend your early AI effort on comprehension, not generation.
Point it at the systems nobody fully understands anymore. Map what’s actually in there. Trace what a proposed change will reach before you commit to it. Write down the manual processes that run on tribal knowledge. The output isn’t a prototype you can show off. It’s something better. It’s the ability to change a thirty-year-old system on purpose, with your eyes open, instead of crossing your fingers.
The army I was part of did this work because the alternative was systems failing on a date everyone could see coming. We didn’t have a tool that could read the code for us. You do. The question isn’t whether AI can understand your oldest, least-documented, most important systems. It can. The question is whether you’ll point it there while everyone around you is still watching the blank page fill itself in.
Over the next few pieces I’ll get specific about what this looks like on the ground, for the product managers who have to investigate before they can prototype, and for the operators and boards trying to judge whether their teams actually do. The modernization calls that look impossible right up until someone reads the system are part of the same story.