Someone asked me last week if legacy code will disappear now that AI writes so much of our software. My first answer was a quick "no." Then I looked into it, and the real answer turned out to be more interesting than a simple no.
The story we tell ourselves
The pitch for AI coding tools always sounds the same. Feed the model your old codebase, and it will read the messy parts, explain the parts nobody remembers, and modernize what needs to change. In theory, legacy code stops being scary. It becomes just another input for a model with a big context window.
There is some truth here. In March 2026, Anthropic launched the Claude Partner Network with a $100M commitment, and legacy code modernization was one of the main use cases they pointed to. Cleveroad, a company that works on these migrations, explains that AI-assisted modernization reads existing code and translates it step by step, instead of throwing it away and starting over. A full rewrite is risky. You lose business rules that got buried in the code over the years, rules nobody wrote down anywhere else. AI tools are good at pulling that hidden logic out before anything gets touched.
So on the enterprise side, there is a real market forming around this. IBM i shops, old RPG systems, COBOL wrappers, all of it. Companies like ARCAD, Fresche, and Profound Logic are building tools and services around exactly this problem. If legacy code was disappearing, nobody would be selling shovels for it.
But here is the part I didn't expect
While AI tools get better at explaining old code, they also seem to be making developers less willing to touch it.
GitClear published research that LeadDev covered recently, and the numbers are hard to ignore. Legacy refactoring, meaning changes to code that is more than 12 months old, has dropped 74% since 2023. Developers are not going back to clean up what exists. They are building new instead, because that is what AI tools are good at and fast at. The research also found a rise in "error masking," where the model writes code that never throws an error no matter what input it gets, instead of handling the input properly. That looks fine today. It becomes tech debt the moment someone has to figure out later why the error handling is there at all.
This connects to something Google's DORA report found too: every 25% increase in AI usage adds about 7.2% more instability to a system. More AI does not automatically mean more stability. Sometimes it means the opposite, just with more code shipped around it.
So which is it?
Both things are true at the same time, and I think that is the honest answer.
At the big, expensive, well-funded end of the industry, AI is genuinely helping teams face 25-year-old systems that no human fully understands anymore. That work was basically impossible to staff before. Now a modern developer can be productive on a legacy system they have never seen, because the AI can explain what the code does, not just what it says.
But at the daily, ordinary end, where most of us actually work, AI is quietly creating a new kind of legacy code. Code that was generated fast, that passes the tests, that satisfies the prompt, and that nobody wants to open again in a year. Faros points out that developers increasingly care about net productivity, not just how fast the first draft appears, and that tools requiring constant correction lose favor quickly. That is a sign teams are noticing the same thing I noticed while reading all this: speed at the start does not mean less maintenance later. It can just move the maintenance further down the road.
Legacy code is not going anywhere. If anything, AI is teaching us how legacy code gets born in the first place, and that part was always true, long before any of these tools existed.
Sources
- Code maintainability plummets in the AI coding era – LeadDev
- AI-Assisted Legacy Code Modernization Guide 2026 – Cleveroad
- Here Come The AI-Based Code Modernization Offerings – IT Jungle
- Best AI Coding Agents for 2026: Real-World Developer Reviews – Faros
- 20 Best AI Coding Agents in 2026 – Agentic.ai
Top comments (5)
Swallowed errors are the new unchecked null, except they're generated at scale and pass review because the diff looks defensive. That GitClear error-masking finding deserves more attention than the refactoring stat that got the headlines. One counter-signal to the 74% drop worth watching: some of the fastest-growing agent extensions right now are gatekeepers, spec interrogators that grill you before code is written and review loops that run after. Developers seem to be responding to exactly the instability you describe by making the agent harder to satisfy. Whether that culture spreads faster than the legacy pile grows is an open question. My money says the pile is winning this year.
Good catch on the gatekeeper trend, I hadn't connected that to the error masking finding but it makes sense. If teams are adding spec interrogation and review loops because the first draft can't be trusted, that's basically an admission that speed alone was never the point.
Where I'm less sure is whether this becomes culture or just another checkbox. Spec interrogators and review gates can turn into the same theater as code review already sometimes is, a step everyone rushes through to get the merge button. The real test isn't whether teams adopt these tools, it's whether the person running the gate still has the patience to actually read what comes out the other side.
My guess is you're right that the pile wins this year. But I'd bet the outcome long term depends less on which agent extensions get popular and more on whether teams still reward someone for saying "this isn't good enough" when the tests pass and the diff looks clean. :D
This matches what I see running multiple coding agents side by side. The commits read clean and pass tests, but six weeks later nobody remembers why the agent chose that abstraction because the reasoning lived in a chat window that is gone. The old kind of legacy code accumulated slowly enough that someone could still trace intent from commit messages and tickets. The new kind can pile up in a single afternoon if you approve five agent PRs without reading the diff closely. I have started treating the diff itself as the only durable record, since the summary the agent gives me is often a flattering paraphrase of what it actually did.
Was always going to be this way, in my view. But a reckoning’s coming soon. The error masking finding is the real story here, not the 74% refactoring drop; code that looks defensive but is really just dodging the decision of what should happen on bad input. That’s a new flavor of legacy code: nobody ever understood it, not even the person who merged it. And there’s far more of it shipping than the old hand-written-COBOL era ever produced.
That line about nobody understanding it, not even the person who merged it, is the part that stuck with me too. Old COBOL at least had an author who knew why a weird branch existed, even if that knowledge left the company with them. This new kind doesn't have that. The commit message says the tests pass, and that's the whole explanation.
I'm curious what "reckoning" looks like to you though. With COBOL the reckoning was a slow one, systems just got harder to touch until someone was forced to rewrite. This error masking problem might surface faster, since it's not about age, it's about a specific input nobody tested for finally showing up in production. Feels less like a slow decay and more like something that breaks loud on a random Tuesday.
Either way, I think you're right that scale changes the story. Bad decisions used to take years to accumulate. Now they ship every sprint.