March 2024. A colleague from Rocksoft and I join a project, a solid application, running for years. It quickly turns out to be built on Vue 2, whose end of life was December 31, 2023, a quarter earlier. The framework is officially unmaintained: it no longer receives security patches. And yet it still installs, the build passes, "it works." It's 2026 now, and the project is still on Vue 2.
That's the heart of the problem: "it works" is a temporary state. We take on technical debt in exchange for a short-term gain, a faster release, one more feature, but it carries interest, and that interest grows with every month of delay. This piece is about what that risk really is, and how AI changes the economics of paying it down.
What it costs
Debt isn't a budget line someone deliberately approves. It's the gap between what a system should cost to maintain and what it actually costs.
The scale is real: developers at the average company spend roughly a third of their time servicing debt instead of building new features. For a ten-person team, that's the equivalent of more than three full-time positions a year, consumed by invisible overhead.
Why the business defers it, and why that's a mistake
A new feature has a face: you can show it to a client. Migrating to a newer framework version has none. Once it's done, the application works exactly the same, except it ate weeks of work. Deferring therefore looks rational, but it's wrong on two levels.
First, "don't touch it" doesn't mean "nothing happens." Unmaintained dependencies accrue new vulnerabilities that no one will patch, browsers retire APIs, and the documentation and answers online refer to versions two generations newer. Maintaining a dead stack is programming with a flashlight in an archive.
Second, deferring grows the debt itself. Every feature added on top of an outdated foundation is new code to be rewritten later. The migration target doesn't wait in place, it grows with each sprint.
And at the end waits a paradox: the neglected foundation starts blocking the very features it was neglected for. In our project, the libraries needed to extend one of the features were available only for the newer framework version. So as long as we stayed on Vue 2, that feature remained out of reach.
Two faces of the risk
When debt grows too large, the bill can arrive all at once, and it hurts.
Equifax (2017): attackers got in through a known vulnerability in Apache Struts for which a patch had existed for months but was never deployed. Roughly 147 million records of personal data leaked. It's the classic cost of not updating, and little has changed since, as nearly all Struts downloads still go to unsupported versions today.
The axios attack (2026) shows the opposite face: "keep everything up to date" isn't a free pass to security either. In a supply-chain attack, attackers hijacked the maintainer account of one of the most popular JavaScript libraries and shipped malicious releases that pulled down a remote-access trojan on install. What failed here wasn't inaction but automation. Pull requests from dependency-update bots carry an implicit trust and tend to get waved through without scrutiny, and the malicious change spread across public repositories within minutes.
The lesson from both cases: updates demand attention, not just frequency. The risk lies as much in standing still as in racing forward blindly.
End of life isn't only about missing features
End of support means, above all, no more security patches. And not just for the framework core, but for the entire ecosystem of plugins around it, which dies along with it. Each such dependency is a separate, unmaintained piece of attack surface.
Then comes compliance: many teams can't ship unsupported software because of clauses in SLAs and contracts, and "it works, so we'll leave it" can eventually collide with an audit.
Paid extended support is sometimes available, but it's a crutch. It only buys time for the inevitable: migration.
How AI changes the math
The main argument for deferring, "migration is weeks we don't have," has just stopped being true.
Classic bots (Dependabot, Renovate) detect outdated packages and open PRs, but they don't fix breaking changes. On larger API shifts they leave you a red build to resolve by hand. Language models (Claude, Codex) go a step further: they perform the actual transformation of the code to the new framework version. McKinsey estimates that generative AI in application modernization speeds up timelines by 40 to 50% and cuts debt-related costs by around 40%.
The key is the verification loop, which closes the gap between "the code compiles" and "the code works in the browser." By wiring the model up to a browser through MCP (e.g. Playwright or Chrome servers), the model, after rewriting a view, reads the console itself, catching runtime errors and warnings, and fixes the code before a human ever sees it.
A counterpoint is necessary: AI is not an autopilot. Models can "hallucinate" dependencies, sometimes with names that have been maliciously registered, and machine-generated code falls into the same implicit-trust trap as bot PRs. There's a lot of it, it looks solid, so it's tempting to wave it through without review. AI lowers the cost of performing the migration, not the cost of understanding what's entering the project. The human doing code review stays the most important element, especially given supply-chain risk.
In practice
Start with visibility: an audit of your dependencies and a full list of what actually enters the project (an SBOM), transitive dependencies included.
Keep automation on a leash. Bot PRs go under human eyes, a cooldown for fresh releases, automerge at most for small patches with test coverage. Treat AI as a supervised migration accelerator, not an unsupervised executor.
The hardest part is usually the conversation with the business, and this is where the engineer tends to lose, because they talk about "updates" when they should talk about risk and cost: a framework with no security patches, contractual clauses, a third of the team's time lost to debt.
And since the cost of migration itself has just dropped, the old "we can't afford it" needs recalculating from scratch.
Technical debt doesn't go away on its own. But with the right tools, you can finally stop paying only the interest and start paying down the principal, before it grows beyond what you can handle.
