After 15 years of VS Code, I gave my backlog to parallel agents in Orca

2026-11-13来源 dev.toEnglish
After 15 years of VS Code, I gave my backlog to parallel agents in Orca

I have used VS Code for fifteen years. Orca is the first IDE that made me consider leaving it.

Orca is an open-source desktop app for CLI coding agents: Claude Code, Codex, OpenCode and a long list of others. You add a repo, and every task gets its own git worktree with its own agent inside. You watch all of them from one window and review each result as a pull request.

This is how I run it on my personal finance app, what broke in the first week, and the rules I added because of it.

One task, one worktree, one agent

The core idea is simple. Each agent works in its own folder, on its own branch, so two agents never touch the same files. When one finishes, you get a PR. When one needs you, you get a notification.

Orca's worktree search: one Claude Code agent per issue, each in its own worktree and branch

My first run was two GitHub issues, launched as two worktrees in about two minutes of clicks:

  • The first agent fixed a bug in how my app reads broker screenshots. PR opened in 2 minutes 31 seconds, 15 tests passing. I reviewed it and merged it after CI went green.
  • The second agent stopped and asked. The issue pointed to a spec section that, as it turned out, still lived in an unmerged PR. Once I told it to write the spec from the issue text, it opened its PR in 5 minutes 29 seconds.

Issues are the briefs

Orca's Tasks view pulls the GitHub issues of every repo you add into one table. Each row has a Start button.

Orca Tasks view listing the open GitHub issues of one repo, each with a Start button

Start opens the Create worktree dialog, and the issue URL becomes the agent's first prompt.

Create worktree dialog started from a GitHub issue: branch from origin/main, agent Claude on Sonnet

One tip before you press Start anywhere: the default view mixes every repo you added, upstream forks included. Mine showed 250 pages of other people's issues. Filter by project first.

A strong model plans, a cheap model executes

I ask a top model (Fable 5.2 or Opus) for the plan and the task split. Every agent that writes code runs on Sonnet.

You set this once. Settings, Agents, Claude, Model: Sonnet. Orca then appends --model sonnet to every launch, so there is no per-task choice to forget.

Orca Settings, Agents: Claude as default agent, model Sonnet, and the arguments Orca adds to every launch

The status bar shows how much of your Claude plan you have used. Two Sonnet agents working for 22 minutes moved it from 40% to 41%. Measure that meter per session. A token count alone hides how much faster a bigger model burns the same plan.

Launching from the command line

Orca ships a CLI, available in every Orca terminal. Once a repo is added, one line creates the worktree, starts the agent and sends the brief:

orca worktree create --repo id:<repoId> --name fix-hipotecas-colours \ --agent claude --model sonnet --prompt "$(cat prompt.txt)" --json 

That is how I dispatch work now. I describe the problem to Claude in plain language, it writes the briefs, and it launches the agents in Orca with that command. I come back to review PRs.

What went wrong, and the rule each one gave me

1. The agent offered to merge its own work

When an agent finishes, Claude Code suggests "merge it" as the next prompt. Accepting it by reflex is one Enter away.

Rule: every brief ends with "open a PR, never push to main, never merge". I merge myself, after CI and after reading the diff.

2. Nothing stopped an agent from pushing to main

My repo is private on a free GitHub plan, so GitHub offers no branch protection. Orca's default permission mode is Full access, which launches Claude Code with --dangerously-skip-permissions.

Rule: a pre-push hook in .git/hooks/pre-push that rejects refs/heads/main. Every worktree of the repo shares it.

#!/bin/sh while read local_ref local_sha remote_ref remote_sha; do if [ "$remote_ref" = "refs/heads/main" ] && [ -z "$ALLOW_MAIN_PUSH" ]; then echo "Blocked: push to main. Set ALLOW_MAIN_PUSH=1 to override." exit 1 fi done 

3. The agent worked on old code

One of my local clones was 484 commits behind origin. An agent can only report on what the clone knows, and a stale clone gives you a confident, empty answer.

Rule: branch every worktree from the remote. orca repo set-base-ref --repo id:<repoId> --ref origin/main.

4. A brief that links to a missing doc stalls the agent

That second issue cited a spec section sitting in an unmerged PR. The agent did the right thing and asked, but it sat waiting until I answered.

Rule: paste the context into the issue. A link to another doc is fine as extra reading, never as the only source.

5. A green deploy that never reached prod

A colour fix finished with the agent reporting "deploy succeeded, it's in prod". I opened the page: same colours. The deploy job had passed, but my GitOps controller never rolled out the new image. The agent had trusted the last green signal it saw.

Rule: before an agent says done, it checks the version actually served.

6. One colour task became three infra fixes

The same agent, in the same worktree, went on to fix the deployment, then a duplicate database migration id, and merged one of those PRs without waiting for CI. The "never merge" line from the original brief got lost further down the same conversation.

Rule: when the work changes type, open a new worktree with a new brief.

Gotchas worth knowing on day one

  • Each new agent in Full access mode shows Claude Code's bypass-permissions warning and waits for you to accept it once. Your first parallel run stalls on that screen.
  • Config that lives in shell aliases or .zshrc does not reach agents that Orca launches, because Orca runs the binary directly. Put env vars and hooks in ~/.claude/settings.json.
  • Never pin a hook to a versioned Homebrew path like /opt/homebrew/Cellar/node/26.0.0/bin/node. Homebrew deletes it on the next upgrade. Use /opt/homebrew/bin/node.
  • New worktrees only get tracked files. Anything gitignored in your main checkout (.env, local helpers) has to be copied in.
  • Turn on system notifications for Orca. The "agent finished" and "agent needs you" alerts are half the point.
  • Screenshots work: paste one into the agent prompt with Ctrl+V (not Cmd+V) in the terminal, or drag the file in.

Start in fifteen minutes

  1. Install Orca from onorca.dev and add one repo.
  2. Settings, Agents: pick Claude Code and set the model to Sonnet.
  3. Add the pre-push hook and set the base ref to origin/main.
  4. Pick two small, well-described issues and press Start on each.
  5. Review both PRs yourself. Merge only after CI.

Will I stay on Orca? Ask me in a month.

What is the first rule you would add before letting an agent loose on your main branch?

Tested on Orca 1.4.253 and 1.4.255 on macOS, with Claude Code on Sonnet 5.5.

原文:https://www.a8q9.cn/en/article/after-15-years-of-vs-code-i-gave-my-backlog-to-parallel-agents-in-orca-68a11a.html

相关文章