Refactoring

The most repetitive agentic task is also the easiest to parallelize: same task spec, different scope. "Update all logger calls to use the new structured logger" applied across packages A through E is five identical jobs with five independent codebases. Five panes, five agents, one-fifth the wall time.

why this is a pane-shaped problem

each package is independent

When the refactor scope is one package at a time, each agent operates in total isolation. No shared state in-flight. No risk of agents writing to the same file. The only coordination happens at merge — and by then each package is already clean.

the spec is already written

A refactor has a clear definition of done: before-and-after patterns the agent can verify. Write the spec once in a markdown file. Copy it to every pane. The agents do the mechanical work. You review diffs.

walkthrough

→ Step 1. Write one task spec in refactor.md at the repo root. Include the before-and-after pattern, the files or directories to touch, and any patterns to avoid. The more precise the spec, the less the agent improvises.
→ Step 2. For each package, open a new pane in Pane. Each pane gets its own worktree on its own branch — Pane handles that automatically. Name the panes after the packages (e.g. refactor/pkg-auth, refactor/pkg-billing).
→ Step 3. In each pane, launch Claude Code and point it at refactor.md. The spec is the same; the working directory is different.
→ Step 4. Wait. Move between panes with ⌘↑ / ⌘↓ to monitor progress. Desktop notifications fire when an agent finishes or gets stuck.
→ Step 5. Review each diff with ⌘D. Commit each package independently with ⌘K. Rebase the next package branch on the previous commit if packages share a dependency boundary.

variation: best-of-N

If you are uncertain about the right approach for a refactor, spawn three agents on the same package from the same base branch — three worktrees, same spec. Review all three diffs and pick the result you like best. Discard the other two worktrees. This costs three times the API tokens but produces a better outcome when the task is ambiguous. Emdash makes best-of-N first-class; in Pane you do it manually by creating three worktrees from the same base branch.

when this breaks

Parallel refactoring breaks when packages share interfaces that the refactor changes:

→ Shared interface changes. If the refactor modifies a type or function signature that every package imports from a shared library, sequence the changes top-down. Refactor the shared library first; let it land; rebase each package branch on top.
→ Cross-package imports. When package B imports from package A and both are being refactored in parallel, package B's agent will work against the pre-refactor version of package A. Sequence these, or accept a rebase after package A lands.
→ Migration scripts. Database migrations, code-generation scripts, and similar artifacts with global side-effects should always be sequenced — one per branch at a time.

- - - - - - - - - - - - - - - -

See also: Pane vs Emdash for a comparison of the best-of-N pattern across tools.

orDownload*Windows SmartScreen warningDirect downloads can show a SmartScreen warning while Pane is unsigned. Pane is fully open source, so you can audit the code and build from source yourself.1. Click More info2. Click Run anyway3. Continue the installerThe PowerShell install downloads the official release directly and avoids most browser download friction.

Paste that in PowerShell.MacLinux