- Overall: LOOP Multi 88 vs Single 80 (Multi wins 10 of 14 items).
- But not one-sided: feature depth, UI, and UX go to Single; maintainability, separation of concerns, SOLID, extensibility, and fewer bugs go decisively to Multi.
- The verdict: grow a product → Multi; show a demo today → Single. Each process stage buys a different kind of quality — design buys structure, the QA loop buys fewer defects.
- Follow-up (measured): under an identical external QA gate, the human round-trips to pass were Single 3, Multi 3 — a tie. Multi's internal QA did not reduce human intervention; its value is structural quality and a slightly faster, cleaner convergence.
The experiment
A browser paint app with an identical spec (20 buttons, 20 features, dark theme, no external libraries) was built through two processes.
- Single: one veteran engineer; final deliverable only.
- LOOP Multi: a strict PM → architect → developer → QA → fix-loop → survey workflow.
Model (Fable 5), environment, spec, and system prompt were identical; only the process instructions differed. A third-party evaluator agent then scored both codebases on 14 items out of 100, citing file:line evidence. Both apps passed live browser checks for drawing, undo, and redo.
The exact prompts (in Japanese, as sent):
▶ Download the Single and Multi prompts (.txt)
Results
Overall score (average of 14 items, scored by a third-party evaluator agent)
All 14 items. ■ Single / ■ LOOP Multi
What the two deliverables look like
Single, "Dark Paint" — SVG icons, always-visible palette. 7 files / largest 790 lines
Multi, "Paint Studio" — 18 files / largest 348 lines, EventBus + Strategy + 3-layer canvas
Where the gap comes from
- The design stage buys structure: separation 93 / SOLID 92 / extensibility 92 are direct products of the architect role — adding a tool really is one class plus one registration line.
- The QA loop buys fewer defects: Multi ships defensive code throughout (pointer-id tracking, zero-size guards, MIME checks). Single ships a real multi-touch drawing bug and empty undo entries — the difference of being built "knowing it will be inspected".
- The process has a cost — polish: budget spent on role-play and review round-trips is budget not spent on extras. Single's niceties (draggable selections, zoom-around-center, tolerance fill) are simply absent in Multi. That is the UI/UX gap.
Postscript: measuring human round-trips to a passing bar
"Multi runs on its own, so it should need less human intervention" — to test that, I put both deliverables through an identical external QA gate and counted how many times I had to send a fix instruction (i.e., how many times control came back to the human; agent-internal hand-offs don't count) until an independent QA reported zero blocking (high/mid) bugs.
Blocking bugs (high+mid) per QA round. Both reach zero after 2 fixes — 3 human round-trips each (1 build + 2 fixes)
The result was a tie: Single 3, Multi 3 (1 build + 2 fixes each). Multi's internal QA did not reduce the external round-trips. It did start with fewer blocking bugs (1 vs 2), leave fewer minor ones (2 vs 3), and its fix builder ran faster overall (25.8 vs 32.0 min). So Multi's value is structural quality and slightly faster convergence, not fewer human touches — consistent with the 14-item scores above. (One trial per condition; the "mid" bar is somewhat subjective but applied identically to both. The main thing that interrupted continuous running was the usage cap, not model capability.)
Environment: three isolated agents on aidoc (2 builders + 1 evaluator, all claude-fable-5, memory-unbound, isolated workspaces). Builders did not know they were in a comparison. One trial per condition — a small sample.