There is a simple test we believe every developer tool should pass:
Would the team building it use it on their own product?
For Mapnostics, this was never really a question.
Mapnostics exists to help engineering teams understand their codebases, identify dead and zombie code, uncover dependencies and understand the potential impact of changes.
So at some point, we had to turn the same lens on ourselves.
We ran Mapnostics against the Mapnostics codebase.
And what we found was a useful reminder that even the people building a code intelligence platform don't have a perfect mental model of their own software.
We identified 28 dead code candidates and 14 zombie code candidates that we investigated and cleaned up.
The numbers themselves weren't the biggest lesson.
The lesson was how easily software accumulates things that nobody intentionally decided to keep.
We weren't expecting a perfectly clean codebase
Mapnostics was, and still is, an actively evolving product.
Features change.
UI components get replaced.
Experiments become production features.
Architecture evolves.
APIs get modified.
Old implementations are replaced by newer approaches.
When you're moving quickly, removing every piece of obsolete code immediately isn't always the highest priority.
Sometimes you need to ship.
Sometimes an old implementation is left temporarily because the team is focused on a more important feature.
Sometimes nobody is completely sure whether a particular piece of code is still being used.
That's normal.
The problem appears when those decisions accumulate.
A few unused components become dozens.
A temporary implementation becomes part of the repository's permanent history.
A feature disappears from the product, but pieces of its implementation remain.
Eventually, the repository contains not only the software the company is running today, but also traces of software it used to run.
That's what we wanted to investigate.
28 dead code candidates
Our first category was dead code.
Mapnostics identified 28 candidates that appeared to have no meaningful active role in the application.
We didn't simply delete everything automatically.
That is an important distinction.
A code intelligence system shouldn't say:
"This looks unused. Delete it."
It should help an engineer ask:
"Why does this look unused, and what evidence supports that conclusion?"
We investigated the candidates, looked at their relationships and references, and then removed the code that we determined was genuinely obsolete.
That process reinforced one of the principles behind Mapnostics:
Detection is not the same thing as deletion.
The tool should surface evidence.
The engineer should make the decision.
Then came the more interesting category: zombie code
The 14 zombie code candidates were more interesting.
Zombie code is different from straightforward dead code.
It may still have references.
It may still be connected to parts of the system.
It may have remnants of an older feature or implementation.
But its original purpose may no longer exist.
It is code that has effectively outlived the reason it was created.
This is one of the reasons zombie code can be more difficult to identify.
A simple search for unused files isn't enough.
You need to understand relationships and context.
Some of the candidates we investigated were connected to the evolution of features and implementations that had changed over time.
The code hadn't necessarily been created incorrectly.
It had simply survived longer than its purpose.
That's a very different problem.
The surprising part was that we built the tool
There was a certain irony in the exercise.
We're building a product whose purpose is to help teams understand complicated codebases.
And our own codebase still accumulated obsolete code.
But that's actually an important finding.
Dead and zombie code aren't necessarily symptoms of bad developers.
They are often symptoms of software evolution.
A healthy software team can still produce obsolete code.
A fast-moving startup can produce more of it.
A large enterprise can accumulate enormous amounts of it over years.
And with AI coding tools making software creation dramatically faster, this problem could become even more pronounced.
AI could make this problem much bigger
Historically, there was friction involved in creating software.
Developers had to write the code.
They had to understand the architecture.
They had to spend time implementing an idea.
That friction naturally limited how much software a team could produce.
AI is removing some of that friction.
An engineer can ask an AI coding agent to create a component, prototype a feature, generate an integration or implement an alternative approach in a fraction of the time.
That's an incredible productivity improvement.
But there is a second-order effect.
If creating code becomes dramatically easier, creating code that eventually becomes unnecessary also becomes easier.
The future repository may contain the history of hundreds of AI-assisted decisions.
Some will become important.
Some will be replaced.
Some will never make it into the final product.
Some will remain technically present even after their purpose disappears.
The cost of writing that code may be close to zero.
The cost of understanding it later won't be.
The real problem isn't 42 pieces of obsolete code
It would be easy to look at our numbers and conclude:
28 dead + 14 zombie = 42 pieces of unnecessary code.
But that's not really the important number.
The bigger issue is the uncertainty surrounding the codebase.
If an engineer encounters an unfamiliar component, they need to determine:
- Is it used?
- Who uses it?
- What depends on it?
- Is it part of a critical flow?
- Can it safely be removed?
- What happens if we change it?
- Is it an old implementation?
- Is there a newer replacement?
That investigation consumes engineering time.
Multiply that across hundreds or thousands of components and the cost becomes significant.
This is why we think dead-code detection is really a software understanding problem.
Dead code creates noise
There is another reason this matters in the age of AI.
AI coding agents increasingly rely on the repository as context.
They search the codebase.
They identify similar implementations.
They infer patterns.
They use existing components as references for new work.
If the repository contains large amounts of obsolete code, the system has more noise to reason through.
An old implementation can look like a valid implementation.
An abandoned component can look like an architectural pattern.
A deprecated API can look like something the system still expects developers to use.
The repository becomes a historical archive rather than a clean representation of the current system.
That creates a subtle problem:
The more code you have, the more important it becomes to know which code actually matters.
This changed how we think about Mapnostics
Before running our own analysis, it was easy to think of dead-code detection primarily as a cleanup feature.
After using it on our own codebase, we started thinking about it differently.
Dead code is one signal inside a much larger software intelligence problem.
The same codebase contains information about:
- Architecture
- Dependencies
- Ownership
- Active and inactive components
- Change impact
- Technical risk
- Historical implementations
- Critical paths
Dead-code detection is simply one way of asking:
What in this system still matters?
Impact analysis asks:
What happens if we change it?
Dependency analysis asks:
What is connected to it?
Architecture analysis asks:
How is the system actually structured?
Together, these provide something more useful than a list of files.
They provide a model of the software.
We don't want Mapnostics to blindly delete code
This experience also reinforced something we care about deeply.
We don't want Mapnostics to become a button that says:
"Delete 42 things."
Software is too complicated for that.
Instead, we want Mapnostics to help engineers make better decisions.
If something looks dead, show the evidence.
If something looks like zombie code, explain why.
If something has important dependencies, expose them.
If removing something could have a large impact, make that visible.
The goal is not to replace engineering judgment.
The goal is to give engineers better information before they exercise it.
Our own codebase became part of the product test
There is another benefit to using Mapnostics on Mapnostics.
Every time the system produces a questionable result, we learn something.
Every false positive tells us something about the analysis.
Every missed relationship tells us something about the intelligence model.
Every confusing finding tells us something about how the product should communicate evidence.
That makes our own repository more than just our production code.
It becomes one of our test environments.
We're not building Mapnostics around an imaginary codebase.
We're building it against the same problems we encounter ourselves.
Software doesn't stay clean by itself
The biggest lesson from finding those 28 dead code and 14 zombie code candidates wasn't that our codebase was messy.
It was that software naturally accumulates history.
Features come and go.
Architecture evolves.
Teams change.
Products pivot.
Implementations get replaced.
And code remains.
The longer a software system lives, the more important it becomes to distinguish between what exists and what still matters.
That distinction is going to become even more important as AI accelerates software creation.
The future codebase may contain more code than any engineering team has ever had to manage.
The winning teams won't necessarily be the ones that write the most.
They'll be the ones that can continuously understand what they've built.
We learned that firsthand.
We built Mapnostics to help teams understand their codebases.
Then we pointed it at our own.
28 dead code candidates. 14 zombie code candidates. 42 pieces of software history that we were able to investigate, understand and clean up.
And perhaps the most important result wasn't what we removed.
It was what the exercise taught us:
If you're building software continuously, you also need to continuously understand what deserves to remain.