When you want to build something with agents, you usually toss "build this for me" into a single chat window. You hope the spec, the screens, and the code all come back in one shot.
That tends to dump one blob of output, and you get stuck before you even know what to fix. If you want to build with agents, what you need first isn't a smarter model. It's a pipeline with split roles.
It's role separation, not a single agent#
The point isn't handing everything to one AI. It's orchestration: put planning, design, development, and research in separate roles, and connect them with documents.
When roles mix, outputs mix. If you can't tell planning from implementation, humans have no bar for review, and agents have no input to pass downstream. To keep speed and consistency together, split the roles first.
Five roles you actually need#
Before you spin up a bunch of agents, decide what each of these five roles actually produces.
1) AI planner#
This role pins the problem down in a PRD. It defines user stories and acceptance criteria (AC), and it also proposes feature priority.
The document that comes out of here becomes the baseline for every later step. Chat history must not be the baseline.
2) AI PM / task manager#
This role breaks the PRD into executable work. It converts Epic → Story → Task, and it sorts dependencies and order.
Don't have a human jump straight into writing code. Make them look at the task list first. Hand over a big job in one go, and it goes off the rails.
3) AI designer#
This role maps screen flow and wireframes, organizes component specs, then produces Figma drafts.
Design shouldn't draw the whole screen as one picture. It should move from components up to views. The units a developer will assemble later need to exist first.
4) AI developer#
This role implements from issues and design specs. It builds components first, then composes screens. Testing and refactoring belong here too.
The input isn't "a vibe." It has to be issues + components + design artifacts. Fuzzy input makes fuzzy implementation.
5) AI researcher (interview specialist)#
This role writes interview questions and explains why each question is justified. It summarizes results, extracts insights, and hands them to the next cycle.
Shipping is not the end of making. The role that feeds user feedback back in as the next input is what closes the pipeline.
Run them in this order#
If you only split the roles and run them all at once, you get artifacts that rest on different assumptions. You need a sequence.
- Define the problem — Pin down in one line what you're making, and for whom
- AI planner writes the PRD — Document it through stories and acceptance criteria
- AI PM breaks down tasks — Organize execution units and dependencies
- A human reviews and confirms issues — Registering tasks as issues is a human job
- AI designer produces drafts — Create component specs and screen flow
- AI developer implements — Stack code from confirmed issues and design
- Test, review, ship — Ship only what passes verification
- Collect feedback with an interview AI — Get questions, justifications, and a result summary
- Feed it into the next cycle — Put the insights back into problem definition
The step a human must not skip is number 4. Don't pass agent-made tasks straight into implementation. A human should hold the gate that confirms them as issues.
Keep documents as a single source of truth#
Pipelines usually break not because there are too many roles, but because the baseline documents are scattered.
- Keep a document-based single source of truth (SSOT). When the PRD changes, the tasks should change with it
- Link the artifacts from each step. PRD ↔ issues ↔ design ↔ code should be able to find one another
- Humans own final decisions and quality judgment. Agents handle drafts, breakdown, and implementation
The more you hand off to agents, the less you should coordinate from memory. The next role's input has to be documents and links, or the pipeline doesn't run.
Start with one role#
You don't need to run all five roles from day one. If you have something to build, start by naming the work that's currently mixed in one chat.
Let planning receive only the PRD, task breakdown only the tasks, and implementation only confirmed issues. Add one human gate that confirms issues, and you already have a pipeline that's much easier to handle than a single "build this for me."
No one can whistle a symphony. It takes a whole orchestra to play it.
— H.E. Luccock
