How much time does your team waste each week searching for information that already exists somewhere?
A 2001 study estimated that a worker spent one-third of their day searching for information. These figures, which have since been disputed, should be used with caution. But the qualitative observation remains valid in 2026: despite decades of investment in document management, enterprise search, collaborative platforms, and modern documentation methodologies, information management remains problematic in most organizations.
There are numerous scenarios, according to a taxonomy based on 878 real-world documentation artifacts: documentation that is nonexistent, obsolete, incomplete, inconsistent with processes or code, illegible, or impossible to find. The risks extend beyond productivity alone. Regulatory noncompliance can have serious consequences. The departure of a “local guru” can paralyze an entire operation.
The Limitations of Past Approaches
Each generation of tools has contributed something. None has solved a problem whose causes remain remarkably stable.
The effort-benefit imbalance. The person who documents is not the one who benefits from it, and documentation is seen as a waste of time compared to more productive tasks.
The lack of a feedback loop. A test that fails triggers an immediate alert. Documentation that has become inaccurate only becomes apparent later, to a reader, without any warning.
The vicious cycle of trust. Outdated documentation erodes trust in the information and demotivates those who took the trouble to maintain it.
Culture takes precedence over process. Serious documentation problems persist despite formally well-defined processes. No tool has ever corrected this.
The human cost. Diátaxis [4] is a robust methodology, but it relies on ongoing editorial discipline, and manually auditing an existing corpus quickly becomes unmanageable.
The Benefits and Limitations of Artificial Intelligence
Of these five causes, artificial intelligence addresses only two: those related to time and detection. The asymmetry of benefits and the influence of organizational culture remain entirely foreign to it. It does not perform miracles: it does not generate knowledge that does not exist, and, being non-deterministic, it does not guarantee the accuracy of what it produces. Its reliability is therefore never absolute.
Still, this criterion must be applied fairly. An answer obtained from a colleague is no more reliable: they may be mistaken, have an older version of the system in mind, or be reasoning within a related scope. The same applies to a document found on the intranet; there is no guarantee that it is up to date or that it has been reviewed. Organizations have always operated with uncertain information. They have learned to evaluate it based on its context: who wrote it, when, and for what purpose. Artificial intelligence does not solve this problem, and to claim otherwise would be a mistake in analysis.
What it does change is the time required to access information. Querying a system in natural language rather than navigating through directory trees, receiving a formulated response rather than a list of results, reading a reconstructed business rule rather than four hundred lines of conditions—the time required to access information changes by an order of magnitude for an activity that takes up a significant portion of the workday.
This reduction in time also makes feasible what has always been the best safeguard against error: cross-checking. Comparing the code, a ticket, and an architecture note is a reflex that everyone is familiar with but that almost no one puts into practice, because it represents a disproportionate effort relative to the question at hand. When automated, it becomes a routine operation, and discrepancies between sources themselves constitute valuable information, indicating where the documentation has fallen out of sync with the actual system.
Two reservations remain.
The first one concerns the nature of what is accessible: trade-offs, historical constraints and architectural decisions remain tacit within individuals and cannot be extracted from any repository.
The second concerns the form of the answers obtained: a fluid and well-structured answer inspires more confidence than a colleague’s hesitation. Traceability back to the source is becoming a necessity, enabling the reader to exercise the same judgement that they apply, without even realising it, to a colleague’s answers.
The first cannot be extracted from any repository. The second stems from the form of the answers obtained: a fluid, well-constructed answer inspires more confidence than a colleague’s hesitation. Traceability back to the source becomes a necessity; it allows the reader to exercise the same judgment that they apply, without thinking about it, to a colleague’s answers.
Toward Living Documentation
Documentation is only “living” if it is a byproduct of the system rather than a parallel artifact, if deviations are detected automatically, and if we agree to document only what poses a genuine business risk. Producing ten thousand pages that no one will read would, on a larger scale, replicate the failure of wikis.
At 5th floor, we implement solutions based on this approach. It involves first defining the critical scope—the processes and components whose lack of understanding would pose a real risk to business continuity, revenue, or compliance—and then building a foundational body of documentation from existing sources (code, tickets, notes, communications) rather than starting from a blank page. This foundation is then made searchable using natural language, with systematic attribution of sources, and cross-checking is automated with every system update, so that discrepancies are flagged before a reader discovers them.
