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?
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.
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.
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.
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.
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.”
We help organisations connect AI strategy, regulation and practical controls. Let’s talk.
Get in Touch