Habr: How a Stale Knowledge Base Breaks LLM Agents, and How to Fix It

Habr has published the second part of a series on LLM development. The author explains why a stale knowledge base is more dangerous than having no documentation at all. If you show an agent polished but outdated markdown, it will take it for truth and start making mistakes at the level of architecture, statuses and dependencies.

Why it matters

The core idea is simple: an LLM trusts its context the way a compiler trusts its input. When a knowledge base holds old service versions, broken links and plans that diverged from reality long ago, the agent works from a false map of the project. The errors then come not from a weak model but from an incorrect description of its environment. For teams running dozens of parallel projects, this quickly becomes a systemic problem rather than a one-off oversight.

The author stresses that manual discipline barely works here. The more documents, repositories and agent sessions there are, the faster a knowledge base accumulates entropy. Even a well-structured workbench goes stale from the moment it is created if nobody checks it automatically. So the question is no longer whether to write documentation, but how to build mechanisms into the process that keep it from quietly degrading and poisoning the next development cycle.

How to catch staleness

The basic answer is simple automated checks that can be run manually or in CI. The author describes a script that was first run on his own workbench and immediately found dozens of problems: more than a third of internal links led nowhere after documents were migrated between repositories. This is especially dangerous for an agent: it tries to follow a link, can't find the file, and either loses context or starts filling the gap with hallucinations. At scale, this quickly becomes a constant source of defects.

• Checking internal links between markdown files
• Monitoring the freshness of key documents by update date
• Coverage check: every project must have a workspace file
• Aggregating TODOs from all markdown documents into a single overview

Separately, the author recommends setting a freshness threshold, for example 60 days, and not rewriting every document from scratch but doing a short review of the facts: versions, statuses, dependencies, current plans. A couple of minutes on such a pass restores trust in the document. The same logic applies to TODOs: as long as tasks are scattered across logs, plans and notes, the team can't see the full picture. Once they are aggregated, the knowledge base becomes a working tool again rather than an archive of random notes.

Rules and pitfalls

Scripts alone are not enough if the documents themselves have no clear lifecycle. The author suggests labeling them with the statuses active, reference, draft and archived, and moving old material to archive/ instead of deleting it. After each phase of work, the agent should update related documents, record unfinished items and, when the context window overflows, build a continuation prompt for the next session. This keeps the knowledge base synchronized between sessions instead of sprawling across the model's memory.

As the author writes:

"An outdated plan is the same poisoned context, only harmless-looking."

The second part of the argument also covers the flip side: LLMs make automation too cheap, so developers easily start optimizing the process instead of the product. Yet another ADR, yet another script or a perfectly crafted pipeline looks like progress, even though production may still lack a working feature. The practical guideline here is strict: product first, then staging, monitoring and CI/CD, then typing, tests and more complex autonomous loops. If a team builds a full "hypothesis, generation, deploy" chain before it has learned to catch a broken merge, it is investing in meta-optimization with questionable ROI.

What this means

The Habr piece hits the main pain point of AI-assisted development: the quality of a model's answer depends more and more not only on the prompt but on the hygiene of the context around the code. For teams and solo developers, the takeaway is practical: a knowledge base should live by the same rules as code, with checks, statuses and regular updates. Otherwise the LLM will speed up not the work but the spread of old errors, which will look plausible and replay from session to session.