Planning AI Projects: The Four-Document Pipeline
The fastest way to derail an AI-assisted project is to hand the model a vague brief and watch it build confidently in the wrong direction for two hours. The four-document pipeline isn't process for its own sake — it's the structure that keeps AI anchored to what was actually decided.
On this page
Why One Document Isn't Enough
Most projects fail not because of bad code but because of bad plans handed to AI. If the specification is ambiguous, the AI fills in the gaps with plausible guesses — and those guesses compound. A single planning document collapses four different types of thinking into one place, which means each type contaminates the others.
Separating planning into distinct documents forces clarity: the PRD answers what and why, research answers what exists, the plan answers how, and the roadmap answers what next. Collapse them and you get a plan built on assumptions instead of facts.
The Four Documents
PRD (Product Requirements Document): the what and why. Immutable once finalized. Captures what you and the team agreed to build. 'DO NOT MODIFY' at the top signals to both humans and AI that this is the source of truth — not the document you're currently writing, the one you agreed to.
Research doc: what currently exists, no opinions. The AI documents your codebase, existing APIs, and patterns before forming any views. The research step asks only what files are involved, how they connect, and what patterns are in use. Opinions belong in the plan doc, not the research doc.
Plan doc: the what and how. A living document. Tells a human how to think about the work. This is where the AI's reasoning about approach, tradeoffs, and architecture goes.
Roadmap: the checklist. Tells the AI what to do next, phase by phase. Date-prefix it and archive it when done. Future you and future AI can see the history without guessing which document was live.
Skipping a planning document saves time on the document and loses it three times over on the rebuild.
The PRD Is Immutable
Once the PRD is finalized, it doesn't change silently. If requirements shift, you version the PRD. This single rule stops the feature list from expanding mid-sprint and keeps the AI anchored to what was actually agreed.
Without this rule, a cooperative AI will build three features you didn't ask for because they sounded related to what you did ask for. The PRD is the contract. Treat it like one.
The Two-Folder Structure
aiDocs/ is tracked by git. Permanent project knowledge lives here: context.md (a bookshelf of one-line pointers to referenced docs), PRD, architecture decisions, and coding style. AI reads it every session.
ai/ is gitignored. Working process artifacts live here: roadmaps, research notes, session-specific instructions. Gitignoring it keeps session artifacts out of version control and keeps the permanent decisions separate from the work in progress.
Be Ruthless About MVP Scope
The MVP is not the small version of the whole product. It's the minimal version that lets a real user validate the core hypothesis. Every feature that doesn't trace directly back to the PRD problem statement doesn't belong in this sprint.
The pressure test: 'I have X weeks with Y developers — is this realistic?' That question does the same work a skeptical senior engineer would do. Run it before you commit to a scope. The answer is almost always that you're underestimating integration, testing, and the last 20%.
Want to apply these frameworks to your business?