Claude Code Projects: A Review Plan for Parallel AI Work

Parallel coding agents do not remove the need for someone to decide what counts as a safe, correct change. They move that responsibility into a workflow with more branches, more context, and potentially more simultaneous decisions. With Claude Code Projects, the coordinator can divide related work into threads, gather their reports, and surface pull requests for review. A human still has to define the allowed work, inspect the evidence, reconcile overlapping changes, and decide whether a change should merge.

That is not a flaw in the product. It is the job of the system around it. Anthropic’s current Projects guide describes threads as separate Claude Code sessions with their own context windows and, for cloud work, branches and repository copies. It describes project instructions and memory as shared context, not a guarantee that every instruction is enforced. It also says approval prompts are handled inside the individual thread. These details matter because a project-level message, a thread-level approval, a repository permission, a pull request, and a merge are different control points. Before automating more of a process, apply the same test for whether a task is worth automating: identify which steps are repeatable and which decisions still need a named owner.

VentureBeat’s launch-day reporting similarly describes separate worker sessions and notes that overlapping changes can still produce ordinary merge conflicts. That corroborates the need to retain a human integration decision, but it is reporting about the product design, not a controlled safety evaluation (VentureBeat’s report).

My recommendation is to create a short decision-rights map before running the first batch. Name the person who may define scope, the person who can approve access, the reviewer for each pull request, the owner of integration conflicts, and the person who decides whether to merge. Then start with a small task and prove that the map works in practice. The proposal below is a governance pattern, not a claim that Anthropic has certified it or that we have tested it in a production repository. The same boundary matters for where review should stay in unattended coding, where the ability to continue work does not transfer responsibility for accepting or merging it.

A coordinator can organize work without owning your release decision

The redesigned Claude Code Projects experience starts from a continuing project conversation. Anthropic says a user can send related work to that conversation, and Claude can answer in place, route work to an existing thread, or start a new one (launch announcement). Threads do the assigned work and report back. The project’s Overview page groups what is working, waiting, completed, and ready for review.

View image detail

A human decision separates a proposed change from an accepted change.

Actual size

Choose Actual size to read the graphic closely.

It is tempting to read “coordinator” as “manager who has accepted the outcome.” The product’s description is narrower. The coordinator keeps track of threads and sees what they report, rather than every step they take. A separate thread has its own session and context window. A thread working in the cloud can make changes on its own branch and open a pull request when the work calls for one. This is a useful way to gather parallel work, but it does not establish that the result matches an engineering standard, has passed the team’s complete test suite, or is ready for release.

The distinction matters for accountability. If the coordinator chooses a poor decomposition, you still need a human to recognize it. If one thread misunderstands a requirement, the person who owns that requirement needs to correct it. If two threads make inconsistent assumptions, someone must resolve them before integration. If a pull request is technically valid but product-inappropriate, the pull request still needs to be rejected. The software can route work; the team remains accountable for the change it ships.

This should affect how you describe the tool to colleagues. “Claude will run several threads and bring back branches for review” is both ambitious and precise. “Claude will implement the feature safely while we are offline” bundles together code generation, risk management, test completeness, and authorization. Those are different claims, and the public product guide does not make them equivalent.

The human decisions form a chain

A review plan is easier to make when you name each decision separately rather than assign a vague “human in the loop” role. For a multi-thread code project, the chain often looks like this: a person approves the goal; a person limits the repositories and tools; a person confirms the work split; a thread produces a diff; automated checks produce evidence; a reviewer interprets that evidence; an integration owner resolves interaction between branches; and an authorized maintainer decides whether to merge or release.

View image detail

Parallel proposals stop at one human approval gate before acceptance.

Actual size

Choose Actual size to read the graphic closely.

This chain does not have to involve eight different people. In a small team, one person may hold several roles. The important thing is that the responsibilities are explicit and that a thread cannot silently exercise authority it has not been given. A branch is an isolation mechanism, not an approval. A passing test is evidence about the cases it covers, not a complete assessment of business intent. A pull request is an invitation to inspect, not a release instruction.

A compact decision-rights table can help:

• What work is in scope?: Owner: Product or engineering lead; Evidence to inspect: Goal, acceptance criteria, exclusions; Boundary: Threads do not redefine the outcome
• Which repositories and tools are allowed?: Owner: Repository or security owner; Evidence to inspect: Access list, environment, data classification; Boundary: Do not broaden access by convenience
• Is the task split safe to run in parallel?: Owner: Technical lead; Evidence to inspect: Shared contracts, file overlap, dependency map; Boundary: Interdependent changes stay sequenced
• Is each change technically sound?: Owner: Named code reviewer; Evidence to inspect: Diff, tests, warnings, assumptions; Boundary: “Thread complete” is not approval
• Do the changes fit together?: Owner: Integration owner; Evidence to inspect: Cross-branch behavior, contract checks; Boundary: Resolve conflicts deliberately
• Should the change merge or ship?: Owner: Authorized maintainer; Evidence to inspect: Review, CI, product and release criteria; Boundary: Keep merge/release as an explicit decision

This table is not meant to slow down every change. The least risky task may need a very lightweight path. But the table makes it possible to choose a proportionate path intentionally instead of discovering after several threads start that nobody owns integration.

Instructions and memory are continuity, not enforcement

Projects share instructions and memory across work in ways that can reduce repeated context setting. Anthropic’s current guide says a project’s threads begin with the project’s repositories and files, instructions, and memory; cloud threads also load repository CLAUDE.md files and skills. The guide describes project memory as notes Claude keeps about requirements, decisions, and pitfalls. It recommends keeping project-wide context separate from repository-specific instructions.

View image detail

A document is inspected as useful context, not treated as proof of enforcement.

Actual size

Choose Actual size to read the graphic closely.

That is valuable, but it does not make memory a permission system. The guide states that memory files are separate from project instructions and repository CLAUDE.md files. It also says that when a project uses multiple repositories, repository permission rules do not reach each cloud thread in the same way they do for a single-repository project. A written preference such as “use no more than three threads” can be a useful instruction, while the documentation cautions that the preference is not itself a hard cap.

The practical implication is to place every rule in the control that can actually enforce it. Put clear scope, branch, testing, and review expectations in the instructions threads receive. Use repository protections and required reviews for changes that must not merge unattended. Configure the cloud environment deliberately, and do not assume tools installed on a local machine are available in a cloud session. Keep credentials scoped to what the task needs. Ask a human to confirm any permission prompt that exceeds the stated task boundary.

Write memory as a helpful history, not as the only place for a critical rule. If a billing change must be reviewed by a specific owner, include that expectation in the durable instructions and the team’s actual repository review configuration. If a known pitfall should inform the work, record it in memory but verify that it remains current before relying on it. The project is an ongoing conversation, and the guide says later work draws on recent messages, recent threads, and project memory rather than every detail in the complete conversation. A critical acceptance rule should therefore not depend on somebody remembering an old message.

Approval prompts belong to the thread that raised them

Anthropic’s project guide explains that when a thread needs approval, the prompt appears in that thread and waits there. A project-level instruction to “go ahead” does not answer it. Each approval covers the specific prompt or, depending on the choice offered, a broader part of that thread. That is a meaningful boundary for teams who delegate several threads at once.

View image detail

An exceptional request leaves the normal flow for explicit review.

Actual size

Choose Actual size to read the graphic closely.

A reviewer should not treat a waiting approval as a nuisance to clear reflexively. First identify what the thread wants to do, which resource it needs, and whether the request fits the approved task. If the request adds a dependency, touches a new repository, or reaches a protected environment, pause and ask whether the original owner meant to permit it. The quick way to keep a thread moving may also expand the scope beyond what the person who set the goal intended.

For multi-repository projects, extra care is appropriate. The docs state that permission rules from each repository do not apply to a cloud thread in a multi-repository project in the same way as a single-repository project. That shifts more responsibility onto the project’s environment, the approvals people grant, and the review process. A project that spans three repositories is not automatically safer because each thread works on a separate branch. The access path itself needs to be checked.

A small approval log can help a team understand where its policy is ambiguous. Record the thread, requested action, resource, approving person, and reason. Do not copy tokens or sensitive values into the log. Over time, repeated prompts can identify a missing connector, an unclear project instruction, or an overbroad task. The goal is not to eliminate every prompt. It is to make the ones that matter easier to recognize.

A branch is a review surface, not a safe zone

Cloud threads use their own branches and repository copies. That gives reviewers a specific change set and limits direct concurrent edits to the same checkout. It does not prevent one thread from creating a logically incompatible change on its branch, nor does it mean conflicts disappear when separate work reaches a shared codebase. Anthropic’s launch post and current docs describe pull requests as places where proposed changes can be reviewed. The docs also provide actions to resolve conflicts or prompt a thread to fix CI and respond to comments.

View image detail

A proposed coding change receives a visible review check.

Actual size

Choose Actual size to read the graphic closely.

Treat each thread’s branch as an inspectable proposal. Ask it to report the files changed, commands run, tests passed or skipped, assumptions made, dependencies added, and any known gap. Then compare that report with the actual diff and test output. A summary is useful, but it is still a statement from the same work process that produced the code. For high-impact changes, run independent checks or review the code without relying solely on the thread’s narrative.

An academic analysis offers useful context for this review boundary, with an important limit: it studied earlier AI-assisted pull-request workflows, not Claude Code Projects. Chung and Hassan analyzed 29,585 completed pull-request lifecycles across five tool families, including 338 Claude Code pull requests in the sample. The study separates who initiated a pull request from the actor recorded at merge. It reports that agent-initiated work and merge control do not necessarily belong to the same actor. The authors also caution that an automated merge log can identify the executor without revealing who or what authorized the decision. The data is concentrated in 2025 and drawn from repositories already using AI coding tools, so it cannot establish how the new Projects beta performs. It does support treating generated branches as proposals and naming a person responsible for review and release decisions (the study and its methods).

Test evidence should answer the acceptance question. “Tests passed” is incomplete unless you know which tests ran, against what change, and whether the tests cover the relevant behavior. If a thread cannot access a service or test environment, it should say so. A synthetic result, mocked service, or skipped suite must not be presented as production evidence. Make the final review record say which checks are required and which are optional for the task.

When multiple threads touch a shared contract, review the combined set as a system. A reviewer can examine each pull request and still miss the fact that the new API field is required in one service and optional in another. Use a contract test, integration suite, or explicit cross-branch checklist to inspect the seams. Where work is tightly coupled, sequence it: settle the contract first, then assign implementation branches. It can be faster to parallelize independent testing or documentation after the interface is fixed than to ask three agents to invent the interface independently.

Decide who resolves overlap before it appears

Parallel work often reveals that task boundaries were less independent than they looked. Two threads can edit the same configuration, use different names for the same setting, or disagree about which test is authoritative. A merge conflict is visible; incompatible assumptions may not be. In both cases, someone needs the authority and context to choose the intended direction.

View image detail

A work tree exposes nested dependencies that need an owner.

Actual size

Choose Actual size to read the graphic closely.

Choose one integration owner for the pilot. That person does not need to write every line, but should understand the shared design and decide whether to accept a conflict resolution, ask a thread to revise its branch, or merge work in a new order. Do not ask a coordinator to “make all the PRs green” without stating the source of truth for any conflicting behavior. Tests can be wrong or incomplete, and CI cannot decide which product behavior is desired.

An operational pattern is to establish an integration branch or a sequence of PR reviews only after the relevant owners agree on a stable contract. Threads then target branches according to that plan. If the project guidance includes the starting branch and PR expectations, those become visible to each new thread, but a human still verifies the branch target. The guide notes that teams can tell threads which branch to start from and when to open pull requests. The existence of a setting or instruction does not remove the need to check the pull request’s base branch.

If a thread requests a conflict resolution, read the specific conflict rather than accepting a broad instruction to choose one side. Conflicts often encode a product decision: whether to preserve compatibility, which default to use, or whether to migrate existing data. Ask for a proposed resolution with the relevant requirements and test implications. Have the owner confirm that proposal before it becomes the new source of truth.

Local Remote Control changes the boundary, not the need for one

The current Claude Code Projects guide describes a local thread option through Remote Control. It is meant for work requiring something on the owner’s device, such as a local database, emulator, or API behind a VPN. The documented flow requires Claude Code 2.1.280 or later, connecting the relevant folder, and explicitly allowing the specific thread. Work continues only while that computer is awake and Remote Control remains active. In a Git repository, the user can choose a worktree to keep concurrent local threads apart.

View image detail

A person tends a locally connected work environment.

Actual size

Choose Actual size to read the graphic closely.

The local thread has the machine’s files, tools, connectors, and Claude Code settings; it does not simply use the cloud environment. It begins with project instructions but not project memory files loaded. That difference deserves its own review. A task that can see a local database may expose or modify records the cloud worker cannot reach. A device emulator may be connected to real test accounts. A command that is safe in a disposable cloud sandbox may be risky on a developer’s machine.

Before allowing a local thread, specify which folder it may use, whether it should get its own worktree, what data is synthetic or production, and which commands require human approval. If the device sleeps or the app exits, work pauses or stops. Do not set an expectation that the local job will finish in the background just because cloud threads can keep going after the laptop closes. The execution modes have different availability and access properties.

Keep the reviewer from becoming the new bottleneck

If several threads complete around the same time, review capacity can become the limiting factor. More parallel output is useful only when the review path can absorb it. A team can manage that queue by limiting batch size, asking for smaller pull requests, aligning thread scope with reviewer specialties, and using reliable automated checks to catch repeatable issues before a person spends time on them. Those are workflow choices for the team, not automatic guarantees of the coordinator.

View image detail

A human monitors the review path as several proposals arrive.

Actual size

Choose Actual size to read the graphic closely.

Do not optimize the number of open pull requests. Optimize for decisions a reviewer can make confidently. Each request should state one purpose, link back to its acceptance criteria, name tests, and call out unresolved assumptions. Threads can be asked to keep separate concerns apart. The review owner can stop a batch from expanding if the work arrives faster than it can be examined.

A useful pilot measures review time as carefully as generation time. If the project reduces the waiting period but doubles the time spent understanding changes, the team has learned that its handoff improved while its review system did not. That result suggests a different fix: improve test evidence, clarify requirements, or reduce overlap. Adding more threads would likely make the queue worse.

When cost matters, compare the same accepted outcome across workflows. Rise’s guide to estimating the cost of an AI task explains why model usage alone misses retries, tools, review, and repair.

Reviewers also need a stopping rule. Decide in advance whether a failed test, missing environment, unexpected dependency, broad permissions request, or unplanned data migration means the thread must pause. Without a stopping rule, people may approve a risky action simply because a deadline is close and a thread is waiting. The easiest way to make approval safer is to define the cases that cannot be approved automatically.

A practical preflight and closeout checklist

Before starting a project batch, confirm that the beta is available to the account and that the chosen repository and GitHub permissions meet the current product requirements. List the goal, acceptance criteria, exclusions, repository scope, thread limit for this first trial, and the owner for each decision. Confirm where instructions live and which environment a thread will use. Choose a task with a stable contract and identify files or systems that must not be touched.

Before the coordinator starts threads, review its proposed work split for dependencies, duplicated ownership, and tasks that need a shared decision. Give each task a testable output. State which actions are allowed automatically and which require an approval. If the work involves local Remote Control, verify the required version, exact folder, worktree behavior, and device uptime. If the account or repository access is missing, stop instead of substituting an unapproved source or workspace.

For each completed thread, check its diff, branch, test evidence, changed dependencies, access requests, assumptions, and remaining gaps. Ask the responsible reviewer to accept or reject the proposal. Have an integration owner examine interactions among accepted branches. Preserve required CI, code-owner review, or other existing controls. An explicit maintainer should decide whether to merge or release.

After the batch, note how much human steering and review it took, which instructions were misunderstood, which tasks were genuinely independent, and whether memory needs a correction. Update the project instructions only after the owner checks that the revised rule is accurate. This closeout is how a team can make the next batch less confusing without treating an anecdote as proof of safety.

The boundary that makes parallel work usable

The design promise of Claude Code Projects is coordination. One conversation can hold related work, coordinate threads, and show which work needs attention. The way to use that promise responsibly is to keep the team’s decisions visible at the points where authority changes: task definition, repository access, thread approval, pull-request review, conflict resolution, and merge.

There is no single human checkpoint that covers all of these. The person who writes the initial goal may not be the person who owns a production repository. The person who approves a thread’s access may not be the right reviewer for the code. The reviewer may not have release authority. Make those distinctions explicit for the work you assign, even if the same teammate ultimately holds every role.

A small, well-defined pilot is a good place to test whether the new coordinator fits. Keep the work bounded, measure the work of review and integration, and stop when the thread’s request exceeds the approved scope. If the team can see each proposed change, confirm its evidence, and make the final shipping decision deliberately, parallel threads may give it a useful way to organize long-running work. If those decisions are hidden or nobody has time to make them, the coordinator has not made the process safer by itself.