From Docs to Decisions: Redefining Requirements in AI-Assisted Development

Preface: A Counter-Intuitive Conclusion

When generative AI first appeared, many people's immediate reaction was: "Finally AI can help me write requirements documents and PRDs." But practitioners who have spent years working with models from the earliest versions to today reach the opposite conclusion: In the AI era, the scarce skill is not "writing documents" but "deciding what to do." Requirements definition is shifting from an "organizing and archiving" step to a "decision-making" step. Below I trace how this understanding evolved step by step.

Roadmap: The Full Picture in One Table

Starting Phase: Used early LLMs to auto-generate business flowcharts from email/IM text. Lesson: Organizing prior information (glossaries, premises) directly determines generation accuracy.

Exploration Phase: Used Cursor + Markdown for requirements definition. Lesson: The codebase itself is the best context.

Pilot Phase: Piloted conversational AI in selected teams. Lesson: Knowledge accumulation matters more than rushing to roll out.

Deepening Phase: Introduced AI across the full requirements definition flow. Lesson: Upgrade from "single prompt" to "a mechanism" integrating context, codebase, and accumulated experience.

Finalization Phase: "Skeleton goes to code, requirements go to prompt." Lesson: Explicitly separate "skeleton" and "requirements"; let code carry the skeleton so the team can focus on requirements.

Breakthrough Phase: Built a "zero-day delivery" methodology. Lesson: Requirements definition shifts from "writing docs" to "slicing scope."

Present: Re-understanding the essence of requirements definition. Lesson: It is turning from an "organizing step" into a "decision step."

As the timeline progresses, the topic expands beyond requirements definition into the shape of the entire development process.

Starting Phase | Teaching AI to Read Chat Logs and Draw Flowcharts

The earliest attempts date back several years. The idea was simple: business communication is scattered across emails and IMs; could we feed that directly to an early LLM API to auto-generate business flowcharts?

Reality was harsh. The model couldn't distinguish valid requirements from chatter and digressions; generated flowcharts were often irrelevant.

The turning point that made it usable: First define the glossary, key roles, and basic business assumptions clearly, then let the model generate. Even adding qualitative background context into the prompt caused a qualitative leap in output quality.

This experience left a lasting obsession: The quality of prior information (context) is the starting point of everything. The various "Rule" mechanisms that later evolved in engineering trace their origin here.

Exploration Phase | Using Cursor + Markdown to "Reverse-Query" Requirements from Code

When Cursor appeared, I immediately adopted it for requirements definition. The model was still relatively early, but the key change was: Reference context (glossaries, requirement info) could be pulled directly from the codebase.

This brought a practical benefit: when the system needed incremental enhancements, generating requirement documents became remarkably smooth. Because the code itself carries the most accurate current state, it's faster and less prone to drift than relying on humans to recall and write manually.

A mantra I repeated during this phase: "Extract the codebase correctly, then list necessary information into Markdown."

Lesson: Leveraging the codebase well is critical. This directly led to the later "code indexing" approach.

Pilot Phase | Small-Scale Pilot: Accumulate First, Then Promote

By this stage, generative AI's potential was clear, so we began piloting in some teams. But I didn't rush a company-wide rollout for two reasons:

The "conversational AI + organize context before feeding" playbook was still undergoing trial and error and hadn't solidified into a stable organizational method.

Many team members were skeptical of AI; a full rollout carried too much risk.

So we chose cautious progress: first make it work in a small scope.

During this phase I coined a concept called "Project as Code" : express all project information in Markdown or code as much as possible, and continuously accumulate it. This practice of "managing project information with code" became the foundation for later "reverse-querying requirements from the codebase."

Lessons: Let "evangelist" role members accumulate usage experience first. Compared to rushing promotion, the priority is to accumulate knowledge first (codify it).

Deepening Phase | From "Single Prompt" to "A Mechanism"

Using accumulated experience as the foundation, we officially entered the "full-process AI for requirements definition" stage, running three tracks in parallel:

Reverse-query from codebase, auto-generate documents. Starting from existing code, generate specifications and business flow documents — faster than manual writing and less likely to deviate from implementation.

Use UI generation AI for prototypes first, then reverse-engineer requirements. Tools like v0 create interactive UI prototypes to align understanding, then solidify requirements. "Show the customer a working thing first" eliminates cognitive gaps early.

Start requirements definition at the pre-sales stage. Spin up the requirements definition flywheel during business negotiations, raising the "resolution" of requirements in one go before signing.

Lesson: The real productivity lever isn't a magical prompt, but integrating context, codebase, and accumulated experience into a "mechanism" embedded in the requirements definition process.

Finalization Phase | "Skeleton Is Code, Requirements Are Prompt"

After continuous practice, the next core question became: "How should development itself be driven?" — i.e., finalize a methodology so the entire chain from requirements definition to implementation can be run stably by the whole team.

The unavoidable core problem: How can anyone get consistent output?

The core philosophy I established: "Skeleton goes to code context, requirements go to prompt."

Compared to pure "Vibe Coding" that generates from scratch via natural language instructions, using a skeleton codebase as the foundation yields more stable generated code quality and higher team learning efficiency. The skeleton is read from existing code; requirements are passed via prompt — years of accumulation converge here into a clear form.

The development process itself evolved into what I call "AI-Driven Agile" , a hybrid mode:

Rhythm: Phase-based progression like Agile.

Individual development: Like a "high-speed waterfall with heavy design" — make design thick.

The core purpose is to minimize rework risk caused by "generating code while requirements/specs are still vague" — so deliberately make the requirements definition and design phases heavier.

Lesson: Let code carry the "skeleton" so the team can focus energy on "requirements."

Breakthrough Phase | "Zero-Day Delivery" — Start Requirements Talk from a Running System

As AI makes development faster, the bottleneck moves further upstream.

The next step is a methodology called "Zero-Day Delivery (0-Day Import)" . Its approach is unconventional: At project kickoff, deploy the skeleton code to a test environment first, then conduct requirements definition and design with the premise that "the system is already running."

Documents? Just diffs on top of the "skeleton code version template."

Meetings demo runnable things whenever possible, aligning understanding while watching.

Requirements definition is redefined as "slicing scope (slicing Issues)" — breaking tasks down to a granularity where "one development cycle completes within 1 hour."

Moreover, this "scope slicing" work is best handled by business-side people.

The key shift: the protagonist of requirements definition changes from "writing documents" to "slicing the right scope." The faster AI makes development, the more the upstream ability to define "what to do and at what granularity" becomes the bottleneck of the whole chain.

Lesson: AI makes development faster, so the bottleneck moves further upstream. The role of requirements definition shifts from "document writing" to "scope design."

Present: Requirements Definition Is Turning from "Organizing" into "Deciding"

Requirements definition moves from "organizing" to "deciding."

After refining this method for years, I increasingly realize: The "meaning" of the requirements definition step itself has changed.

When AI can already handle organizing and documenting at high speed, the core left for humans is one thing: Deciding what to do. Requirements definition thus quietly shifts from an "organizing step" to a "decision step."

Interestingly, even though today's development process centers on coding agents like Claude Code, the information organization and consensus-building in the requirements definition and high-level design phases still cannot be fully handed over to them. Reasons include: Markdown visibility, approval process (instruction history) visualization, etc., are not fully compatible with the "hard requirements" of traditional waterfall processes. In other words, the "decision" link remains firmly on the human side.

Furthermore, this "decision" is no longer the monopoly of a few experts. Business owners, operators, internal IT — everyone is pushed into the position of "defining what to do."

Requirements definition and design are becoming a step that needs to be "democratized." Therefore, every obstacle on this road is worth dismantling one by one.

I increasingly believe: Tools should exist like air. Let users feel no cost, no lock-in, so they can put all attention on the decision of "what to do."

After years of practice, the final answer isn't "we need to pile on more mechanisms and experience," but — treat those mechanisms and experience as "already discussed past," freeing up a patch of soil where people can focus on true value creation.

This section's insight is the conclusion of the whole article: Generative AI's job is not "generating documents" but "building a mechanism that collects the right context and slices the right scope." Requirements definition has already turned from an "organizing step" into a "decision step."

Summary: The Continuous Thread

Looking back, each phase's lesson forms a continuous thread:

Context is the starting point of everything. To extract precision from text mixed with chatter, organizing glossaries, premises, and business assumptions is indispensable (later the "Rule" concept).

The codebase is the best context. Instead of relying on human recall, reverse-query from existing code — faster and more accurate (later code indexing, and "skeleton is code context").

Knowledge relies on accumulation, not promotion. In a skeptical atmosphere, centering on evangelists and accumulating experience into prompt sets is what actually worked.

The faster AI, the further upstream the bottleneck moves. After development is accelerated, the role of requirements definition shifts from "document writing" to "scope design."

Don't treat generative AI as a "magic box." The real task is to think clearly: How to feed it the right context, how to build a mechanism that slices the right scope.

But more importantly — The phase of discussing "mechanisms" has long ended. Now the most critical thing is to focus on "what exactly to do." Years of empirical evidence lead me to believe the conclusion stops here.

A Personal Note

What moves me most in this retrospective isn't a specific tool, but the cognitive curve itself: We always thought AI would replace us in "doing things," but what it truly forces us to upgrade is "judgment."

Documents can be auto-generated, prototypes one-click produced, code batch-laid-out — when these are no longer scarce, human value is compressed and purified to the most core point: Among infinite possibilities, decide "what to do and what not to do."

No tool can do that for you.