Write Docs Before Code: Four Key Documents for AI Product Development

Most developers, when handed a product idea, reach for Cursor and start writing code. But if the goal is an iterable, maintainable product, there's far more to prepare before opening Cursor than you might imagine. One YouTube creator's approach is worth studying: before writing a single line of code, have AI generate four documents — an AI architecture context, a system design document, a PRD with embedded build prompts, and a design document.

The core principle behind these four documents comes down to one thing: don't let AI guess product decisions.

Don't Let AI Guess: Product Definition Must Be Done Before Writing Code

Throughout the video, the creator repeatedly emphasizes a single principle: "I don't let it guess on the product." This isn't a slogan — it's a hard constraint that runs through the entire process.

Take the "AI readiness score" feature as an example. When the creator first had AI process this concept, AI could have simply "guessed" what it was — maybe a percentage, maybe a tier, maybe a skills matrix. But the creator chose to define it explicitly in the document: a score from 0 to 100, paired with named tiers, showing the job title, three core strengths on a card, and updating dynamically as users adopt AI.

Had he left that definition to AI's guesswork, the final product might have drifted completely from expectations. This is precisely the core value of documentation in AI-assisted development: keep product decision-making firmly in human hands, and let AI execute rather than define.

PRD: A Complete Blueprint from Goals to Build Prompts

After enabling the security hardening skill, the PRD AI returned came in a modular structure covering the following:

• Goals and non-goals: what the product should do — and equally important, what it shouldn't
• Use cases and success metrics: who uses it, in what scenarios, and how success is measured
• Product principles: six principles written down before any interface existed
• An 11-step user flow: the complete path from entering the product to completing the core task
• Scoring mechanism and share cards: the specific behavioral definitions for the feature
• Data model and endpoints: the underlying structure for technical implementation
• Risk list: where things might go wrong

The most noteworthy part of the PRD is the 17 build prompts at the end. Each one is listed in order: the files to create, the tests to write, and the definition of "done." This means Cursor never needs to guess what to do next — it just executes in sequence.

The creator specifically notes that these 17 build prompts make AI coding far more deterministic, because every step has clear inputs and outputs.

PRD (Product Requirements Document) is a standard document in product development, traditionally written by product managers to align a team's understanding of a product's features, scope, and priorities. In AI-assisted development, the role of the PRD has fundamentally changed: it's no longer just a communication document for a human team, but becomes structured input fed directly to AI coding tools.

Traditional PRDs tend to focus on describing "what to do" and "why do it," maintaining a certain abstraction around "how to do it" to leave room for engineers. But AI coding tools lack the domain common sense and product intuition of human engineers — any information not made explicit in the document may be "freely improvised." That's why the PRD in this article is expanded into a "blueprint" — not only containing goals, use cases, data models, and other conventional content, but also appending build prompts to be executed in sequence. This hybrid form of "PRD + build prompts" essentially merges product definition with execution instructions, giving AI a definite input and acceptance criteria at every step.

Six Product Principles: Set Before the First Screen Appears

The most illuminating part of the PRD isn't the feature list or the data model, but the six product principles written down "before any screen existed":

1. Honesty first — no false comfort and no deliberate anxiety — highly relevant to the credibility of AI-related products
2. Quality before cost — when evaluating recommendations, don't lower quality standards just because something is cheaper
3. Estimates, not predictions — all numbers provided are estimates, not packaged as precise predictions
4. Recommendations always visible — users can see the system's suggestions, not a black box
5. Free resources first — when recommending learning paths, free options come first
6. Privacy by default + clean premium feel — two foundational experience guidelines for the product

These six principles translate into many concrete decisions at the feature level. For example, "honesty first" means scores won't be inflated just to make users happy; "free resources first" means the ranking logic for recommended courses has a clear value orientation. Without establishing these principles before writing code, every subsequent feature decision risks becoming a one-off "off-the-cuff call."

Design System: From Design Document to Reusable Components

The design document ultimately became a complete design system, including:

• Design tokens: foundational variables like color, spacing, and border radius
• Typography: a complete system of fonts, sizes, and line heights
• Color system: navy blue paired with a white background, conveying a "premium, clean, professional" visual tone
• Component library: which components make up each screen, and each component's states and behaviors

The creator was satisfied with the result — "everything is defined" — with the only gap being image assets, which were also updated after asking AI to fill them in.

One direct output of this design system is the share cards. Users can export vertical cards showcasing their AI readiness score and share them on social platforms. The cards contain the score, the named tier, the job title, and three strengths — content that comes directly from definitions in the PRD rather than ad-hoc decisions made during the design phase.

The value of a design system in AI-assisted development is especially clear: once every color, spacing value, and component state is explicitly defined, the visual consistency of Cursor-generated code improves dramatically.

Design Tokens are the most foundational atomic layer of a design system, referring to abstracting visual decisions like color, spacing, font size, border radius, and shadow into named variables. For example, color-primary might map to navy blue #1B2A4A, and spacing-md might map to 16px. The core value of tokens lies in a "single source of truth": when you need to adjust the brand color, you only modify the token definition, and all components referencing that token update automatically.

In AI-assisted development, the role of design tokens is amplified further. When Cursor generates code, if tokens are explicitly defined, AI will reference var(--color-primary) directly rather than hardcoding #1B2A4A, ensuring visual consistency; if tokens are missing, AI tends to duplicate specific values across different files, making later changes difficult and prone to visual inconsistency. Similarly, the explicit definition of typography and the component library reduces AI's "guessing space," bringing generated front-end code closer to the output quality of a professional designer.

Roadmap: 30 Tasks and the Boundary of P0

The roadmap came back as a table with over 30 items, each tagged along three dimensions: area, priority, and size. The P0 items constitute Version 1, and everything else falls into subsequent versions.

The creator has a clear positioning for Version 1: "Version 1 is the first step, not the product itself." This distinction matters. Many teams plan Version 1 as a "complete product," causing the P0 scope to balloon until they can neither ship on schedule nor get clear user feedback.

The roadmap also includes a noteworthy design: users can raise their AI readiness score by completing foundational free courses, building real applications, and uploading them for review. When the score rises from 30 to 70 or 75, the system records this improvement trajectory, and users can share it with employers. This forms a closed loop of "learn — certify — improve — share," turning the score from a static number into a dynamic record of growth.

P0 (Priority 0) is the highest level in a product's priority system, typically representing tasks that "must be completed before launch, otherwise the product can't ship or its core value doesn't hold." Corresponding levels include P1 (important but deferrable), P2 (nice to have), and so on. Defining P0 directly determines the scope boundary of Version 1.

In practice, P0 inflation is one of the most common causes of product delays — every feature looks "indispensable," and the launch keeps getting pushed back. In this article, the creator explicitly defines Version 1 as "the first step, not the product itself," a deliberate scope-constraint strategy. By marking only a few of the 30-plus tasks as P0 and deferring the rest to later versions, the team can quickly get a runnable, feedback-ready minimal product rather than discovering a misalignment of direction after a long build. This approach aligns with the MVP (Minimum Viable Product) philosophy from lean startup, but places greater emphasis on locking in scope ahead of time through documentation in AI-assisted development, preventing AI from "filling in" unrequested features during coding.

Who Is This Process For?

This approach is best suited for the following scenarios:

• You have a relatively complex product idea involving multiple feature modules and user roles
• You plan to use AI coding tools (like Cursor) to accelerate development
• You want the product to remain clearly structured and consistent in its decisions across many iterations

For small prototypes meant for quick validation, this process may be too heavy. But for a product you intend to build from zero to one and keep iterating on, spending time to get these four documents right before writing the first line of code saves the cost of repeated rework and product direction swings down the line.

In the next episode, the creator will take all the documents into Cursor's Agent mode, execute the build prompts one by one, and verify the tests. That's when the quality of the documentation truly gets tested.

One-line Summary

Let AI generate four key documents before writing code, ensuring product decisions are made by humans and AI only executes.

Paragraph Summary

This article covers a YouTube creator's four-document practice in AI-assisted development: AI architecture context, system design document, PRD with embedded build prompts, and design document. The core principle is "don't let AI guess product decisions." The PRD contains 17 build prompts arranged in sequence, each specifying files, tests, and completion criteria, making AI coding far more deterministic; six product principles are set before any interface appears, providing a basis for every subsequent feature decision; the design system turns the design document into reusable components and tokens; and the roadmap presents over 30 tasks, with P0 forming Version 1. The creator emphasizes that Version 1 is a first step rather than a complete product. This process suits zero-to-one development of complex product ideas but may be too heavy for small prototypes meant for quick validation.