Use case

Refactoring

TL;DR

A refactor across several packages is the easiest job to run in parallel: one spec, applied to separate parts of the codebase. Commit the spec once, open one pane per package, and point an agent in each pane at it. Every pane has its own worktree and branch, so the agents never touch each other's files. Review and commit each package on its own, in a fraction of the time.

The most repetitive agent task is also the easiest to parallelize: the same spec, a different scope. “Switch every logger call to the new structured logger” across packages A to E is five identical jobs on five separate parts of the code. Five panes, five agents, a fifth of the wall time.

Why it fits panes

One package per agent means no shared state while they work.

With one package per agent, each works in isolation, with nothing shared while they run and no chance of two agents writing the same file. The only coordination is at merge, by which point each package is already clean.

A refactor also has a clear definition of done: a before-and-after pattern the agent can check. Write the spec once; the agents do the mechanical work; you review the diffs.

Walkthrough

Commit the spec, one pane per package, review and commit each.

  1. 1Write refactor.md at the repo root: the before-and-after pattern, which folders to touch, and what to avoid. The more precise it is, the less the agent improvises. Commit it, so every new worktree has a copy.
  2. 2Create a pane per package with Ctrl+N, named after the package, such as refactor/pkg-auth and refactor/pkg-billing. Each gets its own worktree and branch.
  3. 3In each pane, start your agent and point it at refactor.md and its package. Same spec, different folder.
  4. 4Watch progress from the sidebar; move between panes with Ctrl+Tab. A notification tells you when an agent finishes or gets stuck.
  5. 5Review each pane's Changes with Ctrl+Shift+B and commit it with Ctrl+Shift+K. If packages share a boundary, rebase the next branch on the previous one first.
Changes panel and diff tabsEvery touched file is listed with its line counts. Click one and its diff opens as a tab next to the agent.Pane 2.4.155, after the agent finished

Variation: best of N

Unsure of the approach? Run several attempts and keep the best.

If you're not sure how a refactor should go, run several agents on the same package from the same base branch and compare. In Pane's Create Pane dialog, set Panes to 2 to 5 and it makes that many worktrees at once. Review each diff, keep the one you like, and archive the rest. It costs more tokens but helps when the task is ambiguous.

Creating a panePick the repo, base branch and name, and Pane makes a worktree for the task.Pane 2.4.155 on Windows 11, repo inside WSL2

When this breaks

Shared interfaces and global side effects need an order.

  • → Shared interfaces. If the refactor changes a type or function every package imports from a shared library, do the library first, merge it, then rebase each package branch on top.
  • → Packages that import each other. If package B imports package A and both change in parallel, B's agent works against the old A. Sequence them, or plan a rebase after A lands.
  • → Global side effects. Database migrations, code generation and similar steps should run one branch at a time.

See also parallel features and Pane vs Emdash.

출처

정정
틀렸거나 오래된 내용이 있으면 알려 주세요. 수정하고 맨 위의 날짜를 갱신하겠습니다. GitHub에 이슈 열기
출처

자주 묻는 질문

또는
다운로드*
Windows SmartScreen 경고Pane에 서명이 없는 동안 직접 다운로드하면 SmartScreen 경고가 표시될 수 있습니다. Pane은 완전한 오픈 소스입니다. 직접 코드를 확인하거나 소스에서 빌드할 수 있습니다.1. 추가 정보 클릭2. '그래도 실행' 클릭3. 설치 계속PowerShell 설치는 공식 릴리스를 바로 받습니다. 브라우저 다운로드에서 생기는 번거로움도 대부분 피할 수 있습니다.npm 전역 설치
PowerShell에 붙여넣으세요.Linux

작성자 Parsa Khazaeepoul, Pane 공동 창업자. .