PRD-first vs prototype-first with AI

There's a live debate in AI product work: when an agent can build almost anything in an hour, why write a requirements document at all? Just have it build the prototype and react to that. The other camp says skipping the spec is how you ship fast, confident, and wrong. Both have a point, and the truth is they're answering different questions.

Here's the honest comparison of PRD-first versus prototype-first, and how to use each instead of picking a side forever.

Two ways to start a feature

When you start a feature with an agent, you can lead with either artifact:

• PRD-first. Write the requirements — what to build, why, the constraints, the definition of done — then build against them.
• Prototype-first. Have the agent build a rough, clickable version now, then react to the real thing and refine from there.

PRD-first decides on paper, then builds. Prototype-first builds, then decides. The right call depends on what you're actually uncertain about.

PRD-first: decide, then build

PRD-first shines when you know what you want and the risk is building it wrong, inconsistently, or with the wrong boundaries. The spec pins down intent so the agent — which will otherwise fill gaps with assumptions — builds the right thing the first time.

It's the stronger choice when the cost of a wrong build is high, when multiple people (or agents) need to align on the same target, or when the feature touches things that are expensive to get wrong. The PRD is cheap insurance against a confident, expensive mistake.

Prototype-first: build, then react

Prototype-first shines when the uncertainty is what to build at all. A document describing a flow invites endless debate — a clickable prototype you can actually use settles questions in minutes. And agents made this cheap — when a working prototype costs an hour, building one is often a faster way to learn than writing another spec.

The product world has noticed: the shift toward prototypes over PRDs is real, because a prototype gives teams something to test immediately rather than another document to read and debate. Progress gets measured by feedback on something real.

Stuart Leo

A PRD gets you agreement on a description. A prototype gets you feedback on the thing itself. When you're unsure what to build, feedback beats agreement.

When each wins

Your biggest uncertainty	Start with
What to build / is it worth it	Prototype — get real feedback fast
How it should work, exactly	Prototype — react to a clickable version
Building it right and consistently	PRD — pin the target before building
High cost of a wrong build	PRD — spec is cheap insurance
Multiple people/agents must align	PRD — one shared source of truth

The deciding question is simple: what am I most unsure about? If it's whether the idea is right, prototype. If it's whether the build will be right, spec.

How C² cascades from PRD but ships fast

The false choice is treating these as permanent rival philosophies. In practice the strongest flow uses both, in sequence: prototype to decide, then spec to build. A quick prototype burns down the "what should this be" uncertainty. Once you know, a tight PRD captures the decision — and in C² that PRD cascades into the scoped briefs an agent builds from, so the real build is rigorous and on-target.

You lose nothing. The prototype gives you speed and feedback up front — the PRD-and-cascade gives you a reliable build after. Prototype-first and PRD-first aren't a fork in the road — they're two stages of the same road.

A PRD decides what's worth building, and a prototype tests whether you were right — good work uses both, in order.

Start here: see what a PRD is and why agents need one, the Cascade from PRD to brief, or read the method.