Product docs rarely fail in one dramatic rewrite. They fail in small drifts: a setting that moved, a screenshot from last quarter, a step that still describes the old billing flow. Readers follow the page and get stuck. You only hear about it when support does.

A weekly drift check is a short, boring habit that catches that earlier. An AI assistant can help you draft the update. It cannot tell you, on its own, whether the product still works that way.

This is the first of a short cluster on keeping docs honest. A companion note (for Hashnode) covers verifying a generated draft against the code. Another (for Telegraph) covers writing a one-page brief before you let an assistant draft a README.

What “drift” looks like

Drift is any place where the page and the product no longer match. Typical signs:

• A button, path, or limit that was renamed or moved.
• A policy or price that changed in the product but not in the article.
• An example that uses a field you have removed.
• A “coming soon” that has either shipped or been dropped.

If you wait for a full documentation project, these sit in front of customers for weeks. A short check, aimed at the pages people actually use, is enough for most teams.

A 20-minute weekly pass

1. Pick a small set. Three to five of the most-used pages, or the pages that changed in the product this week. Do not try to read the whole set every time.
2. Walk the product. Open the real screen, the current plan, or the current API behaviour. Keep the doc beside it.
3. Mark only what drifted. A stale screenshot, a wrong path, a missing condition. Leave style and tone for a later edit.
4. If you use an AI draft, treat it as a suggestion. Paste the current page and a short note of what changed. Then check every changed sentence against the product, the way you would check a colleague’s edit. Delete anything the draft invented to be helpful.
5. Publish the fix the same day if you can, or log it with an owner and a date. An unpublished list of drifts is itself a form of drift.

The documentation category on Toolbit is a useful map if you are choosing a tool to help with drafts or change detection. The tool does not replace the walk-through. If a product claims it can “keep docs in sync,” still run this check on a page you know has changed.

What not to automate away

Do not let a scheduled rewrite touch every page each week. That produces fluent, slightly wrong prose, and it makes genuine reviews harder. Use automation to flag candidates (a ticket titled “billing limits changed,” a merged pull request, a changelog line). Use a person to confirm the product and to accept the edit.

Legal, pricing and safety pages should always get a named reviewer, even when the change looks small.

Checklist

• You have a short list of high-use pages, not a vague intention to “look at the docs.”
• This week’s check was done against the live product, not only against last week’s article.
• Every accepted AI edit was checked sentence by sentence.
• Someone can see what changed, and who approved it.

Takeaway

A weekly walk-through of a few important pages will do more for accuracy than a long AI rewrite of the whole set. Update only what has drifted, and check it against the product before you publish.