One Agent at a Time Was the Bottleneck
For most of the past year, my AI workflow looked like everyone else's. Open the terminal, start an agent, give it a task, watch it work. Then wait. Then review. Then give it the next task.
It was already faster than doing everything by hand. But the shape of the work had not changed at all. It was still a single line: one task, one agent, one working copy of the repo, one thing happening at a time. The agent got faster. I did not.
Two problems kept showing up.
The first was fear of the working copy. There is only one checkout of a project on your machine. Letting an agent loose on it means every experiment is happening in the same place your real work lives. So you play it safe, you keep tasks small and timid, and you babysit every step.
The second was serialization. A client site needs the contact form fixed, the blog dates reformatted, and a new section built. None of those touch each other. There is no technical reason they cannot happen at the same time. But with one agent in one repo, they queue up behind each other for no good reason.
What Orca Actually Changes
Orca gave each agent its own git worktree.
That sounds small. It is not. A worktree is a real, separate checkout of the same repository, on its own branch, in its own folder. Four worktrees means four agents can work on the same project at the same time without ever seeing each other's files.
The fear goes away, because nothing an agent does touches my main checkout. If a run goes sideways, I throw the worktree away. Nothing to unwind, nothing to git reset, no half-finished refactor sitting in the branch I actually need.
And the queue goes away, because independent work stops waiting its turn. The contact form fix, the date formatting, and the new section all run in parallel, each in its own lane, each producing its own diff I can review separately.
How I Actually Run a Day Now
The pattern I have settled into looks less like "using AI" and more like running a small team.
Plan in one place, execute in many
I start in a single context and get the plan right. What are the actual pieces of work, and which ones are genuinely independent? That question used to be academic. Now it directly determines how much runs at once.
Splitting work badly is the main way this goes wrong. Two agents editing the same file in different worktrees produce two diffs that fight each other at merge time. The planning step is where you earn the parallelism.
One agent per unit of work
Each piece gets its own worktree and its own agent, scoped tightly enough that it can finish without needing to ask me a question halfway through. Small, well-bounded tasks are what make this work. A vague brief just fails four times in parallel instead of once.
Different models for different jobs
Not every task deserves the same horsepower. Mechanical work goes to something cheap and quick. Architecture decisions and gnarly debugging get the strongest model I have. And when something matters, I have a second model review the first one's work adversarially, specifically trying to find what is wrong with it.
Getting a genuine second opinion from a different model has caught things I would have shipped. That alone justified the setup.
Review is the real work now
This is the part nobody warns you about. When four agents are producing changes at once, you are no longer the bottleneck at writing. You are the bottleneck at reading.
I now spend most of my time reading diffs, questioning decisions, and sending work back. The job shifted from author to editor. If you are not willing to actually read what comes back, orchestration just helps you ship bad code faster.
Handoffs instead of restarts
The other thing worth mentioning is handing a task from one agent to another with its context intact. Previously, moving work between sessions meant re-explaining everything from scratch. Now a worktree carries its own state, and I can pass it along: one agent investigates, another implements, a third QAs it in a browser.
The Honest Trade-Offs
I am not going to pretend this is free.
Orchestration has overhead. Deciding how to split work, spinning up worktrees, and merging four branches costs real time. For a one-line fix it is pure loss. The break-even point is somewhere around three genuinely independent tasks. Below that, just run one agent.
Parallel failure is a real thing. A bad plan does not fail politely in one place. It fails in four places at once, and now you have four diffs to throw away instead of one.
You must read everything. Volume goes up, so the temptation to skim goes up with it. That temptation is the whole risk. Everything I ship still gets reviewed by me.
It does not make you a better developer on its own. It makes an already-clear plan execute faster. It does absolutely nothing for a plan that was never clear.
Why It Matters for Client Work
At The Boring Solutions I am usually working across several client projects at once. Before, context switching between them was the expensive part. Now each project can have work in flight in its own isolated space, and switching between them means switching which diff I am reading rather than which mental model I am rebuilding.
The result is not that I write more code. It is that more of my day goes into the parts that actually need judgment: what to build, whether the approach is right, and whether what came back is good enough to put in front of a client.
That is the shift. Less typing, more deciding.
Where I Am Taking It
I am still tuning this. The open questions are mostly about where the ceiling is: how many lanes are genuinely useful before review becomes the hard limit, and which categories of work should never be parallelized at all.
But the direction is settled. Running one agent at a time now feels like the same downgrade as going back to a single monitor. Technically fine. Obviously slower.
If you are already comfortable with AI agents and still running them one at a time, isolated worktrees are the next step worth taking.