Why documentation drifts, and why more effort never fixes it

Ask any product team about their documentation and you will hear the same story. It was good once. Someone cared about it, wrote it carefully, and shipped it alongside a launch. Then the product kept moving and the documentation did not. A setting was renamed. A screen was redesigned. A limit was raised. Each change was small enough that nobody stopped to update the page describing it — and small changes accumulate.

Drift is not a discipline problem

The instinctive diagnosis is that people are not disciplined enough. If engineers updated the docs with every pull request, if product managers filed a ticket for every change, the problem would go away. This diagnosis is wrong for a simple reason: it has been tried by every team that has ever existed, and it has never held for more than a quarter.

The reason is structural. Documentation is the only part of a software product that depends on someone noticing that something changed and then remembering to write it down, with no system enforcing either step. Code does not compile if you forget a dependency. A test fails if behaviour changes. A page of documentation simply stays as it was, indefinitely, and looks exactly the same whether it is right or wrong.

Why sprints make it worse

The standard response to drift is a documentation sprint: a week or two where the team audits every page, fixes what is wrong and declares victory. Sprints work, briefly. Accuracy jumps to near 100% on the last day of the sprint and begins declining on the first day after it. Worse, the sprint teaches the organisation that documentation is a periodic project rather than a continuous property, which guarantees the next decline will be tolerated until it is bad enough to justify another sprint.

Plotted over a year, documentation accuracy under this model is a sawtooth: a sharp rise, a long fall, repeat. The average is poor, and readers experience the average.

The actual failure: no trigger, no owner

Strip away the discipline framing and two facts remain. First, there is no reliable trigger connecting a change in the product to the page that describes it. Second, when a page is found to be wrong, there is often no owner whose job it is to fix it. Everything else — the tooling, the writing quality, the sprints — sits on top of those two gaps.

Close the gaps and drift stops. A system that watches for the events that make pages wrong (releases, renamed settings, questions readers keep asking) and routes each one to a proposed change with a named approver does not need discipline. It needs a loop.

What we built instead

DocOpsly exists because we stopped trying to make people remember. Agents monitor the triggers, read the existing documentation as the source of truth, draft the change and route it to the person who can confirm it. That person approves, edits or returns it. The documentation is never "finished" — it is continuously corrected, which is the only state in which it stays accurate.

In the coming months we will write about how the loop works in practice, how a workspace governs it, and what changes for teams once writing stops being anyone's job. This post is the reason all of it exists.