Epistemic Debt Is the New Technical Debt

Every engineer knows the feeling of technical debt. You open a file you wrote eighteen months ago, wince, and spend an afternoon paying down the interest on a shortcut you took to hit a date. It's unpleasant, but it's honest debt. You understand the code. You just don't like it.

There's a second kind of debt forming now, and it doesn't announce itself with a wince. It shows up the day you ask your most senior engineer how a service actually works and watch them hesitate – not because they're rusty, but because no one on the team ever fully knew. The code was generated, it passed its tests, it shipped. The understanding was never there to begin with.

That's the debt worth worrying about, and it deserves its own name. A few people are starting to call it epistemic debt, and the framing is sharp enough that I think it's going to stick.

Technical debt was always a debt you could read

The original metaphor assumed comprehension. You ship something imperfect, you know it's imperfect, and you carry the cost of cleaning it up later. The debt lives in the code, and the code is legible. A new hire can read it, swear at it, and refactor it. Painful, but tractable.

The whole model rests on a quiet assumption: somebody understands the system. The mess is in the implementation, not in the team's mental model of what the implementation does. You can always reconstruct the map by reading the territory.

AI-assisted development is quietly breaking that assumption, and it's breaking it from two directions at once.

The model's understanding decays as the context grows

Start with the tool itself. There's a tidy story we tell about large language models – that bigger context windows mean the model "knows more" of your codebase, so its output gets better the more you feed it. The research says the opposite.

Chroma's study on the phenomenon people now call "context rot" found that model performance consistently degrades as input length increases – not at some far-off limit, but steadily, across ordinary tasks. More context doesn't reliably mean better answers. Past a point, it means worse ones.

This isn't a tuning problem you can prompt your way out of. It's structural. As one good explainer put it, context windows ballooned from around 4,096 tokens in 2022 to a million by early 2024, and yet the models still don't use that room well. Anthropic's own framing is the one I keep coming back to: context is "a finite resource with diminishing marginal returns," and the model spends from an "attention budget" every time you hand it more to read.

So the tool generating large swaths of your system is, by its own architecture, worst exactly where your system is most complicated. The more there is to understand, the less reliably it understands. That's a strange foundation to build on without noticing.

The team's understanding decays too

Now the second direction, which is the one that actually costs you. When the model writes the code, the documentation, and the architectural notes faster than any human reads them, the team's shared understanding of the system stops keeping pace with the system.

The firm Lumenalta named this directly. Epistemic debt, in their framing, is when systems become hard to maintain not because the implementation is messy but because the organization no longer understands how they work. Their endpoint is a phrase that should make any engineering leader sit up: loss of system sovereignty. The moment no human on the team can fully account for the reasoning environment that holds the product together.

You can arrive there without a single bad commit. Every PR is green. The tests pass. Velocity looks great on the dashboard. And the understanding just quietly drains out of the building, one generated abstraction at a time.

There's a related failure on the knowledge side. The team at Anapoly describes "knowledge collapse" – the point where an organization's own documentation, ingested wholesale and never curated, stops being a source of truth and becomes a source of error. The AI reads the stale onboarding doc and confidently repeats steps that haven't been true for a year. Garbage in, fluent garbage out, at scale.

Why this one is worse

Here's the distinction I'd draw, and it's the whole argument: technical debt is expensive to fix but cheap to detect. You can see it. A linter flags it, a code review catches it, a new engineer reads the file and knows.

Epistemic debt is the reverse. It's invisible right up until the moment you need the understanding and discover it isn't anywhere – not in a person, not in a doc, not recoverable from the code without a forensic project. You find out you have it during the incident, during the audit, during the rewrite, during the week your one engineer who sort of gets it is on vacation. The interest comes due all at once, and it comes due at the worst possible time.

Technical debt slows you down. Epistemic debt means you can't safely speed up, because nobody can vouch for what the system will do.

Treat understanding as infrastructure, not exhaust

The fix isn't to write less software with AI. That ship has sailed, and honestly it shouldn't come back. The fix is to stop treating your team's comprehension of its own systems as a free byproduct and start treating it as infrastructure you fund and maintain.

That's a different posture than "write better docs," and the difference matters. Documentation is an artifact. Understanding is a capability. Concretely, it looks like a few unglamorous habits: deciding which parts of the system a human must be able to explain without help, and protecting that knowledge deliberately. Curating what the AI is allowed to treat as ground truth, instead of pointing it at the whole wiki and hoping. Reviewing AI-generated work for whether the team understands it, not just whether it runs. Writing down the why behind decisions while the why is still in someone's head, because the model can reconstruct the what and never the why.

None of that is novel. It's the same instinct good teams have always had about institutional knowledge. What's new is the speed at which the gap opens now, and how cheerfully green the dashboard stays while it does.

The teams that come out ahead of this won't be the ones who used the least AI. They'll be the ones who kept paying down the debt they couldn't see – who treated knowing their own systems as the thing that makes everything else safe to build on. Technical debt was a tax on going fast. Epistemic debt is a tax on going at all.