Documentation is knowledge infrastructure
When AI systems act directly on your documentation, it becomes knowledge infrastructure. Here is what that changes about ownership, budget, and risk.

In April 2025, AI code editor Cursor began logging developers out each time they moved between machines. Sam, an AI support bot, explained the lockouts were intentional: a new policy limited each subscription to a single device. But no such policy existed; Sam invented it. The false explanation spread across Hacker News and Reddit before Cursor could correct it, escalating user complaints and cancellation threats.
Sam functioned exactly as AI support layers are designed to, filling a retrieval gap with a confident confabulation. The irony was hard to miss: a company promising AI reliability to developers, undermined by documentation that was never written for a machine to read.
In a way, Cursor was fortunate that the failure was loud. The post went viral and forced a correction within hours. An undramatic version of the same flaw never trends; it just gradually sends dissatisfied users away, without a thread to trace it back to.
The knowledge layer supports everything
AI has moved documentation upstream. Retrieval systems, copilots, and support agents rely on documentation directly to connect users and prospects with what they need. For most of software's history, a human stood between the page and the reader, carrying context the page lacked and filling its omissions. Now, without a person in the loop, what the documentation says is what the user gets.
When a machine reads your documentation and acts on it without a human intermediary, your documentation is infrastructure. It bears a load, and everything downstream depends on its integrity.
When knowledge infrastructure gives way, its failure cascades. Take an onboarding guide that lists a deprecated installation step. Read by one person, it's a minor annoyance, but fed to an agent setting up new developers at scale, it can break every environment it touches.

The industry is picking up on the pattern. Gartner has projected that 60 percent of AI projects unsupported by AI-ready data will be abandoned through 2026, and the consensus across this year's enterprise reporting points away from model quality as the binding constraint and toward a different question: can the knowledge underneath the model be trusted?
Documentation has authors; infrastructure has owners
"Documentation," as a label, sounds like a reference, obscuring its role as an operational dependency. Real infrastructure has an owner, monitoring, and an on-call engineer who is paged when it breaks. Until now, documentation has lacked that kind of stewardship, more commonly scoped as a deliverable: complete once it ships and unowned thereafter.
Unowned documentation is a latent liability until the moment it publicly fails. In 2024, a Canadian tribunal held Air Canada liable after its chatbot incorrectly told a grieving customer he could claim a bereavement fare for his flight, contrary to the airline's policy. When Air Canada argued he should have checked the correct page himself, the tribunal ruled that customers are not responsible for reconciling one part of a company's site with another. The failure lived in the knowledge infrastructure until it openly presented itself.
A knowledge layer that systems depend upon requires someone who is structurally responsible for keeping it current, as every other piece of production infrastructure does. Yet many organizations lack this person, and the org chart offers no obvious place to put one. As teams streamline and ship faster, the absence is easy to miss because a neglected knowledge layer shows no initial symptoms until something reads from it and gets it wrong. Without a steward, that failure erupts, as it did for Cursor, or leaks out slowly and unnoticed.

Your documentation already speaks for you
You already own what your documentation says, whether or not anyone has been made responsible for it. The moment a system acts on your documentation, that documentation speaks for the company, for better or worse. The stories above chronicle an industry learning, case by case, about what incomplete, outdated, or badly structured documentation can cost when AI retrieves it.
Treat your documentation as the knowledge infrastructure it has become. It carries every team that reads from it, and its failures reach just as far. Load-bearing infrastructure must be owned and maintained; otherwise, it can fail your users first and your business next. Talk to us about your knowledge layer.
Related posts from the studio.
AI-ReadinessThe role AI can't fill
Shipper's pirate/architect framework for AI-era teams is missing a third role. Here's what it uncovers, why it keeps getting cut, and why that matters more than ever.
AI-ReadinessPart 3 of 3Why most teams can't maintain AI-ready documentation
AI-ready documentation degrades without someone structurally responsible for maintaining it. Most product teams don't have that person.
AI-ReadinessPart 2 of 3What makes AI-ready documentation
What does AI-ready documentation actually require? Part 2 of our AI readiness series breaks down the five structural components that determine whether AI systems can reliably interpret your docs.
Join the DevDocs Brief
Receive occasional notes from the studio: new articles, case studies, and documentation strategy updates.
See selected emailsTell us about your documentation challenge.
We respond within one business day.