# Stop Calling It Legacy Code

*With AI in the picture, it's not legacy anymore. It's a Knowledge Container.*

- Author: Bartosz Frąckowiak
- Published: 2024-02-19
- Canonical: https://bfrackowiak.pl/blog/stop-calling-it-legacy-code/
- Also on Medium: https://medium.com/@bfrackowiak/stop-calling-it-legacy-code-02308db28cb2
- Tags: legacy-systems, artificial-intelligence, software-architecture, knowledge-management, software-development

---

We've all been there. You join a new team, clone the main repository, open your IDE, and immediately let out a heavy sigh. It's the dreaded *legacy codebase*. For years, "legacy" has been the ultimate dirty word in software engineering. It was the monster under the bed, the excuse for missed deadlines, and the justification for multi-million-dollar rewrite initiatives.

But I have a thesis that might make a few software architects uncomfortable: **in the era of AI, legacy code no longer exists.** The entire concept of "legacy" is expiring. What we are left with is something far more valuable, and it's time we change how we look at it.

## Why Did We Call It "Legacy" Anyway?

Let's be honest with ourselves for a second. What actually makes code **legacy**?

Historically, code became legacy the exact moment developers simply didn't want to maintain it anymore. It was an incentive problem. The promise of working with brand-new, shiny technology means being more efficient, learning new skills, and therefore remaining highly competitive on the job market. Not everyone wants to put "maintained a 10-year-old monolith" at the top of their CV.

To justify moving away from it, we tended to argue that legacy code is inherently more costly to evolve and that adding new features is too slow.

But here is the reality check: **code is incredibly cheap now.** With AI, generating code is no longer the bottleneck. Legacy code isn't the primary factor slowing down system development; unnecessary *complexity* is what actually kills productivity.

Oh, and let's not forget the most important part: many times, that ugly, outdated, legacy code is exactly what is paying our monthly salaries.

## The Tech Stack Doesn't Matter Anymore

The fact that the technology used in an older codebase isn't state of the art means absolutely nothing to a Large Language Model.

As long as the code passes your functional and non-functional acceptance criteria (like performance and scalability), the age of the syntax is irrelevant. What matters right now isn't the framework. It's the data stored *inside* the code.

## From Codebase to "Knowledge Container"

This brings us to the core of the shift. If it's not legacy code anymore, what is it? It is a **Knowledge Container**.

Think about it. That repository is the single most accurate, battle-tested database your company owns regarding:

- Deeply embedded business processes.
- Highly specific edge-case acceptance criteria.
- Real-world workflows that no one currently working in the office actually remembers.

In the past, code went out of date the moment a developer hit *commit*. Today, that commit just becomes highly structured training data, a rich knowledge base for AI agents to read, understand, and act upon.

## The Rise of the "Dev Operators"

Because of this, we don't need massive, groundbreaking "greenfield" initiatives just to keep systems in sync with modern standards.

If the tech stack no longer matters, the role of the human changes. We are moving away from being traditional engineers who manually type out logic, to becoming **"Operators."** An Operator's job isn't to write the code; their job is to leverage the Knowledge Containers, express the business intent to an AI agent, and accurately judge the final result.

The concept of legacy code simply won't work anymore in the long term. It's a relic of an era where humans had to read every line.

Now, I just wonder: if we stop tracking Technical Debt, how long will it take for us to invent a metric to measure a system's **"Knowledge Density"**?