DraftView · Review Explorer · an interactive explainer

DIFF REVIEWAI AGENTS · 12/MOPEOPLE · 8/MOREAD, ON THE RECORD · 0READ, NO RECORD · 20MERGED UNREAD · 0
  • In: 12 from AI agents, 8 from people · gate: diff review
  • read, on the record: 0
  • read, no record: 20
  • merged unread: 0

A sample month: 20 doc PRs, 12 opened by AI agents, reviewed by diff review with reviewers in Google Docs. Hover a source to follow it. Change the numbers further down and this figure follows.

What happens to a doc PR after the AI opens it?

Writing got automated. Review did not. Doc PRs now arrive at machine speed and wait for a person who can tell whether they are true.

This page follows one of them through three ways a team can review it, then lets you put in your own numbers to see what a month looks like.

Read the storyTry it on a public PR

e built DraftView because documentation teams kept telling us the same thing in different words: the AI opens pull requests faster than anyone can read them. Not faster than anyone can approve them. Approving is easy. Reading is the part that does not scale.

Our guide to docs-as-code review covers how review works when people write the docs. This page is about what changes when an agent does. It runs on the same per-tool assumptions as the cost of docs drift calculator, so the two never disagree.

The short version: in most teams, rubber-stamping is the default outcome, not a failure of character. When PRs pile up, approving without reading is the path of least resistance, and a wrong date ships looking exactly like the right one.

As you scroll, you will see what one doc PR is made of, three ways its review can go, and then you can put in your own team's numbers. At the end there is a chapter on the docs that never get a PR at all, and how doc reviews bring the same people to them.

Chapter 1

A doc PR is a bundle of claims.

PR #1284 · opened by an agent at 02:144 files

Migrating to API v3

Breaking changes

Timeline

Think of one doc PR.

Number 1284, “Migrating to API v3,” opened by an agent at 02:14. It changes four files. Every sentence in it is a claim about the world.

Some claims a machine can check.

Links resolve. The build passes. The endpoint exists. CI is good at these, and they are the minority.

Some claims only a person can check.

“Rate limits now apply per token.” Nothing in CI knows whether that shipped. Someone who was in the meeting does.

Some claims the agent got confidently wrong.

The date is July 31 in the PR. It is June 30 in the contract. In a diff, both look fine. Tap it to see.

The people who would catch it can't read the diff.

Maya, the writer, can. Leo, the PM, opens the PR, sees Markdown, and closes the tab. Dana in Security has no GitHub account at all.

So review happens at human speed, or not at all.

Three days later the PR is still open. Approving without reading is the path of least resistance.

This happens 20 times a month.

Across every repo, every agent, every shift. From one PR to the queue.

The PR in this example is fictional and used throughout this page. The reviewer roles are the ones DraftView is built for: writers, PMs, Legal, Security, and subject experts.

Chapter 2

Three ways review can go.

PR #1284 under diff review

2 days open

  1. day 0An agent opens #1284.
  2. day 0Maya reads the diff and approves the parts she knows.
  3. day 0The text is pasted into Google Docs for Leo and Dana.
  4. day 2Leo replies: “It’s June 30.” Dana doesn’t.
  5. day 2Maya re-types the fix into the Markdown by hand.
  6. day 2Merged. The date is right.
Fixed after about 2 days. The record is a green checkmark and a Google Docs copy nobody will find.

There are many ways review can go. Here are three.

The outcome depends on who reads the page, how they read it, and whether anyone checks the agent's follow-up. The rest of this page uses these three names.

The default outcome: stamped

Nobody decided this. The queue did. It costs no reviewer time and checks nothing, which is why it wins whenever volume outruns attention.

Accurate, partial, slow: diff review

Review the way most teams do today. Engineers catch what engineers know. Everyone else reviews in Google Docs, and about 15% of them never answer. Change the tool further down and this beat changes with it.

The rest of the page is using this scenario

The loop closes: read review

Whoever can judge the page reads the page, comments sit on the sentence, and the agent's fix is checked against the comment before anyone signs off. A human still merges, in GitHub.

Open the live demo. It works best on a larger screen.

Chapter 3 · your numbers

How does review go on your team?

Put in your own numbers and the rest of the page will show you what a month of doc PRs looks like under each scenario.

20
60%
3
Where they review today

20 doc PRs a month, 12 of them opened by an AI agent, each needing 3 non-technical reviewers who review in Google Docs today.

20 doc PRs a month, 12 of them opened by an AI agent, each needing 3 non-technical reviewers who review in Google Docs today.

* The AI share is your estimate; nothing on this page measures it. Reviewer minutes, delays, and how many reviewers go silent come from the published per-tool defaults in the cost of docs drift calculator. Engineering review is the same in every scenario, so it is left out.

Chapter 4 · four findings

Here is what a month of doc PRs looks like for a sample team.

Finding 1: People-time

Read review costs a fraction of the people-time of diff review.

Your 20 PRs take about 50 hours a month under diff review and about 11 under read review, roughly 4.4 times less. Nobody re-types feedback from Google Docs, and nobody decodes a diff.

People-hours per month for 20 doc PRs, by scenario. One square = one hour.
none

0h

Writer, one hour 1 of 30: carrying feedback back into the sourceWriter, one hour 2 of 30: carrying feedback back into the sourceWriter, one hour 3 of 30: carrying feedback back into the sourceWriter, one hour 4 of 30: carrying feedback back into the sourceWriter, one hour 5 of 30: carrying feedback back into the sourceWriter, one hour 6 of 30: carrying feedback back into the sourceWriter, one hour 7 of 30: carrying feedback back into the sourceWriter, one hour 8 of 30: carrying feedback back into the sourceWriter, one hour 9 of 30: carrying feedback back into the sourceWriter, one hour 10 of 30: carrying feedback back into the sourceWriter, one hour 11 of 30: carrying feedback back into the sourceWriter, one hour 12 of 30: carrying feedback back into the sourceWriter, one hour 13 of 30: carrying feedback back into the sourceWriter, one hour 14 of 30: carrying feedback back into the sourceWriter, one hour 15 of 30: carrying feedback back into the sourceWriter, one hour 16 of 30: carrying feedback back into the sourceWriter, one hour 17 of 30: carrying feedback back into the sourceWriter, one hour 18 of 30: carrying feedback back into the sourceWriter, one hour 19 of 30: carrying feedback back into the sourceWriter, one hour 20 of 30: carrying feedback back into the sourceWriter, one hour 21 of 30: carrying feedback back into the sourceWriter, one hour 22 of 30: carrying feedback back into the sourceWriter, one hour 23 of 30: carrying feedback back into the sourceWriter, one hour 24 of 30: carrying feedback back into the sourceWriter, one hour 25 of 30: carrying feedback back into the sourceWriter, one hour 26 of 30: carrying feedback back into the sourceWriter, one hour 27 of 30: carrying feedback back into the sourceWriter, one hour 28 of 30: carrying feedback back into the sourceWriter, one hour 29 of 30: carrying feedback back into the sourceWriter, one hour 30 of 30: carrying feedback back into the sourceReviewers, one hour 1 of 20: reading and commentingReviewers, one hour 2 of 20: reading and commentingReviewers, one hour 3 of 20: reading and commentingReviewers, one hour 4 of 20: reading and commentingReviewers, one hour 5 of 20: reading and commentingReviewers, one hour 6 of 20: reading and commentingReviewers, one hour 7 of 20: reading and commentingReviewers, one hour 8 of 20: reading and commentingReviewers, one hour 9 of 20: reading and commentingReviewers, one hour 10 of 20: reading and commentingReviewers, one hour 11 of 20: reading and commentingReviewers, one hour 12 of 20: reading and commentingReviewers, one hour 13 of 20: reading and commentingReviewers, one hour 14 of 20: reading and commentingReviewers, one hour 15 of 20: reading and commentingReviewers, one hour 16 of 20: reading and commentingReviewers, one hour 17 of 20: reading and commentingReviewers, one hour 18 of 20: reading and commentingReviewers, one hour 19 of 20: reading and commentingReviewers, one hour 20 of 20: reading and commenting

50h

Writer, one hour 1 of 3: carrying feedback back into the sourceWriter, one hour 2 of 3: carrying feedback back into the sourceWriter, one hour 3 of 3: carrying feedback back into the sourceReviewers, one hour 1 of 8: reading and commentingReviewers, one hour 2 of 8: reading and commentingReviewers, one hour 3 of 8: reading and commentingReviewers, one hour 4 of 8: reading and commentingReviewers, one hour 5 of 8: reading and commentingReviewers, one hour 6 of 8: reading and commentingReviewers, one hour 7 of 8: reading and commentingReviewers, one hour 8 of 8: reading and commenting

11h

  • writer, carrying feedback back
  • non-technical reviewers

* Per-PR minutes from the published review model: writer 90 / reviewer 20 in Google Docs, 75 / 15 in Confluence, 120 / 30 by email, 15 / 45 in the GitHub diff, and 10 / 8 in DraftView. Stamped asks nobody, by definition. Hover a square to see what it is.

stamped: 0 hours; diff review: 50 hours; read review: 11 hours

Finding 2: Who actually reviews

Under diff review, 15% of the people you ask never answer. Under read review, 5% don't.

The people who can tell whether the agent got it right are rarely the people who can read a diff. You send 60 review requests a month. In Google Docs, about 9 of them go nowhere.

Where this month's 60 review requests end up
INVITED60ANSWERED · 51WENT SILENT · 9
Invited
60
Answered
51
Went silent
9
  • answered
  • went silent

Showing diff review. Hover a ribbon to isolate it, or switch scenarios above and watch the ribbons move.

* Share of invited non-technical reviewers who never respond, per tool: Google Docs 15%, Confluence 25%, email 30%, the GitHub diff 60%, DraftView 5%. Published defaults from the review model.

diff review: 51 answered and 9 went silent out of 60.

Finding 3: Time to merge

Read review closes the loop in about half a day. Diff review takes days.

The agent's fix is checked against the comment it answers, so a second round costs one glance instead of another review. With reviewers in Google Docs, a PR waits about 2 days on average; in DraftView about 0.5.

Of your 20 PRs this month, how many are still waiting on review, day by day
stampedday 2: 0 waiting
diff reviewday 2: 7.4 waiting
read reviewday 2: 0.4 waiting

* Mean extra days per PR from the review model (Google Docs 2, Confluence 2, email 3, the GitHub diff 4, DraftView 0.5). The shape of the wait is modelled as exponential around that mean; that shape is an assumption. Stamped PRs never wait, because nobody reads them.

On day 2: stamped 0, diff review 7.4, read review 0.4 PRs still waiting.

Finding 4: Evidence

Only read review leaves a record a checkmark can't give.

A green check on a PR is a sentence, not proof. Of your 12 AI-written PRs this month, read review leaves an exportable record for 12: who read it, what changed, how long, against which version. That is the evidence human-oversight rules such as EU AI Act Article 14 ask for.

This month's AI-written PRs, by what they leave behind
Merged with nobody reading it (1 of 12)Merged with nobody reading it (2 of 12)Merged with nobody reading it (3 of 12)Merged with nobody reading it (4 of 12)Merged with nobody reading it (5 of 12)Merged with nobody reading it (6 of 12)Merged with nobody reading it (7 of 12)Merged with nobody reading it (8 of 12)Merged with nobody reading it (9 of 12)Merged with nobody reading it (10 of 12)Merged with nobody reading it (11 of 12)Merged with nobody reading it (12 of 12)
Read, but the only record is a checkmark (1 of 12)Read, but the only record is a checkmark (2 of 12)Read, but the only record is a checkmark (3 of 12)Read, but the only record is a checkmark (4 of 12)Read, but the only record is a checkmark (5 of 12)Read, but the only record is a checkmark (6 of 12)Read, but the only record is a checkmark (7 of 12)Read, but the only record is a checkmark (8 of 12)Read, but the only record is a checkmark (9 of 12)Read, but the only record is a checkmark (10 of 12)Read, but the only record is a checkmark (11 of 12)Read, but the only record is a checkmark (12 of 12)
Read, with an exportable record (1 of 12)Read, with an exportable record (2 of 12)Read, with an exportable record (3 of 12)Read, with an exportable record (4 of 12)Read, with an exportable record (5 of 12)Read, with an exportable record (6 of 12)Read, with an exportable record (7 of 12)Read, with an exportable record (8 of 12)Read, with an exportable record (9 of 12)Read, with an exportable record (10 of 12)Read, with an exportable record (11 of 12)Read, with an exportable record (12 of 12)
  • read, with a record
  • read, checkmark only
  • merged unread

* A PR counts as read when at least one invited reviewer responds, using each tool's published dropout. The record is the sign-off and audit trail DraftView keeps; GitHub keeps the approval.

stamped: 0 with a record, 0 with a checkmark only, 12 unread; diff review: 0 with a record, 12 with a checkmark only, 0 unread; read review: 12 with a record, 0 with a checkmark only, 0 unread

Oversight record · PR #1284sample

  1. Opened

  2. Invited

  3. Commented

  4. Fix verified

  5. Signed off

  6. Exported

Markdown records come with every plan. On Governance, exports are sealed JSON you can check with Verify a record in the Oversight tab, and an org-wide ledger covers pull requests and doc reviews.

More on this in how to audit and prove human review of AI-generated docs and why publicly accountable AI writing needs a record.

Chapter 5 · new, in preview

And the docs that are already on main?

Everything so far starts with a pull request. A lot of documentation work doesn't: a page on main that has gone stale, a getting-started guide that needs fresh eyes before a launch, a policy page Legal checks every quarter. The people who would catch the problems have no way in, so their feedback lands in Slack and a Google Doc copy and half of it gets lost.

Doc reviews start from the files instead of a PR. Git stays the source of truth: the review is a temporary workspace that ends in one pull request.

Doc reviews in DraftView, with reviewers who have no GitHub account. Walkthrough video.
Read the doc reviews launch postHow the review queue keeps up with AI PRs

The outcome is not predetermined.

What a month of doc PRs looks like depends on who is asked to read them, whether they can, and whether anyone checks the agent's answer. Those are choices, and they are cheaper to change than they look.

DraftView never merges anything. It sits on top of GitHub, adds a review layer you can remove, and leaves the content, the comments, and the merge button where they are. The one thing it keeps that GitHub doesn't produce is the record.

A sample month, in one card

20 doc PRs, 12 by AI agents, under diff review: 50 people-hours, 9 silent requests, and 0 AI PRs on the record.

stampeddiff reviewread review
People-hours0 h50 h11 h
Requests that go silent093
Days a PR waits020.5
AI PRs with a record0 of 120 of 1212 of 12

stamped: People-hours 0 h, Requests that go silent 0, Days a PR waits 0, AI PRs with a record 0 of 12. diff review: People-hours 50 h, Requests that go silent 9, Days a PR waits 2, AI PRs with a record 0 of 12. read review: People-hours 11 h, Requests that go silent 3, Days a PR waits 0.5, AI PRs with a record 12 of 12

Connect a repo, or try it on a public PR.

Signing in shares your GitHub name and email. DraftView sees a repository only after you install it there. Reviewers never need an account.

Sign in with GitHubTry on a public PR

Keep reading

What else is new

About this model
v1.0 of the DraftView review model · October 2026

Assumptions. Writer minutes, reviewer minutes, extra days, and reviewer dropout per tool are the published defaults of the cost of docs drift calculator, which explains where each comes from. The AI share is yours. A PR counts as read when at least one reviewer responds, with reviewers treated as independent. Waits are modelled as exponential around the published mean. stamped is a definition: nobody is asked.

Limits. The model does not measure doc quality, does not follow individual PRs or people, leaves engineering review out because it is the same in every scenario, and does not price the cost of a wrong page shipping. The PR, the people, and the oversight record shown are illustrations. We will revise the model as teams using it tell us where it is wrong.

Credits. Written and built by the DraftView team. Any remaining errors are ours; tell us at hello@draftview.app.

A shared estimate lives in its link: the four numbers and the scenario are in the URL.