Your AI writes a README in 4 seconds. Reviewing it properly takes 4 days — if it happens at all.
That's the new documentation problem. Copilot, Claude, and Cursor generate specs, READMEs, and runbooks faster than any team can check them, and unreviewed AI docs are how a README ends up pointing at port 3000 while the app runs on 5173. This guide gives you a practical, tool-agnostic checklist for reviewing AI-generated documentation — the same process whether you review in pull requests, Google Docs, or a purpose-built tool.
Why AI docs need a different review process
Human-written docs fail in predictable ways: they go stale, they skip steps the author thought were obvious. AI-written docs fail differently:
- Confident hallucination. AI states wrong facts with perfect grammar. A human reviewer skimming for "does this read well?" will miss them, because they read great.
- Plausible-but-outdated commands. Models learned from older versions of your stack.
npm install -gadvice that was right in 2023 may be wrong today. - Invented specifics. Port numbers, environment variable names, API parameters — AI fills gaps with plausible inventions rather than leaving blanks.
- Drift at generation time. The doc was accurate against the codebase the AI saw — which may already be three merges behind.
Style review catches none of these. You need a truth review.
The 7-point review checklist
1. Run every command. Don't read commands — execute them in a clean environment. This single step catches most AI documentation bugs (wrong flags, missing prerequisites, renamed scripts).
2. Verify every number and name. Ports, versions, env var names, file paths, API endpoints. Check each against the actual codebase, not your memory. These are the highest-hallucination-risk tokens in any AI doc.
3. Check claims against the current branch. Ask: "was this generated against the code as it exists now?" If the doc describes behavior, find the code that implements it. If you can't find it, flag it.
4. Look for invented features. AI loves completing patterns: if your API has GET and POST documented, it may "helpfully" document a DELETE that doesn't exist. Every capability mentioned needs a source.
5. Review structure separately from truth. Do two passes: one only for factual accuracy (steps 1–4), one only for structure and audience fit. Mixing them is how errors slip through — your brain switches to editor mode and stops fact-checking.
6. Leave comments where the text is. Review feedback in Slack ("the port is wrong in that one doc") gets lost. Comments must be anchored to the exact line, with suggested replacement text, so the fix is one click — not an archaeology project.
7. Re-review on every regeneration. AI docs get regenerated, not edited. Each regeneration can silently reintroduce an error you already fixed. Track review state per version, and diff regenerations against the reviewed version.
Making this a team habit
The checklist works solo, but documentation review scales the same way code review did — with process and tooling:
- Assign a doc reviewer in the same PR/ticket that generated the doc. Unowned reviews don't happen.
- Time-box it. 15 minutes per doc with the checklist beats "whenever someone gets to it" (never).
- Track a simple metric: time from doc generated → doc reviewed. If it's over a week, your docs are effectively unreviewed.
Where tooling helps
Everything above works in any tool, but the friction is real: PR comments are built for code, not prose; Google Docs breaks Markdown formatting the moment you paste; and Slack feedback evaporates.
This friction is why we built DotMD — a place where your team reviews Markdown docs the way you review code: line-anchored comments, suggested edits you accept in one click, AI assistance inside the document, and two-way GitHub sync so the reviewed doc is the shipped doc. If your team is drowning in AI-generated docs, join the customer beta — Premium workspace features are included free during beta.
But tool or no tool: run the commands, verify the numbers, and never trust a doc that reads too smoothly to question.