PRD for AI Coding: Write the First Cycle, Not the Whole Book

You spent a Sunday on it. Fourteen pages: personas, a feature list, a data model, a launch plan. You pasted it into your assistant on Monday, and the first week went beautifully.

By week three you have dropped the marketplace idea, because two early users told you they only wanted the booking part. The document still describes a marketplace. Your assistant reads it at the start of every session and keeps quietly building toward one.

Why the long version goes wrong

The PRD, or product requirements document, comes from teams where writing code was the expensive part. A product manager spent weeks getting it right, because a wrong paragraph could cost a month of engineering.

An AI build flips that. Code is cheap and quick, so you learn by building, and what you learn changes the plan. Most of a long PRD written before the first build is guesses. Some of them are good guesses. You cannot tell which yet.

Your assistant cannot tell either. It gives page nine the same weight as page one, and it has no way to know you stopped believing in page nine on Thursday. A human engineer would ask. A fresh session reads what is written and gets on with it.

What the usual templates get right

The guides that rank for this search mostly agree, and they are right about a lot. Write in plain language. Keep the PRD in a file your assistant can reread, not a chat message that scrolls away. Spell out what is out of scope, because an assistant with no boundary invents features. Give every requirement a check you can actually run.

Where they stop is time. The templates run to six to nine sections and ask you to fill them all in before anything is built. One calls the PRD a living guide, which is the right instinct. None of them say what happens to it the day you change your mind, which is the day that decides whether it helps or hurts.

A short PRD in two layers

Split the document by how often each part should change.

The direction. Half a page, rewritten rarely. 1. The problem, in two sentences, from the user's side. 2. Who it is for, named as specifically as you can. 3. What you are deliberately not building yet. 4. The decisions you have already made, each with one line on why. 5. Open questions, written as questions so nobody mistakes them for requirements.

The first cycle. This is the only part written in detail. Pick a small batch of tasks, usually 3 to 8, that puts something real in front of you. For each one, write the goal, what is out of scope for that task, and how you will check it is done. If an assistant with no history on the project could pick up a task and build it correctly, it is written well enough. We call that a build handoff.

Write the first cycle in detail. Write everything after it as questions.

You are not skipping the planning. You are refusing to plan the parts you have not learned anything about yet.

Changing it is the job working

When the first cycle is done, read what came back before you write the next one. Something took twice as long as expected. Something you were sure users needed turned out not to matter. That is the PRD learning, and the reason to keep it short.

When a decision changes, do not just edit the old line. Write the new one underneath with its reason, and leave the old one visible. A fresh session that finds “marketplace” deleted with no explanation may well put it back. One that reads “dropped the marketplace on 14 March, users only wanted booking” will not. More on why the reasoning matters in Architecture Decision Records Do Not Survive AI Speed.

Changing your mind about something this big is not indecision. It is the idea growing past what you could see on the Sunday you wrote it down.

Where PAPI fits

You can run all of this with one markdown file and some discipline. The catch is that a file just sits there. Files describe. They don't decide. Nothing checks the finished work against them, and they never reorder the backlog when reality changes.

PAPI is a project manager that works inside your AI chat, and it keeps the same two layers as cycles and decisions. Each task gets a build handoff. Every build files a report on actual effort and surprises, and the next plan reads those reports first. Decisions keep their reasoning and get superseded, never overwritten. PAPI does not write code; your assistant still does the building. If you want a finished PRD turned into a task list, Taskmaster does that well; see PAPI vs Taskmaster.

The honest version

A short PRD is not always the right call. If you are paying an agency a fixed price, they need the long version, because the document is the contract. Anything a regulator will read needs it too.

And if you are still exploring, still throwing away most of what you build, skip the PRD for now. A paragraph about the problem is enough until something survives a week.

For everyone in between, write the first cycle and let what it teaches you write the second. Walk one cycle on a demo project, no signup needed.