Run multiple coding agents in parallel

Parallelize independent work

Parallel coding agents help when a project has several tasks that can be verified separately: bugs in disjoint components, each with its own focused tests; a documentation update; or independent read-only investigations. They do not make one tightly coupled change finish faster by default. If two tasks need the same files or depend on an unsettled interface, sequence them or make one depend on the other.

KalCode agents are real Claude Code, Codex, Cursor or Gemini CLI processes in terminal panes. They keep each provider's native tools, configuration and approvals. A multi-agent plan should therefore define the work just as carefully as a plan for several engineers.

Choose the right launch path

New agent can start several independent terminals, up to ten in one launch, in the current project folder. That is useful for research, review or deliberately sequenced work. Those panes do not receive separate Git worktrees just because the count is greater than one.

For simultaneous edits, create a Squad. Each member has a provider, account, model, role, task, optional dependencies and owned paths. Leave Isolated worktree on for members that will write concurrently. KalCode then creates a separate Git worktree and branch for that member; the project must already be a Git repository. Availability of workflow features by plan is listed on Pricing.

Give every agent a boundary

Write one outcome per member and list owned paths as repository-relative folders or files. Keep shared contracts with one owner, then make consumers depend on that work. A practical split might look like this:

An implementation prompt should repeat that boundary: “Only change the owned paths, preserve the shared API, run these tests, and report blockers instead of expanding scope.” Owned paths are coordination guidance, not a filesystem security boundary.

Handle overlapping edits early

KalCode surfaces likely ownership overlap from declared paths, provider-reported edits and Git worktree facts. Treat that warning as a reason to adjust the plan. Move one file to a single owner, add a dependency, or serialize that part of the work. Agents in separate worktrees can still produce branches that conflict when merged; isolation prevents live file clobbering, not semantic disagreement.

When an agent shares the project checkout, avoid concurrent writers entirely. Pause one agent before redirecting the other into the same files. If overlap grows beyond the declared scope, update the task instead of assuming the warning can be ignored.

Review before commit and merge

Agent Fleet can show a member's branch, files touched, uncommitted changes, commits ahead and whether Git predicts a conflict with the base branch. These are observed facts, not an automatic release decision. “Agent done,” “tests passed,” “ready to merge,” “merged” and “shipped” are different states.

Assign a person or a review agent to inspect each diff against the original task, reproduce important findings and run the relevant checks. Commit the isolated branch only when its scope is understood, then merge through your repository's normal Git workflow. KalCode does not treat an agent finishing as permission to merge or deploy by default.

Respect real provider and hardware limits

Every local agent is a real process. Your provider account can impose usage, concurrency, model or organization limits, and your computer still supplies CPU, memory, disk and build capacity. Start with two or three agents, watch terminal responsiveness and avoid making every member run the same expensive build. Add agents only when the next task is truly independent.

Learn the two-provider review loop in Claude Code and Codex together, or return to getting started to connect your first provider. New users can get the current desktop build from the official download page.