Craft
Reviewing an AI-Drafted PRD: What to Check First
A generated PRD fails differently from a human one. Five checks to run first: invented baselines, fake evidence, generic personas, symmetric scope, exclusions.
A PRD written by a person is rough where the thinking is incomplete. The vague paragraph, the section that trails off, the metric with a question mark next to it. That roughness is useful. It tells a reviewer where to look.
A PRD written by a model is evenly smooth. The section nobody thought about reads exactly as well as the one somebody argued over for a week. So the gaps do not announce themselves, and a review that reads top to bottom for quality will pass the draft, because quality of prose is the one thing it reliably has.
This post is about that situation: the model is the author and you are the reviewer. It is a different job from using AI to review a spec, and different again from choosing a generator by testing it on a brief you already know. Here you have a draft in front of you, and the question is what to check first.
The answer: check for what was invented before you check for what is missing.
Step zero: get the input
Before reading the draft, find what produced it. The brief, the prompt, the notes, the transcript.
Everything in the draft that does not trace back to that input was supplied by the model. Some of it will be reasonable. None of it was decided. Until someone confirms it, treat it as an assumption, however confident it sounds.
If the input is not available, that is your first finding. A generated draft with no recorded input cannot be reviewed for invention at all, only for style.
The five checks, in order
1 · Invented baselines and targets. List every number in the document: targets, baselines, limits, timeouts, percentages. For each, ask where it came from. A target with an invented baseline is worse than a target with none, because it looks like a decision and somebody will build to it.
2 · Fabricated evidence. "Users frequently report frustration with the current flow." "Support data shows a sharp rise in related tickets." "Research suggests teams prefer bulk actions." Each sounds sourced. Ask for the source. A model that has no evidence will still write the sentence evidence usually goes in, and a reviewer can see that research was cited but not whether it says what the spec claims. Delete what you cannot trace rather than softening it.
3 · Generic personas. "Maya, a busy operations manager who values efficiency." She could belong to any product, which is the tell. A persona with no detail you could only know from your own users is decoration. Replace it with the actual segment you have data on, or cut it. Generic personas are one of the signs of a spec written without your context.
4 · Suspiciously symmetric scope. Three goals, three non-goals, three phases of similar length. Every "must have" list the same size as the "should have" list. Real scope is lumpy, because it was argued over: one hard cut that cost someone something, one requirement that grew because an engineer pushed back. Balance is what pattern-completion looks like. Ask which line someone fought for. If the answer is none, nobody has made the decisions yet.
5 · Missing or boilerplate exclusions. "Out of scope: mobile, internationalisation, admin tooling." Things nobody proposed, excluded at no cost. A real exclusion is something somebody wanted and did not get, and it is the line that prevents the scope fight after approval. A generated draft rarely knows what anyone wanted.
| Signal | What it looks like | What to ask |
|---|---|---|
| Invented numbers | Precise targets and limits, no source | Where did this come from? |
| Fabricated evidence | "Users report", "data shows", "research suggests" | Show me the source |
| Generic persona | A name, a job title, a trait | What do we know that only our users could tell us? |
| Symmetric scope | Balanced lists of equal length | Which line did someone fight for? |
| Boilerplate exclusions | Things nobody proposed | Who wanted this and did not get it? |
What it looks like in a draft
An illustration. A fragment from a generated draft for team invitations, with the five checks applied:
Problem. Teams struggle to onboard new members efficiently. User research shows invitation friction is a top-three churn driver. Persona. Priya, a team lead at a fast-growing startup, needs to add teammates quickly. Goal. Increase invitation completion from 54% to 75% within one quarter. Out of scope. Mobile app, SSO, internationalisation.
Four sentences, four findings. The "top-three churn driver" claim needs a study that may not exist. The 54% baseline needs a query someone actually ran. Priya could be anyone's persona. And none of the exclusions was something a customer asked for, so the list protects nothing.
Fixed, the same fragment is shorter and less impressive: Baseline: [TBD: invitation completion rate, query owner Dewi, by Friday]. Evidence: 14 support tickets last quarter mention expired invite links (linked). That second version can be wrong, which is exactly what makes it reviewable.
Then run the ordinary review
Once the invented content is out, what remains is the usual review: missing states, untestable criteria, unwritten dependencies. That part is mechanical, and a checklist or an AI reviewer handles it well.
The order matters. A mechanical review run first, on a draft full of invented numbers, will dutifully confirm that the invented numbers are testable. It cannot know which numbers you supplied. Only the person who knows what went into the draft can check that.
Why fluent drafts slip through
Skimming checks for fluency, and fluency is now free. As the briefing on the verification tax put it, a spec can be correctly sectioned, confident throughout and contain no decision at all. Reviewing generated work is a reading skill, and it is the skill most teams were never taught.
If you generated the draft yourself, it is harder. You remember what you meant, so you read your intent into sentences the model wrote. Review it a day later, against the brief rather than against your memory. And if you drafted it in a general assistant, the habit of making it mark its assumptions before drafting saves most of this work.
Less to undo at the start
Most of this review is undoing invention. The cheaper fix is a generator that invents less. Ours scores the brief on six dimensions before it drafts, asks about what is missing, and reads your workspace's past decisions and standards instead of starting blank. That is the design intent, not a guarantee. Run the five checks on its drafts too.
FAQ
How do you review an AI-written PRD? Get the input first, check for invention before omission, then run the ordinary review.
What does it usually get wrong? It fills gaps with plausible numbers, evidence, personas and scope, in the same voice as your facts.
Is this AI review? No. The model wrote it; a person who knows the input reviews it.
What do I do with an invented claim? Mark it as an unknown with a reason and a date, or delete it.