Every AI product demo I sit through starts the same way: an empty prompt box, a request in plain English, and a working app a few minutes later. It’s a genuinely impressive party trick. It’s also, I’d argue, the least interesting thing happening in enterprise AI right now.
The more consequential work is happening somewhere far less glamorous: inside fifteen-year-old code bases nobody wants to touch, written by engineers who left the company a decade ago, running business logic that nobody has fully understood in years. Most AI coverage gets this backward. Legacy code isn’t technical debt. It’s accumulated business intelligence: decades of decisions, encoded as software, with the people who made those decisions long gone.
Greenfield development gets the keynote slots. The old code gets the money, reluctantly, and usually without the understanding needed to spend it well.
The Real Shortage Isn’t Developers, It’s Memory
This isn’t an isolated problem. A 2025 Pegasystems study, conducted by research firm Savanta across more than 500 IT decision-makers worldwide, estimates that the average global enterprise wastes more than $370 million a year through its inability to efficiently modernize legacy systems, with nearly $134 million of that tied to slow, resource-intensive transformation projects alone.
We recently worked with a battery distribution company running more than fifteen legacy applications, the kind of sprawl that accumulates over twenty years of mergers, one-off integrations, and engineers solving today’s problem without much thought for tomorrow’s. Buried in that code were pricing rules, inventory thresholds, and distribution constraints that represented years of institutional decisions, written down nowhere except in logic nobody had fully mapped.
It’s tempting to call this a talent problem: hire more developers, migrate faster. But you can’t hire your way out of the fact that the person who understood why a module worked the way it did left the company in 2014. Most enterprises suffer from a memory shortage, not a talent shortage. And until recently, there was no real way to solve that at scale. You either paid a handful of senior engineers to hold the institutional knowledge in their heads indefinitely, or you lost it the day they left.
What AI Actually Changes
We didn’t point a code-generation tool at the old codebase and tell it to rewrite everything; that’s roughly how you quietly delete business logic you didn’t know existed. Instead, we used AI agents to do the unglamorous groundwork first: trace how the fifteen-plus applications actually connected to each other, surface the decisions embedded in the logic that had never been written down elsewhere, and hold onto that context as something the organization could query, not something that lived only in one engineer’s head. This lines up with what other AI vendors are now documenting publicly: Anthropic’s guidance on modernizing COBOL systems with Claude Code describes the same sequencing, automating the exploration and analysis phases first rather than jumping straight to rewriting.
The agents weren’t graded on how much code they generated. They were graded on how much institutional knowledge they could surface and preserve. Engineers then worked alongside them on the actual migration and test generation, checking the agents’ interpretation of business logic against how the system behaved in production, not trusting it on faith. A useful signal we watched for: did the agent’s explanation of a rule match a pattern we could independently verify in production logs, or was it a plausible-sounding guess? The gap between those two is exactly where legacy modernization projects usually go wrong.
The original estimate for the project was eight and a half months. It closed in four, a 53% reduction. But the more durable outcome wasn’t the timeline. Institutional knowledge that used to evaporate every time an engineer left the company became something the organization could actually retain.
Software engineers have spent decades writing software. The next decade may be spent excavating it, with AI acting less as an author and more as an archaeologist, carefully reconstructing the reasoning buried in code that outlived the people who wrote it.
A Rough Framework for Doing This Without Breaking Things
The projects that go well seem to follow roughly the same sequence, whether the system is a pricing engine or a claims pipeline:
Discover: map how the systems actually connect, not how the architecture diagram from 2016 says they connect.
Understand: have the agent surface the business logic and the assumptions behind it, in plain language a domain expert can sanity-check.
Verify: cross-check that interpretation against real production behavior, not just against the code’s own comments.
Transform: migrate or rebuild only once the first three stages hold up, with humans owning the sign-off.
Skip straight to Transform, and you’re not modernizing. You’re gambling with logic you don’t understand yet.
Why This Matters Beyond Engineering Teams
Institutional memory doesn’t just quietly decay when a senior engineer retires. It becomes an acute liability at the exact moments a business can least afford it: during an acquisition, when a new owner needs to understand what they actually bought; during an ERP migration, when old logic has to be translated into a new system correctly the first time; during a compliance audit or incident response, when someone needs to explain why the system behaved a certain way, under a deadline, to a regulator who won’t accept “the person who built it left in 2014” as an answer.
Treated this way, legacy modernization stops being an engineering line item and starts looking like an organizational resilience question, which means it’s not just CTOs who should care. It’s CIOs weighing what happens when key technical staff turns over, M&A teams trying to price what they’re actually acquiring, and boards thinking about how much of the company’s operational knowledge exists nowhere except in code nobody currently reads.
The Caveat That Matters
None of this works unattended. The riskiest version of this approach is one where an agent’s interpretation of old business logic gets trusted without verification, because legacy systems are exactly the place where a confidently wrong AI assumption costs the most. Full autonomy on your newest microservice is a reasonable bet. Full autonomy on the pricing engine nobody’s touched since 2011 is not. The value is that AI makes it possible to become, once again, the engineers who understand the business, at a system nobody currently understands. It doesn’t replace them.
Where I Think This Goes Next
For twenty years, enterprises have treated legacy software as something to escape: a cost center to fund reluctantly and modernize away as fast as budget allows. I think AI is about to reveal that a lot of that code was actually one of the most valuable knowledge repositories the business ever built. It just needed something capable of reading it. Researchers are already documenting the other side of this loop: a 2026 multivocal literature review on LLM-assisted development finds that today’s pursuit of AI-accelerated speed is itself creating “fast-integration debt,” code shipped quicker than it can be understood. Legacy modernization is just that bill finally coming due, a generation early.
I’d be curious whether other engineering and technology leaders are seeing the same shift: is the return on your AI investment showing up more in what you’re building, or in what you’re finally able to understand and preserve? And for anyone who’s tried running AI agents against a genuinely old, undocumented system, where did the agent’s understanding hold up under verification, and where did it quietly fall apart?
