Don't let the same persona handle design, implementation, and review.

If this sounds familiar

SYMPTOMS

• I asked for authentication, but it also included standardizing error handling.
• The diff involves 40 files, and I lack the motivation to read them all, so I approve them superficially.
• Three days later, I can't even explain why this implementation was chosen.
• I want to run tasks in parallel, but fear of conflicts forces me to run them one by one.
• The screens generated always look like something I've seen before.

This is not a capability issue. It happens because you are assigning design, implementation, review, and merging to a single persona. If this were a human team, no one would allow the same person to decide on the design, implement it, review it, and merge it.

The solution is reducing permissions

PERMISSIONS

All five personas use the same model. There is no difference in intelligence. The only difference iswhat they are allowed to do.

AI chooses the most plausible next step within the given context. If you say "Create a login feature," it is plausible to do everything related to it. If you say "Change only inside src/auth/** and satisfy these three acceptance criteria," the most plausible next step becomes something entirely different.

Workflow

FLOW

Request → [Architect] Split into Issues (create non-overlapping scopes)
         │
         ├─ [Coder] issue/12-xxx ─┐
         ├─ [Coder] issue/13-yyy ─┤  Parallel
         └─ [Coder] issue/14-zzz ─┘
                                   │ One PR at a time
                                   ▼
                            [Reviewer] Check acceptance criteria and scope → Merge
                                   │
                                   └─ Conflict → [Conflict Resolver] → Reviewer

Parallel implementation, sequential merging. Merging three things simultaneously means that even if each is correct individually, you cannot isolate the cause if the combination breaks. You end up re-examining all three, which is slower than doing it sequentially.

What this setup built

EVIDENCE

A record you can check beats a description. These four personas built one small CLI, and the whole process is public.

mdlinkcheck — a CLI that finds broken relative links in Markdown. 87 tests, two CI workflows passing.

• Issues — each one carries scope, dependencies and acceptance criteria, written before any code
• Pull requests — each maps to exactly one Issue and stays inside its declared scope
• The parallel run — three Issues implemented concurrently in separate worktrees, merged one at a time

The history is not cleaned up. What went wrong is still in it. Two Issues declared a scope that did not exist; a Coder stopped and reported a missing dependency instead of editing a file outside its scope; and the tool itself caught 17 broken links in its own README. A history with no rejections only proves that review was not doing anything.

Read the history

Two configurations

PACKAGES

The contents are identical across tiers. What differs is how many people may use it and whether you may share it internally. You can move up a tier by paying the difference. The terms ship in LICENSE.txt.

View Quartet on GitHub Purchase Quintet (Coming soon)

Why your UI always looks the same

WHY YOUR SCREENS LOOK GENERATED

Hero section centered on the full screen. Three-column monospace cards with icons. Purple gradient. Pure black text on a pure white background. You recognize it instantly, and once recognized, you lose trust in it.

The cause is letting the Coder decide on the design. If asked to make decisions without specifying colors, fonts, or spacing, the output will be the most frequent form in the training data. This is not an issue of AI's aesthetic sense; it is a lack of input.

In Quintet, the UI Designer writes the specification before implementation. Structure → Tokens → States → Motion → Copy are determined in order, and the Coder implements based solely on the specification. If design elements not written in the spec are required, implementation stops and is sent back.

When not to use this

WHEN NOT TO USE THIS

This adds overhead. The number of steps per task definitely increases.

• Exploration / Prototyping (stage where acceptance criteria cannot be written)
• Changes that can be completed in one file (no point in creating a PR for a typo fix)
• Work with inherently linear dependencies (splitting does not enable parallelism)
• Tasks that take 30 minutes

There are also limits. Since the Reviewer uses the same model as the Coder, it cannot detect errors inherent in the model's systematic knowledge. If a library's API is consistently misremembered, the Coder will make a mistake, and the Reviewer will judge it as correct. The countermeasure is to include executable verification in the acceptance criteria.