How I Build Apps Now: PRDs, Milestones, and AI Coding Agents That Ship

Brian Casel's Builder Briefing describes a simple but important shift: the workflow starts with a raw idea, turns it into a written PRD, breaks it into milestones, and then lets an AI coding agent build one milestone at a time.

That is not the same as vibe coding. Vibe coding is prompt, hope, patch, repeat. The PRD-first approach asks a different question: what exactly should be built, for whom, and what is explicitly out of scope?

Diagram of the idea-to-PRD-to-milestones-to-agent workflow
The useful shift is not more prompting. It is a tighter specification before the agent starts.

Why the PRD comes first

A good PRD turns a vague request into a buildable brief. It names the user, the core flow, the edge cases, the constraints, and the things the team is deliberately not building right now.

That matters because an AI coding agent is only as useful as the instructions it receives. If the spec is fuzzy, the agent can still produce code, but it will often produce the wrong code faster.

  • Users: who actually needs the app.
  • Core flow: the smallest useful sequence the product must support.
  • Edge cases: the failures and exceptions that usually appear later.
  • Out of scope: what you are consciously not paying for yet.

Why milestones help agents ship

Brian's process does not ask the agent to build everything at once. It splits the PRD into milestones and then builds one milestone at a time. That creates a better control loop for both the human and the agent.

Milestones reduce ambiguity, make review easier, and create natural checkpoints where the team can course-correct before too much code accumulates. In practice, that is often the difference between shipping a useful tool and getting lost in a half-finished prototype.

  1. Write the PRD before code starts.
  2. Break it into milestones that can stand on their own.
  3. Let the agent build one milestone.
  4. Review the output and refine the next milestone.

The three free tools Brian highlights

Brian also points to three tools that support the process: PRD Creator, Design System Creator, and Build New. Together they do something practical: they turn abstract product thinking into a repeatable build environment.

  • PRD Creator: helps shape the questions and produce a usable product brief.
  • Design System Creator: sets visual guardrails so the app does not become inconsistent.
  • Build New: gives the team a starter foundation instead of starting from zero every time.

The real pattern is not the tool names. It is the discipline of starting with structure before asking an agent to generate code. Once that habit is in place, the team spends less time clarifying the basics and more time improving the product.

What this process solves and what it does not

This workflow solves a real problem: teams often skip the thinking and move straight to coding. The result is speed at the beginning and confusion later. A PRD plus milestones slows the start a little, but usually accelerates the whole project.

It does not solve product judgment. You still need someone to decide what matters, what to defer, and when to stop polishing. AI can help build the thing faster, but it cannot tell you whether the thing is worth building.

Source note: Based on Brian Casel's Builder Briefing #32, “How I build apps now.”

Previous PostNext Post

Related Articles

Related Services

Service

AI Workforce Process Transformation

Learn More →

Service

Education & Training

Learn More →
Miloš Cigoj
Milos CigojFounder, Excellence Consulting · Operational Excellence & AI Strategy

Interested in this topic?

We help organisations connect AI strategy, regulation and practical controls. Let’s talk.

Get in Touch