AI writes PRDs fast — how does a PM review them?

These days I basically don’t write PRDs myself.

Usually I first discuss the requirements, scope, flows and product rules with AI, then have AI organize them into a document for the phase. When requirements change later, I keep having AI revise it.

Generating a PRD is no longer the problem.

What really troubles me is:

AI generates too fast and too much, and I can’t necessarily review it all properly.

A document can become well structured and detailed in a very short time. Background, goals, flows, edge cases, acceptance criteria — it seems to have everything.

But the longer the document, the harder it is to keep the same level of attention.

Sometimes I read the first part carefully and gradually slip into skimming. Sometimes, because the requirements have been discussed over several rounds, I subconsciously feel: this was all organized from our earlier conversations, so it can’t have drifted too far.

The real problems often only show up during development:

• one rule conflicts with another somewhere else;
• two states have no way to transition between them;
• AI decided on its own how to handle something in order to complete a flow;
• an idea that was only provisional got written up as a formal requirement;
• the scope slowly grew while things were being fleshed out;
• the acceptance criteria look complete but can’t actually tell you whether something passes.

You can still change things at that point, of course.

But what’s affected is no longer just one document; it may include the design, the code, the tests, and everything else generated from this PRD.

So what I care about now isn’t how to get AI to write a more complete PRD, but:

once PRDs are mainly generated by AI, how should a PM review them to really find the problems?

AI has separated writing from thinking

When PMs wrote PRDs themselves, writing and thinking often happened together.

How a flow goes, how a rule is phrased — usually already thought through once in the act of writing.

Now AI can expand a discussion straight into a full document. Organizing, filling in and expressing have all gotten much faster, but it also brings a change:

the document being written doesn’t mean every judgment in it has been carefully confirmed.

AI-generated content has another trait that easily lowers your guard: it usually reads very smoothly.

There aren’t many obvious grammatical or structural problems. More often, a local judgment is actually inaccurate, but placed inside a complete paragraph, it still looks quite reasonable.

So review easily turns into:

• is the structure tidy;
• does it read smoothly;
• does the content look complete.

Rather than:

• should the product really behave this way?
• is there an extra rule here we never decided on?
• would development read this sentence to mean something else?

You can’t simply decide which sections to read and which to skip

The most direct fix seems to be reading only the key parts carefully:

• scope;
• product rules;
• states and permissions;
• error flows;
• acceptance criteria.

Background, explanations and examples can be skimmed.

But there’s an unavoidable problem:

before you’ve read it, how do you know where the new decisions were written?

AI might add a line in an ordinary flow description:

if generation fails, the system will automatically retry and overwrite the original result with the new one.

It looks like just error handling, but it actually decides:

• whether extra calls are made;
• whether the original result is kept;
• whether users know the system retried;
• whether it keeps going after repeated failures;
• whether users can recover the earlier content.

So there’s no completely safe “skip list.”

All new content needs to be scanned at least once. But that doesn’t mean you have to reread word for word from page one every time either.

The more realistic approach is to first surface the places that genuinely need the PM’s judgment.

AI shouldn’t only deliver a full PRD

If after every change AI outputs a complete document again, the PM still has to find for themselves:

• what changed;
• what’s new;
• what’s just been reworded;
• where new product decisions have appeared.

The more often the document is updated, the harder that is to keep up.

So a complete PRD delivery should contain at least two parts.

Part one: the full PRD for the current version

It holds the requirements, for product, design, development and testing to keep using.

Part two: a review summary for this round

It doesn’t need to summarize the whole document again; it only needs to say:

• what was added this time;
• what was changed or deleted;
• which flows, states and rules are affected;
• which content comes from decisions already confirmed;
• which AI proposed to complete a flow;
• which is still only an assumption;
• which questions are still unanswered.

The full PRD is the working document.

The review summary tells the PM where to look first this round.

Otherwise, if every change requires rereading the whole PRD, you easily end up relying on “it should be fine.”

Decisions, assumptions and suggestions need to be clearly separated

Another reason AI-generated PRDs are hard to review is that content of different kinds is often written in the same confident tone.

For example:

• users can save three résumés;
• users may need to save several résumés;
• to limit the scope of phase one, users can save only three résumés for now.

These may respectively be:

• a confirmed product rule;
• an unvalidated assumption about users;
• a trade-off for the current phase.

But if they’re all laid out flat in the body, design and development may read them all as “formal requirements.”

So I want AI, when generating documents, to clearly separate:

• confirmed decisions
• provisional plans
• assumptions to validate
• unresolved questions
• AI’s own suggestions

What exactly they’re called doesn’t matter.

What matters is that content AI filled in doesn’t automatically become a confirmed requirement just because it made it into the PRD.

Building a simple demo from the PRD is a very effective way to review

Some problems really are hard to spot from text alone.

A flow may read smoothly in a document, but once it’s put on a screen, problems show up immediately:

• users don’t know what to do next;
• a page is missing a necessary state;
• some operation actually needs confirmation;
• two states can’t be told apart on screen;
• after an error, users have no way to continue;
• a rule that seemed simple actually needs a lot of extra interaction.

So once there’s a PRD for a phase, I think a very effective practice is:

have AI quickly generate a simple demo from the PRD, then review the demo and the document together.

The demo doesn’t need complete design, nor production-quality code.

Its job is to turn the requirements in the text into something you can click through, move between states and watch change, helping the PM, design and development confirm that everyone understands the same product.

When reviewing, you can pick a few concrete scenarios:

• how users start a task;
• how they complete it normally;
• what happens when data is missing;
• how it handles AI being unable to give a reliable result;
• whether users can cancel, retry or go back;
• what the page shows after a state changes;
• whether users can continue after refreshing or being interrupted.

Gaps that are hard to notice in a PRD are usually much more obvious in a demo.

But a demo can’t replace the PRD

A demo is great for checking whether flows, interactions and states make sense, but it can’t fully express every product rule.

For example:

• permission checks;
• data requirements;
• boundary conditions;
• errors that are hard to show on screen;
• external dependencies;
• acceptance criteria;
• later logic that hasn’t been implemented yet.

A demo can also look smooth while hiding that the rules behind it are incomplete.

So the better approach isn’t “once the demo’s done, no need to read the PRD carefully,” but:

use the demo to check whether the product really works end to end, and the PRD to check whether rules, boundaries and errors are spelled out.

The two should check each other.

If the demo shows behavior the PRD never described, go back to the document and confirm: was this a temporary choice during implementation, or should it formally become a product rule?

If the PRD states an important rule but you can’t find any corresponding feedback or action in the demo, keep adjusting too.

Different content can be reviewed at different depths

Once you know what changed this round, not everything needs the same amount of time.

What must be confirmed carefully

Anything that adds or changes product behavior needs to be read item by item:

• scope and non-goals;
• product rules;
• states and permissions;
• conditions for automation;
• irreversible operations;
• failure and recovery;
• external dependencies;
• acceptance criteria;
• key assumptions.

What needs confirming here isn’t whether the wording is reasonable, but:

• what users will actually experience;
• how development will interpret it;
• whether it conflicts with other rules;
• whether things can be recovered after an error;
• whether this is a decision that has actually been made.

What can be checked quickly

If content that’s already confirmed is just being reorganized, you can read faster:

• restructuring the document;
• unifying terminology;
• adding explanations and examples;
• turning confirmed flows into tables;
• generating first drafts of acceptance criteria from the rules.

The focus of a quick check is whether AI changed the original meaning while rewriting, or added new judgments along the way.

What can be spot-checked

Formatting and mechanical expansion can be spot-checked:

• renumbering;
• converting tables;
• identical structures for repeated modules;
• test cases generated in a fixed format.

Provided AI has clearly stated what it changed, the generation rules are fairly stable, and the consequences of errors are low.

If you don’t even know exactly what it changed, it’s hard to feel truly comfortable reviewing lightly or spot-checking.

For small changes, don’t regenerate the whole PRD

When changing one state, one rule or one field, having AI regenerate the whole PRD seems convenient.

But a full rewrite also creates new review work:

• content you never asked to change may change along with it;
• both the old and new versions are complete, which makes the differences harder to see;
• the PM has to recheck lots of content that was already confirmed.

A safer way is to:

• change only the affected parts;
• list the differences before and after;
• explain which flows and rules are affected in turn;
• record major decisions in the decision log at the same time;
• not re-derive confirmed content every time.

The full PRD still needs maintaining, of course, but updating it shouldn’t mean regenerating it every time.

The efficiency of AI-generated PRDs can’t be judged by generation speed alone

Once PRDs are mainly written by AI, generating content is no longer the bottleneck.

The new bottleneck is whether a person can reliably spot the changes, assumptions and problems in them.

For me, an AI PRD that’s easier to review should at least:

• make this round’s changes visible;
• keep decisions, assumptions and suggestions apart;
• mark what AI filled in on its own;
• let high-risk changes be located quickly;
• support generating a simple demo from the PRD, to check that flows and understanding match;
• write problems found in the demo back into the document;
• not rewrite already confirmed content in every update.

AI has already solved “how to generate a PRD quickly.”

What really needs solving now is how to make sure people can review it, and actually find the problems.