Drafting Specs and Requirements

The draft is not the spec

A spec is a document, but its purpose is a conversation. It exists so that engineering, design, data and whoever else is involved agree on what problem is being solved, what done looks like, and what is deliberately out of scope. The value is in the arguments the document provokes before anyone builds the wrong thing.

That makes spec writing an excellent fit for a language model, provided you are clear about which half of the job it is doing. It is very good at the structure: turning your notes into a readable problem statement, drafting requirements in consistent language, writing acceptance criteria in whatever format your team uses, and listing edge cases you forgot. It is useless at the substance: which problem matters, what trade-off is acceptable, what the team should not build.

So treat everything it produces as a first draft to argue with. Its job is to get you to a disagreement faster.

What goes wrong when you ask for a spec

Ask "write a PRD for a team sharing feature" and you will get something that looks finished. Headings, user stories, success metrics, even a rollout plan. It will be coherent and generic, and it will contain three quiet problems.

Silent assumptions. Where your brief was vague, the model fills the gap with the most common answer and does not tell you. Who can share, whether permissions are inherited, what happens to shared items when someone leaves: each gets a plausible default, stated as a requirement.

Invented constraints and metrics. It may mention technical limits, compliance obligations or target numbers that sound reasonable and have no source. A success metric like "increase weekly active teams" appears because specs usually have one, not because anyone decided it.

Scope creep by completeness. A model trying to be thorough adds requirements. A good spec is often defined by what it leaves out, and the tool has no sense of your team's capacity or appetite.

Brief it like an engineer would read it

The fix is to give it your thinking and ask it to structure, extend and question it, rather than asking it to invent the thinking. Paste in the problem as you understand it, the evidence behind it, the constraints you know about and the non-goals you have already agreed. Then require it to separate what you told it from what it assumed.

I am drafting a spec. Do not invent product decisions. Use only what I
give you, and flag every gap.
Problem: [the problem, in the customer's terms, and who has it]
Evidence: [what we know, with sources such as ticket IDs or research]
Constraints I know about: [deadlines, dependencies, policies]
Non-goals already agreed: [what we are not doing]
Rough solution direction: [if we have one, otherwise say so]
Produce a draft with these sections:

Problem statement, in two or three sentences
Requirements, each numbered, each marked either FROM BRIEF or
ASSUMED. For every ASSUMED item, say what you assumed and why.
Acceptance criteria for each requirement, written as
Given / When / Then, covering the normal case and at least one
failure case
Edge cases, grouped by: permissions and roles, data and migration,
limits and scale, interruption and retries, and removal or undo
Open questions I must answer before this goes to the team,
ordered by how much the answer would change the build
Things I did not mention that a reviewer is likely to ask about
Do not add success metrics, target numbers or technical constraints
unless I supplied them. If you think one is missing, put it under
open questions instead.

The ASSUMED marker is the part that pays. It turns the model's silent defaults into a visible list, and that list is usually the best agenda for your refinement session. The open questions section does something similar: a model asked to name what it would need to know often surfaces exactly the question nobody on the team has answered.

Acceptance criteria and edge cases

This is where the time saving is greatest. Writing criteria for every requirement is tedious, and tedium is where gaps creep in. A model will happily produce the failure cases and the permission variants that you would have stopped writing at the fourth requirement.

Two habits keep them honest. First, read every criterion as the engineer who will test against it. If you cannot tell whether a build passes or fails it, the criterion is vague, however well written it looks. Second, ask for criteria that would fail. "Give me two ways a build could meet these criteria and still be wrong for the customer" is a good follow-up, because it exposes criteria that test the mechanics but not the outcome.

For interface states such as empty, loading and error screens, your designer will want the fuller treatment in AI for UX and Product Design. Your concern at spec level is behaviour: rules, permissions, data and what the system does when things go wrong.

What stays with you

The problem statement is yours, because it encodes a decision about what matters. The non-goals are yours, because they encode a decision about what does not. The answers to the open questions are yours, and some of them belong to other people who should be asked rather than simulated. And the final read before the spec goes out is yours, with particular attention to anything marked ASSUMED that you let through.