AI Writes the Docs. Humans Still Have to Verify Them. DraftView Is the Missing Link.

The New Default: AI Opens the PR

Something has quietly shifted in how documentation gets created. AI coding assistants, autonomous agents, and LLM-powered CI pipelines can now draft changelogs, generate API reference pages, update tutorials to match code changes, and open pull requests against your documentation repository — all without a human typing a single word.

GitHub Copilot suggests inline docs as engineers write code. Devin and its successors open PRs that include documentation updates alongside the code changes. Pipelines built on GPT-4o and Claude auto-generate release notes from commit history and post them as PRs the moment a tag is cut. Documentation-specific tools like Mintlify and Swimm detect code changes and propose corresponding doc updates automatically.

This is genuinely useful. Documentation debt is real, and anything that reduces the gap between what the code does and what the docs say is worth having.

But it creates a new problem.

The Problem: AI Docs Aren't Self-Certifying

A PR opened by an AI agent is still a PR. Someone still needs to read it.

Not because AI output is necessarily wrong — it often isn't — but because accuracy alone isn't sufficient for documentation that ships to users. A few things AI-generated docs routinely get wrong that automation cannot catch:

Factual drift. The AI generated content from context it had. That context may be incomplete, outdated, or subtly wrong. An API parameter description that's almost right is more dangerous than one that's clearly wrong.

Tone and voice. Your documentation has a register — a level of technicality, a relationship with the reader, a house style. AI output approximates it. Your users notice when it doesn't match.

Legal and compliance exposure. Auto-generated disclaimers, license references, and security advisories have a way of being almost-correct. Legal counsel needs to see the actual text.

Knowledge the model doesn't have. Undocumented constraints, known limitations, current support policies, in-flight deprecations — these live in people's heads, not in the training data. Only a human reviewer can catch what the model didn't know to include.

The Bottleneck: Review Still Runs at Human Speed

Here's where the process stalls. The AI generates ten documentation PRs in the time it used to take a writer to draft one. But review capacity hasn't scaled. You still have one PM who needs to approve product copy, one legal contact for compliance-sensitive text, one SME for technical accuracy.

The review queue fills up. PRs age. Someone merges without the sign-off that was supposed to happen. Or review becomes a rubber stamp — approvals happening too fast for any real scrutiny because the volume is too high.

The bottleneck has moved. It used to be content creation. Now it's human verification.

What the Review Step Needs

For human-in-the-loop to work at the pace AI generates content, the review interface has to be fast, low-friction, and suited to non-technical reviewers.

GitHub's native PR interface isn't any of those things for documentation. Raw Markdown diffs require the reviewer to mentally render the content. Suggested Changes require understanding the diff format. For an engineer reviewing code, this is fine. For a PM, a legal contact, or a domain expert who needs to approve content quickly, it's a barrier that causes delays, skipped reviews, and rubber stamps.

DraftView as the Review Layer

DraftView sits between the AI-generated PR and the merge. It renders the documentation as it will appear when published — formatted prose, not raw Markdown — and gives reviewers a Google Docs-style interface to comment and suggest edits inline.

The workflow with AI-generated documentation PRs looks like this:

1. The AI agent opens a PR against your docs repository.
2. DraftView picks it up — either via the GitHub App or by pasting the PR URL into the dashboard.
3. You share a review link with whoever needs to verify the content: a technical lead, a PM, a legal contact, an external SME. They get a password-protected link. No GitHub account required.
4. They read the rendered document, leave inline comments, and suggest corrections directly in the text.
5. You review their feedback in DraftView and push approved suggestions back to the PR as native GitHub Suggested Changes.
6. The PR merges with a real audit trail: who reviewed it, what they flagged, what was accepted.

The AI handles the volume. The human review layer handles the judgment. The audit trail handles the accountability.

The Missing Link

The problem with most human-in-the-loop documentation workflows isn't that people are unwilling to review. It's that the review interface makes it hard. When review is fast and the interface matches how non-technical stakeholders already work, the bottleneck clears.

DraftView doesn't replace the writer or the AI. It replaces the part of the workflow that was never designed for documentation review at scale: the raw GitHub diff sent to someone who just wants to read the document and say whether it's correct.