I Stopped Giving Claude Code One Task at a Time

I run more agents than I have hands, and the bottleneck moved. It is no longer how fast code gets written. It is how fast I can decide whether a diff deserves to reach my users. Once I stopped feeding Claude Code one task at a time and started running several agents against separate worktrees, my throughput jumped and my review queue became the actual product. That trade is worth making, but only if you rebuild your process around the new bottleneck instead of pretending it does not exist.

Here is the concrete shape of my week. Tadam needs a fix in the Hebrew ad generation pipeline. Brainers Club has a members feed regression. Arvuyot Yashir has a migration waiting. Luma.ai has a billing edge case. In the old model those are four sequential sessions, and three of them wait while I babysit the first. In the parallel model each one gets its own branch, its own worktree, its own agent with a narrow brief, and I move between them as a reviewer rather than a typist.

One engineer, one task was a constraint, not a law

The rule existed because a human can only hold one problem in working memory at a time. Context switching cost real money, so we built process around avoiding it. That constraint is now partly gone. The agent holds the context. I hold the decision. What I lose in depth per task I gain many times over in tasks that get finished the same day instead of the same month.

The mistake people make is assuming this scales linearly. It does not. Two agents feel like a superpower. Five agents feel like managing five junior engineers who never ask questions and never tell you they are stuck. The difference between those two experiences is entirely about what you set up before you press enter.

What actually broke when I went parallel

Nothing exotic. The failures were boring and repeatable, which is what makes them fixable.

• Two agents editing the same shared file in the same repo. Solved with git worktrees, one per agent, never a shared checkout.
• An agent quietly deciding that the fastest way to make a test pass was to weaken the test. Solved with an explicit rule that a failing test is evidence, not an obstacle.
• Migrations. A schema change written by an agent that never saw the real production rows is the one class of work I still do with my own eyes on the data first.
• Review fatigue. Four green diffs in an hour feels like success and reads like a rubber stamp. This is where real bugs slip into production.
• Half-finished branches piling up. An agent that stops at 90 percent leaves you worse off than one that never started, because now you own an unfamiliar diff.

The brief is the whole job

When I write for one agent I can be sloppy and correct it in the next turn. When I have four running, every correction costs a context switch, so the brief has to carry the weight up front. My briefs now say what done looks like, which files are in scope, what proof is required before it reports back, and what it must not touch. That last part matters more than the first. An agent with no stated boundary will refactor something adjacent because it looked untidy, and now your two line fix is a two hundred line review.

An agent that finishes the wrong task fast is not productivity. It is a diff I have to read twice and then throw away.

How I decide what runs in parallel and what does not

1. 01Independent and reversible goes parallel. Copy changes, component work, bug fixes with a clear repro, test coverage, refactors inside one module.
2. 02Shared surface goes sequential. Anything touching auth, billing, row level security, or a schema that live customers depend on gets one agent and my full attention.
3. 03Unclear scope does not go to an agent at all. If I cannot describe done in two sentences, the work is not ready to delegate. I brainstorm it first, alone or with Claude, and only then hand it off.
4. 04Anything I would be embarrassed to explain to a paying customer gets manual verification in the running app, not just a green suite.

Review became the skill I had to relearn

I teach 600 plus students at nCode and this is the part almost nobody arrives with. They optimize prompts. They should be optimizing judgment. When four diffs land in an hour, reading them the way you read your own code does not work, because you did not build the mental model while writing. So I read differently now. I check the boundary first, then the failure path, then whether the tests actually assert behavior rather than existence. I read the diff as an adversary looking for what it lets through, not as an author looking for what it got right.

The practical rule I hold myself to across all seven products: nothing merges on a green gate alone. Green means it did not obviously break. It never means it works. For anything user facing I open the running app and look at the actual screen, in Hebrew, on a real device width, before it goes anywhere near production.

What this actually bought me

Seven live products with 10,000 plus paying users and members between them, run without a team. Not because agents write better code than a good engineer, but because the cost of trying something dropped far enough that I ship the small fixes I used to postpone forever. The backlog items that were always worth doing and never worth a whole afternoon now get done in the gaps between other work. That is the real change. Not superhuman output, just a much lower floor for what is worth starting.

If you are running one agent and it feels productive, do not immediately jump to five. Go to two, and fix everything that breaks. The failure modes are cheap to learn at two and expensive to learn at five, and they are all the same failure modes. Parallel agents do not remove the need for engineering discipline. They price it correctly for the first time.