There is something slightly strange happening in software right now.
For decades, one of the biggest limitations inside companies was simple: there were never enough developers.
If a business wanted a custom application, it needed developers. If the engineering team was busy, the project went into a backlog. If building something internally was too expensive, the company bought a SaaS product instead.
That equation is changing.
A recent article in CIO, titled “AI is making software cheap to build. Is your organization ready for what comes next?”, makes a very interesting argument: AI is changing software from something scarce into something that can be produced in abundance.
And I think there is a second part to that story which deserves much more attention.
If software becomes cheap to create, understanding software may become the new bottleneck.
That is where things get really interesting.
The software abundance problem
The CIO article gives a fascinating example from Perplexity.
Two engineers, working with hundreds of AI coding agents, reportedly built CobbleDB, a roughly 40,000-line Rust key-value store, in around two months. The system eventually handled part of Perplexity's production search traffic.
There are obviously caveats around the numbers and the economics of building and maintaining custom infrastructure. But the larger point is hard to ignore.
AI allows a very small team to create a lot more software.
And this isn't only happening inside AI companies.
A finance team can build its own reconciliation tool.
A sales team can build an internal application.
A developer can ask an AI agent to create a utility instead of spending several days writing it manually.
A product team can create a small internal workflow without going through the traditional software procurement process.
Individually, none of these decisions sound crazy.
Actually, most of them sound like good decisions.
The problem appears when you have hundreds or thousands of them.
Suddenly an organisation doesn't just have its official applications.
It has scripts.
Internal tools.
AI-generated applications.
Small services.
Experimental repositories.
Temporary utilities that were supposed to exist for six months but are still running two years later.
And somewhere inside all of that is probably something nobody remembers creating.
Creation is getting cheaper. Discovery isn't.
This is probably the most important part of the shift.
For a long time, software creation was expensive.
So companies naturally tried to reuse what they already had.
If an application already existed, there was little reason to build another one.
But what happens when creating something new takes an afternoon?
The incentive changes.
Instead of spending two days trying to find whether another team already built something similar, a developer can simply ask an AI agent:
"Build me one."
That sounds productive.
And it is.
Until you have 20 versions of almost the same thing.
AI is reducing the cost of creation.
But it hasn't magically reduced the cost of understanding.
Finding out what already exists is still difficult.
Understanding dependencies is still difficult.
Knowing whether something is safe to remove is still difficult.
Knowing who owns a system is still difficult.
Understanding why a piece of code exists is still difficult.
And figuring out what will break if you change something is still very difficult.
This is where the software industry may be heading into a rather uncomfortable problem.
We may soon have more software than we can properly understand.
The hidden cost of AI-generated software
Imagine an enterprise with 500 officially recognised applications.
That already sounds like a lot.
Now imagine that underneath those 500 applications there are another few thousand:
- AI-generated internal tools
- Developer utilities
- Scripts
- Automation workflows
- Small APIs
- Temporary applications
- Experimental repositories
- Department-specific software
Most of them won't appear in the CIO's application inventory.
Some may not even have a proper owner.
Some may have access to sensitive data.
Some may depend on systems that nobody remembers connecting.
And some will probably become important without anyone deliberately deciding that they should.
This creates a new type of technical debt.
I would call it software sprawl.
And unlike traditional technical debt, software sprawl can happen incredibly fast.
The real question changes
For many years, the engineering question was:
"Can we build this?"
Then it became:
"How quickly can we build this?"
With AI, we're increasingly moving toward:
"Should we build this at all?"
And then another question follows:
"What happens after we build it?"
Who owns it?
What does it depend on?
Who depends on it?
Is it still being used?
Can it be safely changed?
Can it be safely deleted?
What happens if the engineer who created it leaves?
And perhaps the most important question:
Do we already have something that does this?
These aren't purely coding questions anymore.
They are software intelligence questions.
This is why codebase intelligence matters
At Mapnostics, this is the problem we have been thinking about.
The goal isn't to make another AI coding assistant.
There are already plenty of tools helping developers write code faster.
The interesting problem is what happens after the code exists.
A modern engineering organisation needs to understand its software continuously.
Not just during a pull request.
Not just when something breaks.
Not just when a new developer joins the team.
It needs to understand the relationships inside the system.
What depends on what?
Which code is actually being used?
Which code is dead?
Which code is technically alive but effectively abandoned?
Where are the architectural risks?
Who understands the critical parts of the system?
What will happen if we remove this function?
What will happen if we change this API?
What services could be affected?
And what evidence supports the answer?
That is the direction of Mapnostics.
From code analysis to software intelligence
One of the things that interests me most is how this changes the meaning of "codebase intelligence."
It shouldn't simply mean searching through a repository.
A useful intelligence layer should build a living model of the software.
`text Repository ↓ Files ↓ Symbols ↓ Imports ↓ APIs ↓ Services ↓ Applications ↓ Business capabilities `
Once those relationships are understood, completely different questions become possible.
Instead of asking:
"Where is this function?"
you can ask:
"What depends on this function?"
Instead of:
"Can I delete this file?"
you can ask:
"What is the impact of deleting this file?"
Instead of:
"Is this repository healthy?"
you can ask:
"Which parts of our software estate are becoming risky?"
That's a very different kind of product.
Impact matters more than lines of code
One feature I think becomes particularly important in an AI-generated software world is impact analysis.
Imagine an engineer wants to remove an authentication middleware.
A normal code search may show where the middleware is referenced.
But that isn't necessarily enough.
You want to understand the chain:
`text Authentication Middleware ↓ Routes ↓ Services ↓ Data Access ↓ Applications ↓ Users / Workflows `
Now the engineer can make a decision based on the actual blast radius.
That's much more useful than simply knowing that a string appears in 27 files.
The future of software intelligence isn't just about finding code.
It's about understanding relationships and consequences.
Dead code is no longer a small cleanup task
The same applies to dead code.
Traditionally, finding unused code has been treated as an engineering cleanup exercise.
But in an AI-first development environment, it can become a much larger problem.
AI agents can generate code very quickly.
Some of that code will be useful.
Some won't.
Some will be replaced.
Some will become obsolete.
And some will sit there quietly.
Over time:
`text More AI-generated code ↓ More unused code ↓ More dependencies ↓ More uncertainty ↓ More risk `
Finding and understanding that unused software becomes part of controlling the software estate.
Not just cleaning up a repository.
The next software problem may not be building
This is the part of the CIO article that I found particularly interesting.
The author argues that enterprise IT has spent decades getting better at building software, and that knowing what you own and when to retire it could become the harder problem.
I agree.
We have seen similar patterns before.
Cheap storage didn't eliminate data problems.
It created more data.
Cheap cloud infrastructure didn't eliminate infrastructure management.
It created cloud sprawl.
And cheap software creation may not reduce software complexity.
It may create an enormous amount of it.
The companies that win won't necessarily be the ones that create the most software.
They will be the ones that can understand, control and evolve what they create.
The AI-native enterprise needs a map
This is where I think the "Google Maps for codebases" idea becomes more relevant than ever.
When you drive through an unfamiliar city, you don't want a list of every road.
You want a map.
You want to know where you are.
Where you can go.
What's connected.
What's blocked.
And what happens if you take a different route.
Software is becoming the same way.
As systems become larger, teams need more than code search.
They need a map.
A map of dependencies.
A map of architecture.
A map of ownership.
A map of risk.
A map of change impact.
And eventually, a map of the entire software estate.
AI will create more software than we have ever seen
I don't think this trend is going backwards.
AI coding agents will get better.
Non-technical employees will build more applications.
Developers will manage larger systems with smaller teams.
Companies will replace more SaaS products with internal software where the economics make sense.
And organisations will experiment much more freely.
That's all potentially very positive.
But there is a catch.
Software abundance without software intelligence can become software chaos.
The answer isn't to stop people from building.
The answer is to make the software they build understandable.
That's the problem we are interested in solving at Mapnostics.
Because the next generation of engineering tools won't only help us create software faster.
They will help us understand what we've created.
And perhaps that will turn out to be the bigger problem.
---
Reference
CIO — “AI is making software cheap to build. Is your organization ready for what comes next?”
Read the original article on CIO
Disclosure: Mapnostics is a codebase intelligence platform focused on helping engineering teams understand software structure, dependencies, risk and change impact.