Most people prompt AI coding agents like they're talking to a chatbot. "Build me a login page." "Add a dark mode toggle." "Fix this bug."

That works for trivial tasks. But if you want to build a real product — something with consistent design, sensible architecture, and features that actually work together — you need a fundamentally different approach.

We call it PRD-first development. And after shipping two iOS apps and a handful of web tools with it, we're convinced it's the most important skill in AI-assisted development.

What's a PRD?

A Product Requirements Document. In traditional software development, it's the spec that product managers hand to engineering teams. It describes what you're building, for whom, and why — without prescribing how.

In AI-assisted development, the PRD serves a different purpose. It's not a handoff document between humans. It's the primary input to your AI coding agent. The PRD becomes the product definition that shapes every line of generated code.

Why it works

AI coding agents like Claude Code read your entire repository before generating code. They understand existing patterns, naming conventions, and architecture decisions. What they don't inherently understand is intent — why you're building something, what the user experience should feel like, and where the edge cases live.

A good PRD fills that gap.

Consider the difference:

❌ Without PRD

Build an expense tracking
feature for a trip
planning app.

✅ With PRD

Build expense tracking per
the attached PRD.
- 3 split types: equal,
  percentage, exact
- Settlement via simplified
  debt algorithm
- UI follows RTDesignSystem
- See data model section

The output is night and day. The PRD-informed version produces code that fits the product vision because the AI has context about the whole system, not just the immediate feature.

We've seen this play out dozens of times now. Without design constraints, AI produces the same bland interface every other AI-built app has. With a 20-line design system reference, it produces something that looks intentional.

Anatomy of an effective AI-facing PRD

Here's what we include in every PRD. The format has evolved over months of iteration.

1. User stories — keep them concrete

Don't write "As a user, I want to track expenses." Write: "As the trip organiser, I add a £45 fuel receipt, split equally between 3 people, categorised as 'Fuel', at the current stop." The specificity gives the AI realistic test cases to code against.

2. Data model — be explicit

Define your models, their relationships, and constraints. The AI should never have to guess whether an expense has-many splits or belongs-to a trip. Write it out. Include cardinality, optionality, and cascade rules.

3. UI descriptions — not wireframes

"The expense list shows a scrollable list grouped by stop, with each card showing the amount, category emoji, payer name, and split indicator. Tapping opens the detail view." This gives the AI enough to build correct UI without being so prescriptive that it can't adapt to the platform.

4. Design system reference

Point the AI at your design tokens file. Colours, fonts, spacing, corner radii. Without this, you get system-default everything.

💡 This is the single biggest lever

80 lines of design tokens produce better apps than 80 hours of prompt engineering. An AI with a design system writes beautiful, consistent code. An AI without one writes generic Material/UIKit defaults.

5. Edge cases and business rules

"If a percentage split doesn't sum to 100%, show an error. If a member leaves the trip, their unsettled expenses transfer to the organiser." Every unwritten rule becomes an AI hallucination waiting to happen.

6. What NOT to build

Equally important: "v1 does not include receipt OCR, multi-currency, or recurring expenses." This prevents scope creep from an AI that's trying to be helpful by anticipating features you haven't asked for.

The workflow

Our development cycle has stabilised into a reliable pattern:

  1. Write the PRD (45–60 minutes) — This is the creative act. Everything downstream depends on it.
  2. Plan mode — "Read this PRD. What questions do you have? What are the riskiest parts?" The AI's questions often reveal gaps you missed.
  3. Execute in phases — One logical chunk at a time. Data model → core views → edge cases → polish. Never the whole feature at once.
  4. Build after each phase — We regenerate the Xcode project with XcodeGen, build, and fix any compilation errors before moving on.
  5. Human review — Read every file. Understand what was generated. Fix the 15% that needs adjustment.

The entire PRD → working feature flow takes 2–4 hours for a substantial feature. Traditional estimation for the same scope: 2–4 weeks.

Real numbers from real projects

In our latest tracking (February 2026):

  • 4/4 Claude Code sessions succeeded across one day of work — including a complete AI pipeline rewrite for a trading bot
  • 92 tests generated alongside production code, all passing
  • 3 PRDs written, each taking 30–45 minutes
  • Zero rollbacks — every feature that went through the PRD workflow shipped

Compare that to the sessions where we skipped the PRD. Those typically require 2–3x more iteration, produce inconsistent styling, and miss edge cases that break in testing.

Common mistakes

Over-specifying implementation

Don't write "Use a UICollectionView with a compositional layout." Write "Show items in a responsive grid that adapts to screen width." Let the AI choose the implementation. It often picks better approaches than you would because it's seen more patterns.

Under-specifying intent

Don't assume the AI understands your product vision. It doesn't. If settlements should feel simple and friendly (not transactional), say that. If the app should feel premium and minimal (not feature-packed), say that.

Skipping the design system

The number one complaint about AI-generated UIs is that they look generic. That's not the AI's fault — it's the absence of design constraints. Even a minimal design system (primary colour, accent colour, font, corner radius, spacing scale) transforms the output.

Building too much at once

Even with great PRDs, asking for an entire app in one prompt produces worse results than building it feature by feature. The AI benefits from seeing previously-built code as context for new features. Each phase adds to the codebase, and the next phase's output improves as a result.

The meta-insight

The PRD-first approach reveals something interesting about the future of software development: product thinking becomes more valuable, not less.

If anyone can generate code, the differentiator is knowing what to build. How it should feel. Where the edge cases are. What "done" looks like.

The PRD is the product. The code is just the compiled output.

We've found that spending an hour on the PRD saves four hours of iteration. It's the highest-leverage activity in our entire workflow. The AI doesn't need better prompts — it needs better briefs.

The developers who thrive with AI aren't the ones who type fastest. They're the ones who think clearest.

We're publishing our actual PRDs alongside the apps we build. If you want to see working examples of AI-facing PRDs, or you're developing a similar workflow and want to compare notes, get in touch — [email protected].

This is the second in a series about AI-assisted development. Previously: Building an iOS App in One Evening with AI. Next: Design Systems for AI — why 80 lines of Swift tokens produce better apps than 80 hours of prompt engineering.

Sett & Stone is a small software studio based in Yorkshire, UK. We build Rowta (trip planning), Glucoscape (diabetes management), and various tools for things we find interesting.