{"slug": "assigning-5-personas-to-claude-code-for-parallel-development", "title": "Assigning 5 Personas to Claude Code for Parallel Development", "summary": "A developer has devised a multi-persona architecture for Claude Code that assigns distinct roles—Architect, UI Designer, Coder, Reviewer, and Conflict Resolver—to enable parallel development on large requests. The approach constrains each persona's permissions to create checkpoints and reduce conflicts, with the developer noting that the real challenge lies in how issues are split rather than in the model's capabilities. The developer reports building 10 personal apps in three months and releasing two to the App Store using this method.", "body_md": "When you give a large request to Claude Code, doesn't this happen?\n\nWhile building 10 personal apps in three months and releasing two to the App Store,\n\nI encountered these issues extensively. Here is the architecture I arrived at.\n\nThe conclusion is that **this was not a capability problem. It was a permission design problem.**\n\nYou are asking one persona to handle design, implementation, review, and merging.\n\nYou decide the design, implement it yourself, review it yourself, and merge it yourself.\n\nThere is no check or balance anywhere. No human team would approve this configuration.\n\n| Persona | Can Do | Cannot Do |\n|---|---|---|\n| Architect | Create/split Issues | Write code |\n| UI Designer | Write UI specifications | Write code |\n| Coder | Change only within the assigned Issue's scope | Touch outside scope, merge, or decide structure |\n| Reviewer | Review and merge | Implement or resolve conflicts |\n| Conflict Resolver | Resolve conflicts | Merge or act before being called |\n\n**All use the same model.** There is no difference in intelligence. The only difference is what they are allowed to do.\n\nWhy does this change the result? AI selects the most plausible next step within the given context. If you just say \"build a login feature,\" it is plausible for it to do everything related to that topic. If you say \"change only `src/auth/**`\n\nand satisfy these three acceptance criteria,\" the most plausible next step becomes completely different.\n\n**Constraints create context, and context determines output.**\n\n```\nRequest → [Architect] Split into Issues (create groups with non-overlapping scopes)\n         │\n         ├─ [Coder] issue/12-xxx ─┐\n         ├─ [Coder] issue/13-yyy ─┤ Parallel\n         └─ [Coder] issue/14-zzz ─┘\n                                   │ One by one per PR\n                                   ▼\n                            [Reviewer] Check acceptance criteria and scope → Merge\n                                   │\n                                   └─ Conflict → [Conflict Resolver] → Reviewer\n```\n\n`.claude/agents/architect.md`\n\nlooks like this:\n\n```\n---\nname: architect\ndescription: Use to turn a feature request into GitHub issues for\n  issue-driven parallel development. Defines per-issue scope (owned paths),\n  dependencies, branch names, and acceptance criteria. Never implements code.\ntools: Bash, Read, Grep, Glob\nmodel: inherit\n---\n\nYou are the **Architect**. You do not write code.\nYour job is to \"split Issues into units that can be executed safely in parallel.\"\n\n## What to do when called\n\n1. Read the request and identify necessary tasks.\n2. Split tasks into **1 Issue = 1 scope = 1 branch**.\n   - Keep scopes as narrow as possible and ensure they do not overlap with other Issues.\n   - Group non-overlapping Issues together as a \"parallel start group.\"\n3. When creating an issue via `gh issue create`, always include:\n   - Scope: Paths of files/directories you are allowed to modify\n   - Branch: issue/<number>-<slug>\n   - Depends on: Dependent Issue number (or \"none\")\n   - Acceptance Criteria: Specific enough for the Reviewer to judge\n\n## Rules to follow\n\n- Do not write implementation or test code.\n- Do not put Issues with overlapping scopes in the same parallel group.\n```\n\nOn the Coder side, include this:\n\n```\n- Do not touch files or branches of Issues you are not assigned to.\n- Do not merge to main yourself (only Reviewers may merge).\n- Do not resolve conflicts on your own judgment.\n- If implementation cannot be completed without changing files outside the scope, stop changes and return a report stating \"Changes outside scope are required.\"\n```\n\nThe last line is crucial. If the Coder silently expands its scope,\n\nthe **signal that \"the Architect split incorrectly\" disappears.**\n\nTo be honest, **how you split Issues** matters more than persona settings.\n\nIn practice, conflicts usually occur in the following files:\n\n`package.json`\n\n, migration indexesIf multiple Issues are designed to touch these, conflicts will inevitably occur.\n\nCreate an Issue that changes only the shared file first, and make others depend on it.\n\n```\nIssue #10  Scope: src/routes/index.ts        (Add route definitions first)\nIssue #11  Scope: src/pages/settings/**      Depends on #10\nIssue #12  Scope: src/pages/billing/**       Depends on #10\n```\n\nThis allows #11 and #12 to run in parallel. Since #10 is small, it finishes quickly.\n\nThe Reviewer judges based solely on the acceptance criteria. If written in an unverifiable way,\n\nthe review will pass through without scrutiny.\n\n| Writing Style | Verifiable? |\n|---|---|\n| \"Login functionality works correctly\" | No |\n\"Logging in with an unregistered email returns 401 and `USER_NOT_FOUND` \" |\nYes |\n| \"Improve performance\" | No |\n| \"Initial list display of 200 items completes within 500ms\" | Yes |\n\nSplitting into \"Model Layer Issues\" and \"View Layer Issues\" creates linear dependencies,\n\nso they cannot run in parallel.\n\n```\n(NG) \"Have the coder do Issue 12\" → Wait for completion → \"Do 13\"\n(OK) \"Implement Issues 12, 13, and 14 in parallel using the Coder.\n       Issue three Agent calls simultaneously within one message.\"\n```\n\nSeparating the calls makes them sequential. I wasted a significant amount of time here initially.\n\nEven if implementation is parallel, merging must be done one by one. If you merge three at once,\n\neven if each is correct individually, you cannot isolate issues if the combination breaks.\n\nYou end up re-examining all three, making it slower than sequential merging.\n\nThe practical upper limit for parallel tasks was **3–4**. The constraint lies not with AI, but with review capacity.\n\nEven if scopes are respected, running multiple Coders in the same directory causes accidents.\n\nBuild artifacts mix, and one `git checkout`\n\naffects the other.\n\nSeparate them at the filesystem level using `git worktree`\n\n.\n\n```\ngit worktree add -b issue/12-upload ../worktrees/issue-12 main\ngit worktree add -b issue/13-profile ../worktrees/issue-13 main\n```\n\nSince `.git`\n\nis shared, disk usage increases by only the size of one branch.\n\nTo be honest, **this adds overhead.**\n\nIt is only worth it when you want to run three or more tasks simultaneously, and when\n\ntracing history later has value.\n\nThere is one more limitation. **The Reviewer uses the same model.**\n\nIf the model has systematic errors, such as consistently misremembering a library's API,\n\nthe Coder will make the mistake, and the Reviewer will judge it as correct.\n\nThe countermeasure is to include **executable verification** in the acceptance criteria.\n\n\"Tests passing\" is one of the few ways to externally verify against the model's assumptions.\n\nI publish the configuration for splitting Claude Code into separate personas —\n\nArchitect, Coder, Reviewer, Conflict Resolver — under MIT. Copy it, run\n\n`./setup.sh`\n\n, and it works. It does not depend on your tech stack.\n\n[https://github.com/quintetkit/quartet](https://github.com/quintetkit/quartet)\n\nI built one real tool using nothing but this workflow. Every Issue, PR, review\n\nand merge is still there. **The parts that went wrong were not deleted.**\n\n[https://github.com/quintetkit/mdlinkcheck](https://github.com/quintetkit/mdlinkcheck)\n\nThe version that adds a UI Designer persona, review criteria, a per-Issue\n\nparallel execution script and a 10-chapter guide is on the\n\n[product page](https://quintetkit.github.io/index.en.html).", "url": "https://wpnews.pro/news/assigning-5-personas-to-claude-code-for-parallel-development", "canonical_source": "https://dev.to/quintetkit/assigning-5-personas-to-claude-code-for-parallel-development-5abn", "published_at": "2026-09-04 04:44:37+00:00", "updated_at": "2026-09-04 04:53:54.696501+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools", "artificial-intelligence"], "entities": ["Claude Code", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/assigning-5-personas-to-claude-code-for-parallel-development", "markdown": "https://wpnews.pro/news/assigning-5-personas-to-claude-code-for-parallel-development.md", "text": "https://wpnews.pro/news/assigning-5-personas-to-claude-code-for-parallel-development.txt", "jsonld": "https://wpnews.pro/news/assigning-5-personas-to-claude-code-for-parallel-development.jsonld"}}