Your engineering dashboard says the work is done. The build is green, the tests pass, and a manager signs off. Then an audit finds that a meaningful slice of the product cannot be reached from anywhere.
That is what I found in Team-X, an open-source, local-first desktop app for running AI-agent organizations. An audit deleted 3,640 lines of renderer code that compiled, had tests, and was connected to nothing. The changelog records it. The lesson is for anyone who funds or runs software teams: green is not the same as shipped.
The metric that misleads you
Compiling and passing tests are the two signals most teams report upward. Neither says whether a user can ever reach the code. A function can be correct, typed, and tested, and still never run in the product, because the test calls it directly and the product never does.
The definition I use now is simple. Code is done when an import chain connects it to a real entry point. Everything else is an orphan, and orphans have a carrying cost.
What the orphans did
Two examples from the audit show why this is a governance problem and not a tidiness problem.
- Install dialogs that invented permissions. The skill and tool install dialogs showed a "manifest preview" of tool names and capability grants. The repo records that this preview was invented client-side, with no manifest fetched or parsed. A user would have approved an install against a screen the app made up. The real manifest loader sat unused behind the live dialogs.
- A scheduler that never scheduled. A queue file described itself as the orchestrator's only scheduler primitive, the path every agent execution flowed through. The orchestrator never imported it. A manager reading that header would have believed a pause control worked through it. Real dispatch lived elsewhere.
Nothing in the repo shows a user ever saw the dialogs, because nothing could reach them. The exposure was latent: a trap for the next engineer who wired a button to whatever looked finished.
Why dead code is a business risk
The most expensive documented case is Knight Capital. The SEC's account says: "Although this function was not meant to be used, Knight left it in the router." The same SEC press release says the firm "eventually suffered a loss of more than $460 million" after trading began on August 1, 2012.
Google treats dead code as a cost to be removed automatically. In its engineering write-up on Sensenmann, the team says the project "submits over 1000 deletion changelists per week, and has so far deleted nearly 5% of all C++ at Google." Its method starts from the dependency graph: "This allows us to find libraries that are not linked into any binary, and propose their deletion."
Security guidance says the same thing in plainer terms. The OWASP Top 10 entry on vulnerable and outdated components tells teams to "Remove unused dependencies, unnecessary features, components, files, and documentation." The Team-X audit dropped three dependencies that only dead code used.
There is a performance angle too. A 2023 study of JavaScript dead code says: "The costs for downloading and parsing dead code can negatively contribute to the loading time and resource usage of web apps." That study covered mobile web apps, so treat it as direction rather than a number for your stack.
Is AI-assisted development making this worse?
I will keep this claim narrow. The repo does not record who or what wrote the dead code, and I am not going to guess. What I can cite is a trend. GitClear's 2025 research analyzed 211 million changed lines and reports "a spike in the prevalence of duplicate code blocks, along with increases in short-term churn code, and the continued decline of moved lines (code reuse)."
That is a study of duplication and churn, not dead code. But the direction matters for an operator: plausible code is cheaper to produce than ever, so the review that asks "does anything call this?" has to become a tool, not a habit.
What to do about it
- Change the definition of done. Require a reachability check, an import chain to a named entry point, before a feature is reported complete.
- Run an entry-point audit once. List real entry points and print every file with no inbound chain. Tools such as Knip do this for JavaScript and TypeScript.
- Treat headers and docs as claims. Where a file says "this is the only X", verify that the system uses it.
- Pin every deletion. Team-X turned tests that read dead files as text into tests that assert the files are gone. A deleted module that can quietly return was never deleted.
- Prune the supply chain. Remove dependencies only the orphans used, then rerun your vulnerability scan.
The full engineering account, including the code and the guard tests, is in 3,640 lines of code nobody could reach. This work is on main in the repo and was not in a tagged release when I wrote this.
-Rocky
#TeamX #DeadCode #CodeAudit #EngineeringDreams #StrategiaX
Originally published on Team-X Blog.