A PRD is not enough anymore: what an AI coding agent actually needs to build your app

A product requirements document used to be the end of the specification. You wrote what the app should do, handed it to a developer, and the developer filled in the rest — the tables, the endpoints, the edge cases — with judgement.

An AI coding agent does not fill in the rest with judgement. It fills it in with guesses. And guesses, repeated across a whole codebase, are how you end up with a database that does not match the document, an API payload that changes shape twice in one week, and no security rules anywhere.

That is not a complaint about the agent. The agent did exactly what it was told. The document never actually decided those things.

Prose is a suggestion. A schema is a contract.

When a human reads "users belong to organisations", they know what that means for the database, the API, and the permissions. When an agent reads it, it has to invent a table name, a foreign key, a query pattern, and an authorisation check — and it will invent a different one in each file if nothing pins it down.

This is why I stopped treating the PRD as the deliverable and started treating it as one part of a suite. The tool I built, Web Dev Mehedi, takes one product idea and generates four files that agree with each other, in under 60 seconds:

1. PRODUCT_REQUIREMENTS.md — scope, user journeys, edge cases, and GIVEN/WHEN/THEN acceptance criteria.
2. UI_UX_SPECIFICATION.md — design tokens, typography, view states, and accessibility rules, so the interface is specified instead of improvised screen by screen.
3. TECHNICAL_ARCHITECTURE.md — the PostgreSQL DDL schema with Supabase Row Level Security policies, plus typed REST and Server Actions API contracts with Zod validation, in the same file as each other so they cannot drift apart.
4. AI_AGENT_IMPLEMENTATION.md — phased build instructions and prompt rules that pin Cursor, Claude Code, or Windsurf to files 1–3: use these exact table names, these exact payloads, never bypass RLS, and flag conflicts instead of choosing silently.

Nothing in that list is exotic. It is just the set of decisions a senior engineer would have made anyway — written down before the code exists, instead of discovered afterwards.

Three things this changed for me

Multi-tenancy has to be in the schema on day one. If the RLS policy is written in the same step as the table, the agent never gets a chance to build an unprotected version first and bolt security on later. Security that arrives later arrives incomplete.

Agents follow rigid rules surprisingly well. Most of the "hallucinations" I saw were vagueness failures, not capability failures. The spec never actually decided the thing the agent got wrong — so the agent decided it, plausibly, and wrongly.

Specification is the new bottleneck. Writing code got cheap. Deciding exactly what to build — tables, payloads, permissions, states — is now the expensive part, and it is the part most teams still do in prose.

A note on who this is priced for

Web Dev Mehedi is built in Bangladesh and priced in Taka — from ৳99/month, paid with bKash or Nagad, with 50 free credits on signup and no card required. That is a deliberate choice: the developers and founders I am building for pay for everything with mobile money, and they get skipped by almost every tool in this category, which assumes a dollar card.

If you build with AI coding agents, try generating the full suite for your next idea and hand the agent all four files instead of just the PRD: https://webdevmehedi.com/ai-prd-generator

The free template behind the format is on GitHub if you want to use the structure without the generator: https://github.com/web-dev-mehedi/ai-prd-template

What do you hand your coding agent before a build — and what does it still get wrong?