The hidden cost of code that nobody touches

Every engineering org has the files nobody wants to open. The modules that work, technically, but that require a two-hour archaeology session before anyone can safely change a single line. The migration project that's been "almost done" for eighteen months.

This is big code. And it's becoming the defining challenge for engineering teams in 2026.

Codebases don't stay small

When a codebase is young, navigating it is straightforward. You can hold most of it in your head. You know where things live. New engineers get productive in days.

Then time passes. The team grows. Features accumulate. Acquisitions happen. A three-year-old startup acquires a legacy system with a twenty-year history. Suddenly you have code living in three different version control systems, written in four languages, with dependencies that nobody fully understands.

This is the normal trajectory. One Sourcegraph customer builds tools used by millions of engineers worldwide. Their codebase spans forty-plus years of development across Perforce, GitHub, and GitLab, written in C, C++, Java, and JavaScript. The engineers who wrote some of that code retired long ago.

This is what software looks like at scale.

The migration problem compounds

The instinct when facing a large, aging codebase is to migrate it. Move from one framework to another. Consolidate version control. Update dependencies. Modernize the build system.

These projects are almost always harder than they look because the starting point is unclear. Before you can migrate code, you have to understand it. Before you understand it, you have to find it. And in a codebase spanning millions of lines across dozens of repositories, "find it" is not a simple operation.

A developer trying to understand the scope of a migration has to answer questions like:

• Where is this API actually used, across all our repos?
• Which services depend on this library, directly or transitively?
• Which files will break if we change this interface?
• Are there other places in the codebase doing the same thing differently?

In a small codebase, these are trivial questions. In a big one, they can consume days of investigation before any actual migration work begins.

AI tools are running into the same wall

The promise of AI coding assistants is that they accelerate development. And at small scale, they deliver. But the same big-code problem that slows human developers is starting to slow AI agents too.

Most AI tools work by loading relevant code into a context window. When a codebase is small enough to fit, this works well. When it is not, the agent has to guess which files matter. It retrieves some, misses others, and produces suggestions that look right locally but break things elsewhere.

A developer who knows the codebase can catch these mistakes. A developer who does not, or an AI agent working without sufficient context, cannot.

The result: the teams with the largest, most complex codebases, the ones who could benefit most from AI acceleration, are often the ones who get the least out of it.

What actually changes when you solve this

When engineers have real visibility into a large codebase, migrations stop being archaeology projects and start being engineering projects.

At MathWorks, a JavaScript memory leak that historically took multiple weeks to diagnose was tracked across modules in under a week once engineers had proper cross-repo search. Tasks that used to take hours or days started happening in minutes.

That time compounds. A migration project that would have taken six months of cautious, uncertain work becomes something a team can actually plan and execute against a real deadline.

The codebase does not get smaller. But the cost of understanding it, navigating it, and changing it does.