The Death of “If It Works, Don’t Touch It”

For decades, the uncontested number one rule of software development has been: if it works, don’t touch it. As far as I’ve heard, it seems more common than it should be for an unmaintained fifteen-year-old piece of code, written by a developer who’s not even in the company anymore, to support core services within the organization.

This is not necessarily irrational. Why risk introducing bugs to improve something your customers won’t even see? Why take the time to deeply understand a poorly written codebase when you could be adding new features to your product? Why fire the old manager when your team has been winning? If it works, why touch it?

1. AI changes the calculation

A twenty-year old codebase may be poorly documented, or written in an old version of a now legacy programming language. It makes sense for a company to avoid investing in a refactor, even if that could potentially offer significant improvements in the long run: it’s just too costly.

Or should I say, it used to be too costly. AI is breaking that calculations by dramatically reducing the cost of understanding and adapting old software. What this means is that the economics of refactoring old codebases is finally shifting. Real world cases of codebases being rewritten or improved by coding agents are becoming more and more common. Some of those are listed below.

1.1. The Bun rewrite

In July 2026, Bun creator Jarred Sumner described how Claude coding agents helped port a codebase containing more than 535,000 lines of Zig to Rust. He said the effort reached a passing test suite across platforms in 11 days, compared with his estimate of roughly a year for a small team of engineers intimately familiar with the code.

1.2. GitHub Copilot migration

GitHub chose to migrate the runtime for their Copilot AI coding agents from TypeScript to Rust, with the goal of improving performance, security, and reliability. By using AI agents, they were able to complete the porting in a few months, resulting in over 800,000 lines of production Rust code.

1.3. Linus Torvalds is using AI too

Linus Torvalds, creator and core maintainer of the Linux kernel, has argued that they should not restrict AI usage, as banning it would be comparable to banning code editors or compilers because they also make programming easier. Recently, he has admitted to using Claude code to make an change to a system within the kernel for the first time.

2. The new dangers of unmaintained codebases

Paradoxically, the very same AI tools that have been making refactoring old codebases so much easier are also starting to make it very dangerous not to do so. For a long time, organizations treated long-running code as inherently robust, as if the more time passed, the safer the code was. But a new age of AI mass vulnerability and bug detection has been changing the game.

As LLM-based vulnerability and bug detection skyrocket, so does the ease with which one can exploit it. Even some of the most audited open source projects in the world have been proven by automated agents to have significant flaws. In fact, by October 2026, Anthropic’s coordinated vulnerability disclosure dashboard showed 6,157 vulnerability disclosures across 591 open-source projects. Even if not every report has been validated, this situation goes to show humans alone may not be able to keep up with AI when it comes to codebase maintenance.

Real world examples illustrate exactly this problem.

2.1. The PHP panic

In October 21, 2026, PHP maintainers issued emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS 4.0. The vulnerabilities could allow unauthenticated remote code execution in affected installations, requiring immediate upgrades.

The situation was so severe that even the United States’ National Security Agency (NSA) issued an emergency warning urging maintainers to take pages down until they updated PHP to a version where the issues have been patched.

Since PHP runs about 70% of sites, often in legacy versions, servers running old versions of the language must have taken an unusually high effort to secure. Several poorly maintained servers will likely be unsafe forever. This illustrates how critical it is becoming to ditch the “if it works, don’t touch it” rule.

2.2. Decades-old OpenBSD flaw

Similarly, in April 2026, Anthropic reported that Claude Mythos Preview had identified and exploited previously unknown vulnerabilities across major operating systems and browsers. One example was a 27-year-old flaw in OpenBSD, an OS with a particularly security-conscious reputation.

2.3. Linux bug fixes

Linux kernel releases are seeing a significant increase in CVE fixes 2026, potentially reaching 2,000 in Linux 7.3, and the sharp rise in bug findings is overwhelming maintainers. There are new proposals to remove legacy code and obsolete drivers to reduce review and patch obligations.

This rise is attributed to a combination of factors, including a surge in reports, many of which are duplicates from AI-assisted tools, and the project’s cautious approach to assigning CVEs, prompting new guidance to reporters to verify, produce reproducible evidence and test fixes.

3. Conclusion

The old rule of not touching code that works is losing relevance with every passing day. Not only does the advent of AI make it possible to better maintain legacy codebases, it also makes it essential to do so, as shown in cases like the PHP vulnerabilities. Thus, we may need a new rule: if it works, understand it, and crucially, be prepared to change it.