Dead code is code that exists in your repository but never executes. It is there in the file tree, occupying space, appearing in search results, and occasionally confusing developers who stumble across it. It compiles. It passes linting. It just never runs.
Most teams know they have dead code. Few teams do anything about it. The reasoning is understandable: if it does not run, it cannot cause bugs. If it cannot cause bugs, it is not a priority. There are always more pressing things to work on than deleting code that is not causing problems.
But dead code does cause problems. They are just not the kind of problems that trigger alerts or show up in incident reports. They are the kind that quietly slow down your entire team, every day, in ways that are difficult to attribute to any single cause.
What counts as dead code
Dead code takes several forms, and not all of them are obvious.
Unused functions and methods. These are functions that were written for a feature that was later removed, refactored, or abandoned. The feature is gone, but the utility functions that supported it remain. They are fully implemented, sometimes well-tested, and completely unused. No call site exists anywhere in the codebase.
Unreachable branches. These are conditional paths that can never execute because the conditions that would trigger them are no longer possible. A configuration flag that was removed. A feature toggle that is always on. An error handler for a condition that was eliminated three refactors ago. The branch exists, but no input can reach it.
Commented-out code. This is code that someone disabled by commenting it out instead of deleting it. The intention was usually to keep it available in case it was needed again. In practice, it is never uncommented. It sits in the file, breaking up the logic, confusing anyone who reads it, and serving as a monument to decisions that were never fully committed to.
Orphaned files. These are entire files – modules, components, configuration files, test fixtures – that are not imported, required, or referenced by anything. They exist in the repository because they were never deleted when the code that depended on them was removed.
Unused exports. A module exports ten functions. Three of them are imported by other modules. The other seven are exported but never used externally. They may be used internally within the module, or they may not be used at all. Either way, the export is dead.
Dead dependencies. A package.json lists 40 dependencies. Five of them are not imported anywhere in the codebase. They were added for a feature that was removed, or for a build step that was replaced, or because someone tried a library and decided against it without cleaning up.
Why dead code accumulates
Dead code does not appear all at once. It accumulates gradually, through a series of individually reasonable decisions.
Fear of breaking things. Deleting code feels risky. If you delete a function and something breaks, you are responsible. If you leave it in place, nothing changes. The incentive structure favours inaction. This is especially true in legacy codebases where the test coverage is low and the consequences of a mistake are high.
Unclear ownership. In large teams, nobody is sure who owns a particular module or function. It was written by someone who left two years ago. Maybe it is used by a background job that runs monthly. Maybe it is called by an external system. Nobody wants to be the person who deletes something that turns out to be important, so nobody deletes anything.
No cleanup culture. If your team does not explicitly value cleanup, cleanup does not happen. Sprint planning focuses on features and bug fixes. Code review focuses on the changed lines, not the surrounding context. There is no process for periodically reviewing whether existing code is still needed.
Partial refactors. A developer refactors a module. They create a new implementation and switch the call sites to use it. But they do not delete the old implementation because they want to keep it as a reference, or because the PR is already large enough, or because they plan to come back and remove it later. They never come back.
The real costs of dead code
Dead code imposes costs that are real but rarely measured.
It confuses new developers. A developer joins the team and starts reading the codebase to understand the system. They find a module with 15 functions. They try to understand how those functions fit together, how data flows through them, which ones are important. Seven of those functions are dead. The developer does not know that. They spend time understanding code that does not matter, building a mental model that includes components that are not actually part of the system. The onboarding experience is longer and more confusing than it needs to be.
It inflates complexity metrics. If you measure your codebase by lines of code, cyclomatic complexity, or function count, dead code makes those numbers worse than they should be. A module that reports 3,000 lines of code but only uses 2,000 of them appears more complex than it actually is. This distorts planning estimates, risk assessments, and any analysis that relies on codebase size or complexity as an input.
It hides bugs. Dead code can mask issues in the living code. A search for a particular pattern or variable name returns results in dead code alongside results in active code. A developer scanning the search results might assume that a variable is handled in a certain way because they see it handled that way in the dead code, not realising that the dead code is irrelevant. The dead code creates false signals that make debugging harder.
It slows builds and pipelines. Dead code is still compiled, transpiled, bundled, linted, and scanned. In large codebases, the cumulative effect of processing thousands of lines of unnecessary code adds up. Build times are longer than they need to be. CI pipelines consume more resources. Static analysis tools report findings in code that nobody uses.
It creates false confidence about coverage. If dead code has tests, those tests pass, contributing to coverage metrics without testing anything that matters. If dead code does not have tests, it shows up as uncovered code, creating noise in coverage reports and making it harder to identify genuinely under-tested areas.
How to detect dead code
Detecting dead code is harder than it appears, because the difficulty depends on the type of dead code and the tools available.
Manual search. A developer reads through the codebase, looking for functions that are not called, files that are not imported, and branches that cannot be reached. This is thorough but prohibitively slow for any codebase of meaningful size. It also requires deep knowledge of the system to know which code paths are active and which are not.
Linters and static analysers. Tools like ESLint, TSLint, and similar can detect some forms of dead code: unused variables, unused imports, unreachable code after return statements. But they operate at the file level or the function level. They cannot reliably determine whether a function is called elsewhere in the codebase. They catch the obvious cases and miss the structural ones.
Coverage tools. Running your test suite with code coverage enabled shows which lines execute during testing. Lines that never execute might be dead code. But this approach has a significant limitation: it only detects dead code that is also untested. If a dead function happens to have a test, coverage tools will not flag it. And if your test coverage is low, coverage tools will flag both dead code and living code that simply lacks tests, making it impossible to distinguish between the two.
Dependency analysis. Tools like depcheck (for Node.js) or similar can identify unused packages. This catches dead dependencies but not dead functions or unreachable branches within the code.
AI code review. An AI reviewer that reads the entire codebase can identify dead code that no single-file tool can detect. It can trace call chains across modules, identify functions that are exported but never imported, find configuration files that are no longer referenced, and distinguish between code that is genuinely unreachable and code that is rarely used but still active. This cross-file analysis is where AI review provides the most value for dead code detection.
A practical approach to cleanup
Removing dead code does not have to be a heroic effort. A systematic, incremental approach works better than a single large purge.
Start with confidence. Begin with the dead code you can identify with certainty: unused imports, variables declared but never referenced, files that are not imported anywhere. These are safe to remove and build team confidence that cleanup is valuable and safe.
Use version control as your safety net. The most common objection to removing dead code is that someone might need it later. Version control eliminates this concern. If the code is in your git history, it can be retrieved. Deleting it from the current codebase does not erase it from existence.
Review before deleting. Code review should cover deletions as carefully as additions. When someone removes a function, the reviewer should verify that no call site exists, that no dynamic invocation references it, and that no configuration file or external system depends on it.
Make it a habit, not a project. The most effective teams treat dead code removal as an ongoing practice, not a quarterly initiative. When you edit a file, check whether everything in that file is still used. When you remove a feature, trace the dependency graph and clean up the orphaned code. Small, frequent cleanups prevent the accumulation that makes large cleanups intimidating.
Dead code detection with VibeRails
VibeRails performs full-codebase analysis, which means it reads every file in your project and builds a comprehensive picture of what is used and what is not. This cross-file perspective allows it to identify dead code that file-level tools miss: functions that are defined in one module and never imported by any other, components that were part of a removed feature, configuration files for integrations that no longer exist.
The result is a structured report that categorises dead code by type and location, with enough context for your team to review each finding and decide whether to remove it. It is not a delete button. It is the information you need to clean up your codebase with confidence, knowing that what you are removing is genuinely unused.
Limits and tradeoffs
- It can miss context. Treat findings as prompts for investigation, not verdicts.
- False positives happen. Plan a quick triage pass before you schedule work.
- Privacy depends on your model setup. If you use a cloud model, relevant code is sent to that provider; local models can keep inference on your own hardware.