# Claude Code Projects Lets a Coordinator Split Your Task. Splitting Was the Job > Source: > Published: 2026-10-24 20:01:59+00:00 Anthropic's [redesigned Projects for Claude Code](https://claude.com/blog/projects-redesigned) has "threads that do the work and a coordinator that directs them." Each thread "is a Claude Code cloud session working on its own branch and copy of the repo," and when two threads touch the same code, "the overlap is resolved as a merge conflict just like any other PR." It went out as a beta on September 17. You give it a goal, and Claude "scopes the request, delegates the work, coordinates parallel threads," then reviews what comes back and assembles the result. Read the merge-conflict line as a reviewer. The coordinator picked the seams. If it picked them badly, you find out at merge time, in a conflict between two branches you didn't plan. Splitting the work is the part of the job that decides whether parallel output can be reviewed at all. I'd keep it. Give the product its due first. Anthropic's post lists real strengths. Threads share a memory: "Every thread now adds to and draws from a shared memory." You can "steer progress throughout, even from your phone," and the work keeps going after you step away from your computer. You choose the model and effort for the coordinator and for the worker threads separately. The examples are good ones. Set a goal to cut your checkout p75 latency, and Claude profiles each endpoint and tests optimizations in parallel threads that open PRs. Connect your API, web and mobile repos to retire a deprecated v1 endpoint, and Claude "creates a thread per repo," then tells you which PRs must merge first. There are limits to know about. It's a beta for select Pro and Max subscribers who use Claude Code cloud sessions, with a waitlist for the rest and Team and Enterprise later ([Anthropic](https://claude.com/blog/projects-redesigned)). Each thread is a full Claude Code session, so "projects can reach usage limits faster." [The Register](https://www.theregister.com/ai-and-ml/2026/09/18/claude-code-revamps-projects-so-you-can-work-and-pay-in-parallel/5297532) summed that up in its headline: work and pay in parallel. I haven't used the Projects beta myself. Everything above is from Anthropic's post and the coverage linked here. Google's code review guide has a page on [small changes](https://google.github.io/eng-practices/review/developer/small-cls.html). It defines the right size as "one self-contained change," and it says reviewers "have discretion to reject your change outright for the sole reason of it being too large." Then comes the line that matters here: "it's often useful to think about how to split and organize those CLs at a high level before diving into coding." Before diving into coding. The split comes first because it fixes everything after it: Google's page names the moves: split by files, split horizontally with "shared code or stubs that help isolate changes between layers," split vertically into "full-stack, vertical features," or combine them. Choosing between those is a design decision. It needs to know who reviews what, which module is fragile, and which interface you're willing to freeze for a week. That is senior judgment, and it is the same skill a system design interview tests when it asks you to draw the boxes before you fill them. A coordinator that splits for you makes that decision on your behalf, then asks you to review the result. When the seams are wrong, the merge conflict is the symptom. The cause sits upstream, in a plan nobody checked. There is field data on what happens when code arrives faster than anyone can check it. Fiona Chen and James Stratton at Harvard studied engineering data from 718 firms, January 2021 to March 2026, in a working paper called [*Artificial Intelligence in the Firm: Bottlenecks in Software Production*](https://fion.ac/jellyfish.pdf). It's a job market paper, the data comes from the engineering analytics company Jellyfish, and it hasn't been through peer review. Weigh it that way. After firms adopted AI coding agents, the paper finds lines of code up 30%, commits up 20% and pull requests up 23%. Resolved Jira issues showed small, statistically insignificant gains, and the estimates rule out an output increase larger than 12% of the baseline. The bottleneck it points to is review: "The average time to review a pull request increases by 49%," the share of PRs with changes requested nearly doubles, and comments per PR rise 35%. Writing code is one step, the paper says: "upstream, managers must plan and scope features," and downstream the code has to be reviewed and tested. From the Jellyfish data, checked against a survey of 100 engineers, it finds that engineers spend 30 to 40% of their time writing code. Agents sped up the step that was already the smaller share. The other 60 to 70% goes to the work around it, and the bottleneck the paper measures is review. A coordinator that scopes and splits moves the upstream step to the model too. Maybe it does that well. The paper's numbers suggest where the cost lands if it doesn't: in review, which is already the slow step. Run agents in parallel if you like. Write the split yourself first, in a form a reviewer can check. A short file does it: ``` # Split: refunds for paid orders 1. refund-type (orders-types): add RefundStatus. Seam: the type. Nothing else changes. 2. refund-endpoint (orders-api): POST /orders/:id/refund, with a test. Needs 1. src/routes and src/db only. 3. refund-ui (web-app): refund button on the order page. Needs 2's response shape. Merge order: 1, 2, 3. ``` Then one branch and one worktree per line, named after the task. A worktree belongs to one repository, so create each one from the repo its line touches: ``` cd ~/code/orders-types git worktree add -b task/refund-type ../refund-type cd ~/code/orders-api git worktree add -b task/refund-endpoint ../refund-endpoint cd ~/code/web-app git worktree add -b task/refund-ui ../refund-ui ``` Each agent gets one line of that file as its prompt. When a branch comes back, check it stayed inside its seam before you read a single line of the diff. From `~/code/orders-api`: ``` git diff --stat main...task/refund-endpoint ``` If that list names a file outside `src/routes` or `src/db`, the branch left its seam. Send it back before you start reviewing. If you use Projects, nothing stops you from pasting the same split into the coordinator chat as the goal, though I haven't tested whether it holds to those seams. A person wrote them and can say why each one is there. That's the part to keep. I build Hermes IDE, so weigh this section with that in mind. It's a desktop app that runs Claude Code, Codex and other CLI agents in their own terminals, and its unit of work is the task you name. Press ⌘N (Ctrl+Shift+N on Windows and Linux), type one task, and per the [README](https://github.com/hermes-hq/hermes-ide), Hermes starts it "on its own `hermes/` branch in its own worktree, with the task as the agent's first prompt." Three lines in your split file means three ⌘Ns. *The ⌘N New task sheet: the task "Add a POST /orders/:id/refund endpoint for paid orders, with a test", chips for Claude Code, the orders-api project, a new hermes/ worktree, Accept edits, model and effort, and the "Hermes will run" preview of the claude command.* You pick the agent per task, so the type change can go to Codex and the endpoint to Claude Code, side by side in split panes. *Two real agent sessions side by side: Codex on orders-types after adding a RefundStatus type, and Claude Code on orders-api after a follow-up turn adding a log line, each in its own hermes/ worktree, with the sessions sidebar (status, context use, cost, branch) on the left.* When they're done, the Review Desk (⌘G) shows each branch by turn or by file, and Land commits, opens a PR or merges into the branch the task started from, with undo. Hermes doesn't split a goal for you: each ⌘N is one task you describe. That is the point of this post, but it's also a real gap if you want hands-off parallelism. It has no cloud agents either. Projects keeps going after you step away from your computer. Hermes runs on your machine, and on macOS and Linux agents keep working while Hermes itself quits or updates. Hermes is free, source-available under BSL 1.1, on macOS, Windows and Linux, and it isn't affiliated with Anthropic, OpenAI, Nous Research or any agent vendor. Parallel agents are cheap now. Review is the step that isn't, and the shape of the split decides how expensive it gets. A coordinator can propose seams. I'd still want a person to sign off on them before the first thread starts typing. Have you let a coordinator split real work yet? Did the merge conflicts land where you expected, or somewhere you'd never have cut? Tell me in the comments. Deciding where a system splits, and defending why, is a big part of any design round. The [System Design Pocket Guide: Interviews](https://www.amazon.com/dp/B0GX2SQ594) walks through 15 real system designs, step by step. Choosing the seams before anyone writes code is the same habit this post asks you to keep when the agents do the typing. If you want to try one-task-per-worktree, [download Hermes IDE](https://hermes-ide.com/download) or [read the source on GitHub](https://github.com/hermes-hq/hermes-ide).