The codebase nobody fully remembers

Somewhere in your company there is a solution file that opens 120 projects, and nobody alive can tell you why all 120 are there.

It works. It ships. It has paid salaries for a decade. And it has slowly crossed the line from understood to inherited. The developer who knew why OrderProcessor has three separate retry paths took that knowledge to another company. The reason the scheduler lives in its own process became a story that shrank with every retelling. Now it is a sticky note that says don't touch the scheduler.

You know this codebase. You might be its maintainer. That job teaches a particular kind of care. You move slowly. You read twice. You carry a private map in your head of which floors creak. That knowledge in your head is the real asset. It is also the thing that walks out the door with every resignation.

Memory decays. Code doesn't.

Here is the asymmetry that makes legacy software feel haunted: the humans forget, but the code never does. The three retry paths still know exactly who calls them. The scheduler still knows exactly which types it touches. Every dependency, every override, every subscription is still there, fully determined, sitting in the source.

The knowledge did not vanish. It just stopped being legible to people.

The participant that never forgot

And here is the strange part. One participant in your team re-derives all of that knowledge, perfectly, several times a day: the compiler.

Every build, it resolves every reference, binds every call to its exact target, and checks every implementation against its interface. The result is a complete, correct graph of how the whole 120-project organism fits together. The compiler must build that graph, or it could not compile a single file.

Then it throws the graph away.

The most complete institutional memory your codebase has ever had is built and discarded on every build, while the humans get by on folklore and sticky notes.

That leaves a question which, once asked, refuses to leave. What if that graph were not thrown away? What if it were readily accessible — not only to the compiler, but also to the newest reader on your team: the agent in your editor, about to plan an edit in a codebase it has never seen?

Everything the veterans took with them is still derivable. Who calls the three retry paths. What the scheduler actually touches. Why project 87 is in the solution at all. Hand the agent the graph, and day one starts to look like year five.

That question is the idea that got us to found GraphSlice: stop throwing the graph away, and give it to the agent that needs it most.