The first thing to understand about multi-agent coding workflows is that they exist to solve an economics problem, not a capabilities problem.
For nine B&B operators in Hengchun building booking-direct websites, the question was never whether production-grade software quality was achievable — it was whether it was achievable at a cost structure that made sense for a small lodging business. A development team staffed with a product manager, architect, designer, senior engineers, and QA runs at a monthly burn that dwarfs the additional revenue a booking-direct website generates in its first year. That’s why OTAs still dominate: not just because they have massive ad budgets and established brand trust, but because the entire professional apparatus behind their listed properties — professional digital and marketing teams, full-time operations — doesn’t have an equivalent on the direct booking side.
The multi-agent pipeline is the structure I use to run PM, architecture, engineering, and QA as distinct functions without staffing those roles. Each role is a different agent with different constraints and a different adversarial counterpart. The output quality is real. The cost is Wayne-plus-Claude. This was economically unthinkable for this category of client before AI — now it exists.
Five phases, six mandatory stops
The workflow has five phases: PM, Architect, Designer, Engineer, QA. Most phases run with paired agents — alpha and beta work independently, then debate before converging on a single output. I stop and read the output between every phase. That’s not ceremony; it’s the only error-correction mechanism the pipeline has.
PM phase. pm-alpha and pm-beta write separate PRDs. They consistently disagree — not on solutions, but on problem definition itself: which users matter most, which failure modes to prioritize, which constraints are real versus assumed. Making them argue it out produces something more precise than either draft. Assumptions get forced to the surface. Edge cases get named before anyone touches a schema.
Architect phase. architect-alpha optimizes for clean architecture and correctness; architect-beta optimizes for simplicity and pragmatic delivery. They fight on the same input and the tension is productive — forced to justify every abstraction, they collectively surface trade-offs that neither would have articulated alone.
Engineer phase. Engineering is structured differently. Rather than pairing, I split by layer: alpha handles domain types and Zod schemas, beta handles infrastructure and queries, gamma handles presentation. Before any of them start work, alpha runs a dependency analysis — mapping which specific files and type definitions each engineer needs — to establish the correct build order.
engineer-alpha: dependency analysis → domain layer (types, entities, schemas)
engineer-beta: infra + queries (depends on alpha's domain types)
engineer-gamma: pages + components (depends on beta's query return types)Without the dependency analysis step, gamma repeatedly imports types that alpha hasn’t written yet. Not a failure of agent behavior — just the absence of a shared view of what exists at any point during the build.
QA phase. qa-alpha runs user journeys: navigating the application as a real user, switching locales, walking content listing pages end-to-end. qa-beta handles architectural compliance and logic analysis — checking implementations against specifications, verifying edge cases weren’t left unhandled. They cross-review before producing the final report.
The gate is the only thing that matters
Agents don’t audit their inputs. They execute against them.
If PM is 10% wrong, Architect amplifies it. By Engineering, something is being built that doesn’t match what I wanted — and none of the agents know. They’re faithfully processing their inputs; the misalignment isn’t execution failure, it’s a specification error that traveled downstream unchecked. The discrepancy only surfaces when someone with knowledge of what was actually wanted examines the output. In this pipeline, that’s me, and the only moments I can apply that knowledge are the gates.
I learned this the hard way. I skipped the PM-to-Architect review gate once to move faster. Both architect agents received the same PRD with one ambiguous sentence about how sessions are identified. Alpha interpreted it one way, beta another. Each built a complete, internally consistent architecture around its interpretation. They converged — confidently, on incompatible schemas. By the time I read the output, they’d burned their entire context budgets building something I hadn’t asked for.
Reading the PRD before Architecture started would have caught it. That one ambiguous sentence was visible. I chose not to look.
Skipping a gate doesn’t shorten the timeline. It removes the only mechanism that phase has for catching mistakes before they’re codified into the next phase’s inputs.
Convergence doesn’t mean correct
When pm-alpha and pm-beta disagreed and had to defend their positions, the output was noticeably more rigorous. Competing framings forced each agent to justify choices that would otherwise have been invisible assumptions.
The failure mode is the inverse: paired agents converging on something wrong. Two separate reasoning chains arriving at the same conclusion creates the feeling that the question is settled. The confidence of convergence is exactly what makes it dangerous. When both agents agree confidently, that’s when to read more carefully — not less.
Build passing is a low bar
npm run build passed. npm run test passed. I committed.
Then qa-alpha walked the zh-TW route as a real user and found page titles still in English. qa-beta found featured post cards displaying the wrong date format depending on locale. Neither defect fails a build. Neither surfaces in a type check. Both are visible in about thirty seconds of actual navigation.
This is the class of defect that type systems, build assertions, and unit tests structurally cannot reach. Problems only visible when the full system is in motion, with real data, navigated by someone who knows what correct looks like.
Three to four times slower, at the right places
A full iteration — PM through QA — takes roughly three to four times longer than asking a single agent to implement something directly. Almost all of that slowdown is in PM, Architecture, and the gate pauses. Engineering itself runs at roughly the same speed either way.
That ratio is the structure working as intended. Engineering runs on a spec that’s been challenged in two separate debates and reviewed before any code is written. One agent writing a PRD and immediately coding produces mediocre output — the inputs haven’t been stress-tested. Two agents debating a PRD, a human gate, two agents debating architecture on that foundation, another human gate, then Engineering building on verified specs — quality compounds across phases in a way that flat parallelism doesn’t produce.
You don’t get this by adding more agents to the same process. You get it by making each phase earn what it hands downstream.
What gets preserved
The whole setup is extracted into a reusable template (my_ai-coding-template) — agent definitions, workflow rules, process documents, branch policies, and a set of Claude Code skills that install globally. A new project bootstraps in one command. The next project after the first recovered several hours immediately, and subsequent ones more.
The template has now been used on three production B&B sites. The agent definitions are first-class code — they define the editorial voice, the architecture philosophy, the QA standard. When the pipeline produces something wrong, the fix goes into the agent definition, not just the output.
What the pipeline cannot do is tell you whether you built the right thing. That judgment is still entirely human.