Is a PRD for coding agents still worth writing?
Stefan-Iulian Tesoi · · 6 min read
Yes, but not as the thing a coding agent reads. A PRD for coding agents still records why the work exists and what success looks like, which no backlog item holds. Handed to an agent whole, it gets built as one oversized change; split into items with their own acceptance criteria, it becomes the reference those items point back to.
The document kept its value and changed its reader. It used to be read by engineers who filled the gaps from conversation. Now its readers are the people deciding, and the items cut from it are what the agents read.
What is a PRD for once agents build?
A product requirements document is the record of a decision: the problem, who has it, what success looks like, and what is deliberately out of scope. None of that fits inside a single backlog item, and none of it stops mattering because the code got cheaper.
What changed is the division of labour between the document and the items below it.
| Question | Answered by the PRD | Answered by a backlog item |
|---|---|---|
| Why does this work exist? | Yes | No, it links back |
| What does success look like for the business? | Yes | No |
| What must be true when this one change is done? | No | Yes, as acceptance criteria |
| Which code does it touch, and what must not break? | Rarely | Yes |
| What is out of scope? | Yes | Only where it constrains the change |
The left column is for people deciding whether the work is worth doing. The right column is for whoever builds it, and with agents that reader takes everything literally.
What happens when an agent is handed the whole PRD?
It builds all of it at once, as one change that nobody can review properly. Claude Code and Cursor will both accept a twelve-page document and start, because nothing in the document says where one piece of work ends and the next begins.
The result has a recognisable shape:
- One branch for fourteen requirements. The diff touches thirty files and runs to thousands of lines, so review becomes skimming.
- Uneven depth. The requirements near the top get careful treatment; the ones near the end get a stub and a confident summary.
- Silent decisions. Every ambiguity the PM left open is resolved by the agent, in code, without anyone being asked.
- One verdict for many claims. The agent reports the feature as done, so a requirement that was half met hides inside a whole that looks finished.
A PRD is written to be agreed with. A backlog item is written to be checked against. An agent can only do the second.
Anthropic's own Claude Code best practices recommend asking the agent to plan before it writes code, and the plan it produces is a decomposition. The planning has to happen either way. The real question is whether it happens on the backlog, where a person can see and reorder it, or inside one agent session, where it disappears when the session ends. The mechanics of cutting work small enough are in splitting user stories small enough for a coding agent.
Which parts of a PRD for coding agents survive decomposition?
All of them, but each goes to a different place. The test for any section is who needs to read it and when.
| PRD section | Where it lives after decomposition |
|---|---|
| Problem and who has it | Stays in the PRD; the epic description links to it |
| Outcome and success metric | The epic's acceptance criteria, and its milestone |
| Numbered requirements | One backlog item each, with checkable acceptance criteria |
| Non-goals | Stated in the items they constrain, so the agent sees them |
| Constraints and risks | Each item's blast radius and dependencies |
| Open questions | Resolved before any item is ready; never handed to an agent |
The last row is the one teams skip. An open question copied into an item becomes a decision the agent makes, and it makes it in the direction that is easiest to implement. What each item needs on top of its requirement is set out in how to write a backlog item an agent can execute.
Who keeps the PRD and the items in step?
One owner, and changes flow from the document to the items, never the other way without a decision. Two copies of a requirement drift, and the stale one is always the one somebody reads.
Three habits keep them aligned:
- Every item names the PRD requirement it implements. When the requirement changes, the affected items can be found by search rather than by memory.
- A change found during the build goes back to the PRD the same day. If an agent's work shows a criterion was wrong, fix the document first, then the item.
- Closing the last item is a check on the PRD's outcome, not the end of the work. The success metric the document named is what says whether the epic delivered.
This is product ownership work, and it is the gap teams hit about a month into running agents. In Laimonade the hierarchy is milestone, epic and item: Laimon drafts the epic and its items from the intent you describe, asks about the parts that are missing, and a coding agent works from the items over MCP rather than from the document. A coding agent hands its work back to In Review and cannot move its own item further; a person or Laimon closes it, and a closure by Laimon is stamped as Laimon's. The model is laid out in how Laimonade works, and the role behind it in what an AI product owner actually does.
What does a PRD template look like when it has to decompose?
One page, six sections, and every requirement numbered so it can become exactly one item. Most of how to write a PRD for agents is writing less of it, but writing it in a shape that splits cleanly.
- Problem. Two sentences: who has the problem, and what it costs them today.
- Outcome. One measurable signal of success, and the date it should be read.
- Requirements. A numbered list, each one an observable behaviour: "an invited user who has not signed up sees the invitation again after 3 days".
- Non-goals. What will not be built, named, so nobody builds it.
- Constraints. Systems, contracts and data that must not break.
- Open questions. Must be empty before the first item reaches Ready.
A PRD template longer than this usually holds implementation detail, which belongs in the items, or a discussion, which belongs in the open questions until it is settled. If requirement 3 cannot be written as one observable behaviour, it is two requirements.
Frequently asked questions
How long should a PRD be now?
One page, occasionally two. The detail that used to lengthen a PRD, such as edge cases, field validation and error states, now lives in each backlog item's acceptance criteria, where an agent will read it and a reviewer can check it. A PRD that runs past two pages is usually holding item-level detail or an unresolved debate.
Can an agent draft the PRD?
It can draft one, and a decent first draft from a description takes minutes. What it cannot do is decide what is worth building, for whom, or what to leave out. Treat an agent's draft as a list of questions to answer: every assumption it made is a decision someone on the team still has to take.
Does a PRD replace epics?
No. The PRD explains why the work exists; the epic is where that work lives on the board, holding the items and rolling up to a milestone. A useful pairing is one epic per PRD, with the epic description linking to the document and the epic's acceptance criteria restating the PRD's success measure.