Can AI recover project knowledge that only ever lived in one person’s head?

Part two of this series continues our look at reviving a project that sat untouched for years. The first post covered building an honest, current picture of the codebase fast enough to actually start working with it. This entry picks up right after that: once you’ve uncovered what’s there, how much of it can you truly recover—and how much walked out the door with the person who built it? Follow the series for the rest of the story.

Every abandoned project carries two different kinds of missing information, and they are not the same problem. One common issue is a lack of documentation: nobody wrote down what the API does, what the data model looks like, or why a particular decision was made. The other is missing knowledge: the reasoning behind a specific choice, a number tuned by feel, a half-built feature nobody remembers starting. The first is a writing problem. Reading the code carefully enough eventually solves it. The second is a memory problem, and no amount of reading code fixes a memory problem by itself.

For this project, we set out to honestly answer how much of each we could actually get back. If there’s an old system sitting somewhere with the person who understood it long gone, or about to be, this is the same question, just asked earlier.

What we did

With no code touched, we generated the documentation that never existed: a full API surface (every endpoint, method, and auth requirement), the complete data model across all six MongoDB collections, and six reconstructed architecture decisions, each carrying its own confidence level rather than being stated as a settled fact.

Then came the harder half. Not what’s there, but what’s actually recoverable at all. We checked every piece of the project against everything else, looking for things that were quietly disconnected: a feature that looks finished but goes nowhere, a piece of data that nothing touches anymore, code that runs but doesn’t actually do anything. It turned into 21 specific open questions, and 7 confirmed dead ends, logged one by one rather than folded into a single vague “needs more investigation” note.

Separating these three mattered, not for the sake of being thorough, but because it was about which answer to actually trust:

• Confirmed from the code
• Reconstructed, needs a second look
• We don’t know

A data model read straight off the field names carries a different level of confidence than an architecture decision reconstructed from the folder structure, and neither is the same as an answer that only exists because we asked the person who wrote the code and they remembered. Blending those three into one document would have quietly turned guesses into facts. None of this was academic: reading the resulting artifacts rather than the codebase itself reduced what would normally take four to eight days of onboarding to about two hours.

One technical moment

Buried in the model package was a MongoDB collection called Karma, with a single field named howOften, referenced by no service, no controller, no test anywhere in either repo. Data like this, real and structured, but untouched by anything else in the app, usually means one of two things: an unfinished feature, or a fossil left behind by something that replaced it.

The name alone wasn’t a strong enough signal; any placeholder-sounding field could just be an unfinished feature. What actually gave it away was finding chanceIndex doing the same job somewhere else: Match.java had a field by that name, controlling exactly how often a goal chance fires during a match. Same concept, two names, one of them clearly older.

That was a hypothesis, not a fact. Code alone can tell you two things look alike; it can’t tell you which one came first or why the older one is still sitting there. The confirmation came from asking directly: Karma was the original attempt at making goal frequency configurable, replaced once chanceIndex did the same job with a simpler per-match random value. Nobody ever went back to delete the old collection, not a design choice, just the kind of cleanup that never makes it to the top of anyone’s list.

This is a small detail, but it captures the bigger pattern behind this whole post: the code got us most of the way there on its own, close enough to form a real hypothesis, and one direct question closed the last gap the code alone never could, which one came first, and why nobody ever went back to clean up the older one.

Where AI helped

Most of the game engine was reconstructed cleanly from the code alone. The data model, the API surface, the match lifecycle, and the scheduler timing are all fully recoverable without asking a single question, because the code reflects what a system does, not why; it is close to a complete record once someone actually reads all of it end-to-end.

Where it stopped being that simple was one layer underneath: not what a number does, but why it’s that specific number. Seven engine constants (base scoring chance, home advantage, offside rate, and four more) all landed on the same honest answer once we asked directly: gut feeling, no statistics behind any of them, validated only informally, by colleagues saying the simulated results looked realistic at the time. That’s not a gap in the reconstruction. It’s the actual, complete answer, and the only place it could come from was the person who typed the number in originally.

Some of it never turned up at all, and no amount of asking fixes that either. The pre-2022 git history is simply gone; the repo was moved, and nothing before that move survived anywhere. Whether the simulation actually felt right to the ten or so colleagues who played it back then is gone too; nobody recorded reactions at the time, and a specific feeling from a decade ago isn’t something a follow-up question can restore. Two features, real-time weather at the stadium actually affecting outcomes, and the Karma concept before it got replaced, sit half-wired in the code. Were they still being actively worked on, or already been given up on? Nobody knows, not even the person who wrote them.

The first read of this felt like a clean 80/20, most of it accounted for, a clear minority gone. Counted against the 21 specific things actually logged during the reconstruction, it breaks down as 11 confirmed straight from the code, 4 reconstructed only after asking directly, and 6 nobody could answer at all. Recovered in some form, that’s closer to seven in ten, not the cleaner 80/20 the first read suggested. The rest is gone for good, and the project keeps running without it. Tuning it further just means guessing again, the same way it was tuned the first time.

Why this matters if you’re hiring a nearshoring team

A frozen, undocumented project like this used to carry an unavoidable tax: someone had to read all of it, slowly, and even then, the reasoning behind half the decisions was a guess. That tax is exactly what makes old codebases expensive to touch, and it’s exactly the kind of client that used to be a hard sell, too much unknown, not enough certainty about what’s actually underneath.

What changes here isn’t that the reading happens faster. It’s that we can now tell you, honestly and specifically, which parts of the answer are solid because the code proves them, which parts were reconstructed and still need a real conversation to confirm, and which parts are simply gone. That distinction is the actual deliverable. A wrong answer stated with total confidence is worse than no answer at all, and the real discipline here was treating “confirmed,” “reconstructed, needs a second look,” and “we don’t know” as three separate categories, not one blended pile of documentation with everything stated the same way.

That distinction is also, in miniature, what changes about the debt a project like this carries forward. Missing documentation is cheap to fix, once someone reads the code properly, it’s just writing. Missing knowledge, the reasoning that only ever lived in one person’s head, is the expensive kind. The only real defense against losing it again is writing the “why” down the first time it’s decided. Not after the person who knows it has already moved three jobs on. That habit doesn’t cost anything extra. Not having it does, later, for whoever inherits the project next.

What’s next

Documentation and recovered knowledge tell you what a project is. They don’t tell you whether it’s safe to touch. The next post tackles that question head-on: real dependency and security findings, reached with the same rigor used here to separate documentation from guesswork — and revisited months later with precise numbers rather than gut instinct.

Stay tuned for the rest of the series, next up: whether that same discipline survives contact with a real security audit.