Habr: How Outdated Knowledge Base Breaks LLM-Agents and How to Fix It

Habr published the second part of a series on LLM development: the author explains why an outdated knowledge base is more dangerous than a complete lack of documentation. If you show an agent a beautiful but stale markdown, it will take it for truth and begin to make mistakes at the level of architecture, statuses, and dependencies.

Why this matters

The main idea is simple: an LLM trusts context the same way a compiler trusts input data. When a knowledge base contains old versions of services, broken links, and plans that have long since diverged from reality, the agent relies on a false map of the project. As a result, errors appear not because the model is weak, but because it was given an inaccurate description of the environment. For teams with dozens of parallel projects, this quickly becomes a systemic problem rather than a one-time oversight.

The author emphasizes that manual discipline barely works here. The more documents, repositories, and agent sessions, the faster the knowledge base accumulates entropy. Even a well-structured workbench becomes outdated the moment it is created if no one checks it automatically. Therefore, the question is no longer whether to write documentation or not, but how to embed mechanisms in the process that will not let it quietly degrade and poison the next development cycle.

How to catch obsolescence

The basic answer is simple automatic checks that can be run manually or in CI. The author describes a script that ran through his workbench and immediately found dozens of problems: more than a third of internal links led nowhere after document migrations between repositories. For an agent, this is especially dangerous: it tries to follow a link, doesn't find the file, and either loses context or starts filling it with hallucinations. At scale, this quickly becomes a constant source of defects.

• Checking internal links between markdown files
• Controlling the freshness of key documents by update date
• Checking coverage: each project should have a workspace file
• Aggregating TODO from all markdown documents into a single overview point

The author separately advises introducing a freshness threshold, for example 60 days, and not rewriting every document from scratch, but doing a brief review of the facts: versions, statuses, dependencies, current plans. A few minutes of such a pass returns credibility to the document. The same logic works for TODOs: as long as tasks are scattered across logs, plans, and notes, the team doesn't see the full picture. Once they are aggregated, the knowledge base becomes a working tool again, not an archive of random notes.

Rules and traps

Scripts alone are not enough if the documents themselves don't have a clear lifecycle. The author suggests marking them with statuses active, reference, draft, and archived, and putting old materials in archive/ rather than deleting them. After each phase of work, the agent should update related documents, record unfinished items, and when the context window fills up, collect a continuation prompt for the next session. This way the knowledge base remains synchronized between sessions rather than spreading across the model's memory.

As the author writes:

"An outdated plan is the same poisoned context, just looking innocent."

The second part of the argument brings out the flip side: LLM makes automation too cheap, so the developer easily starts optimizing the process instead of the product. Another ADR, another script, or a perfectly scheduled pipeline look like progress, even though production may still lack a working feature. The practical guideline here is strict: first product, then staging, monitoring, and CI/CD, then typing, tests, and more complex autonomous cycles. If the team builds a complete chain "hypothesis — generation — deploy" before learning how to catch a broken merge, it invests in meta-optimization with questionable ROI.

What this means

The material on Habr hits squarely the main pain point of AI-assisted development: the quality of a model's response increasingly depends not just on the prompt, but on the hygiene of the context around the code. For teams and solo developers, the takeaway is practical: the knowledge base should live by the same rules as code — with checks, statuses, and regular updates. Otherwise, LLM will accelerate not the work, but the spread of old errors that will look plausible and reproduce from session to session.