Every company past a certain age has one. The system nobody wants to touch. It runs something important, it makes money or moves money, the people who built it are long gone, and every change to it is planned like a surgery. The official roadmap says it will be replaced someday. The honest roadmap says it will outlive us all.
I have spent a good part of my career around systems like this, and I want to share something that has genuinely changed in the last year. AI assistants have become the best legacy code tool I have ever used. Not because they fix old code. Because they make old code understandable again, and understanding was always the real bottleneck.
The cost of legacy is the cost of fear
Let me frame the problem in business terms first. Legacy systems are expensive, but the line item is hidden. The expense is not the servers. It is the fear.
Fear makes every estimate triple. Fear makes good engineers refuse to join the team that owns the old system. Fear makes the business stop asking for changes, which means the system slowly stops matching what the company needs. When people say legacy maintenance is expensive, what they mean is, we lost the understanding, and without understanding every change carries risk, and risk has a price.
So any tool that rebuilds understanding attacks the cost directly. That is exactly what AI does well.
Three things that actually work
I will skip the hype and tell you the three uses that have paid off for me in practice.
First, explaining unfamiliar modules. I point the assistant at a gnarly piece of code, a 900 line class with methods named after people who left in 2016, and ask it to explain what this does, what it depends on, and what looks dangerous. The answer is not always perfect, but it is a fast and surprisingly good first map. What used to be two days of reading and note taking is now two hours of guided exploration. Multiply that across every change to the system, and the savings are not small.
Second, generating characterization tests. This one is the gold. Michael Feathers taught us long ago in Working Effectively with Legacy Code that the way into legacy code is tests that pin down current behavior, not correct behavior, current behavior, so you can change things and know if you broke something. It is the same book behind the sprout method I wrote about, and the safety net it describes is exactly what AI now helps you build fast. Writing those tests by hand is slow and boring, which is why nobody does it. An AI can draft dozens of them from the existing code in minutes. I review them, I throw away the weak ones, and suddenly the untouchable module has a safety net. The fear drops a level. The estimates drop with it.
Third, documenting tribal knowledge. Old systems are full of code that encodes decisions nobody remembers. Why does this job run at 4:17 and not 4:00? Why is this customer type handled in a special branch? The AI cannot tell you the original why, but it can surface every weird special case and put it in front of a human who might remember, or who can at least write down that it exists. We turned a pile of folklore into a real document this way. The day the last person who knew the folklore resigns, that document is worth a fortune.
The part AI does not remove
Now the cold water, because this post would be dishonest without it.
AI lowers the cost of understanding legacy code. It does not lower the cost of changing it carelessly. The refactoring discipline that Martin Fowler has documented for decades in Refactoring is still the law of this land. Small steps. Behavior preserving changes. Run the tests after every move. Commit often so every mistake is cheap to undo.
If anything, the discipline matters more now, because AI gives you confidence quickly, and quick confidence is a trap. The assistant explains the module, the explanation sounds complete, and you feel ready to make the big change. But the explanation is a hypothesis, not a guarantee. The model reads code, it does not read the production incidents from 2019 or the customer contract that depends on the weird branch. Trust the explanation enough to start, never enough to skip the safety net.
My working rule is simple. AI to understand, tests to protect, small steps to change. All three. The teams I have seen get burned are the ones who took the first and skipped the other two, because the first one feels so good.
Why this matters beyond the old system
Here is the bigger picture that gets me excited. For decades, the industry answer to legacy was rewrite it, and rewrites are where budgets and careers go to die. We all know the stories. Two years, millions spent, and the new system covers 60 percent of what the old one did.
AI assisted understanding opens a third path between suffer forever and rewrite everything. Recover the knowledge, build the test net, then improve the system in place, piece by piece, while it keeps earning its keep. It is less heroic than a rewrite. It is also dramatically less risky, and the money stays in the business instead of the consulting invoices.
Back in my company days in Brazil I inherited a billing system with zero docs and one very nervous client, and I would have traded a finger for these tools then. The systems did not get younger since. But for the first time in my career, old code feels less like a curse and more like a fixable problem. That is a quiet revolution, and I think it is a bigger one than most of the louder AI stories this year.
Pax et bonum.