Zombie Code

A program consists of many instructions written by a developer. Over the years, new features are added and old ones get replaced. The old instructions are often not deleted, but merely deactivated or forgotten. Exactly these remnants are called zombie code: it is actually dead, but still lingers in the project. Sometimes it is even still executed without anyone knowing about it. The name plays exactly on this: something that shouldn’t still be alive, but still moves nonetheless.

What the old remnants really cost

At first glance, zombie code sounds harmless. Unused lines don’t do anything, after all. The problem is not computing power, but people’s attention. Anyone who wants to change a program must first understand what happens inside it. Every dead line costs reading time and creates doubt.

It becomes especially costly with bugs. A developer searches for hours in a part of a program for the cause of a problem. In the end, it turns out that this part hasn’t been called for three years. Such dead ends accumulate in large projects. In companies with millions of lines of code, this is a real cost factor.

There is also a security aspect. Old code often contains outdated methods, for example for storing passwords. If it is never maintained, but is nevertheless executed under certain circumstances, a vulnerability arises. Attackers specifically search for such forgotten corners. A zombie is therefore not just annoying, but sometimes dangerous.

How code becomes a zombie

The most common path is the convenient one. A developer replaces a function but doesn’t delete the old one. Instead, they disable it with a comment or a switch. This feels safe in case the new solution causes problems. Only, later on, nobody takes the time to remove the remainder.

A second path leads through so-called feature flags. These are switches in the program that companies use to turn features on or off for individual user groups. If a switch is never touched again after testing, the associated code remains forever in a dark state. It is there, it could run, but nobody watches it.

It’s important to distinguish this from unreachable code. Unreachable code can technically never be executed, for example because it sits behind a condition that is always false. Such spots are usually found automatically by an analysis tool. Zombie code is trickier: it is technically reachable, but is practically no longer needed. No software can reliably detect this—only a human who knows the product can.

Zombies in large software projects and in AI systems

Every large piece of software carries such legacy baggage. Banks operate programs that have grown since the 1980s. Operating systems contain routines for devices that no longer exist. Whenever technical debt is mentioned in the news, zombie code is almost always part of it. This refers to the sum of shortcuts that are later paid back with interest.

With AI tools, the topic takes on new significance. Programs like GitHub Copilot automatically suggest entire code sections. Developers often accept these suggestions faster than they can review them. This results in more lines being written in less time, and part of it is never actually used. Several industry studies have reported since 2024 on a growing share of duplicated and unused code.

There are remedies. Companies measure which parts of a program are actually called during live operation. Whatever sees no requests for months ends up on the deletion list. A common misconception, by the way, is that deleting is risky. Since every serious company stores all old versions in a version control system, deleted code can be retrieved at any time. Keeping it around in the live project is therefore almost never necessary.