I can sustainably run three coding agents at once.
I've tried more. Four is where I start rubber-stamping work I haven't actually read, and rubber-stamping is just a slower way to ship a bug. So three is the number. Not because of my machine, my context window, or the model I'm using. Three is where my ability to verify what comes back runs out.
That number is the whole point of this series.
The bottleneck moved, and it didn't disappear
AI has reduced the cost of producing code. It did almost nothing to the cost of deciding whether that code is correct, safe to deploy, and consistent with everything around it.
Those were always two separate jobs. Writing code just happened to be expensive enough that it obscured the second one. Now that producing a thousand lines costs a few minutes, the verification work is the entire job, and it's a job that still runs at human speed.
This is why "AI made our engineering team 10x faster" claims tend to collapse under a follow-up question: faster at what? Generating candidate code, yes. Enormously. Getting reviewed, tested, integrated work into production is a different measurement, and for most teams, the bottleneck has moved.
Every tool I use exists to raise that ceiling
None of the tooling in my setup is about generating more code. Generating code is largely solved with a good system prompt and the right supporting documentation. All of it is about raising how much I can responsibly accept, and each piece reimposes an engineering practice that AI made very easy to skip:
The system prompt and skills carry standards. The conventions a codebase expects shouldn't live in my head or get retyped into a prompt every session.
Plannotator puts a human gate in front of the work. I approve the plan before there's code, and I review the diff before it moves.
git worktrees give each agent its own isolated copy of the repository. Three agents editing one working directory is not parallelism, it's a merge conflict with extra steps.
herdr gives me visibility across all of it: which worktrees are live, which tasks are still open, and what agents are waiting on me. Without that view, the third agent isn't a productivity gain. It's something I forgot about.
Standards, review gates, isolation, and coordination. Read that list without the tool names and it's just competent engineering practice. That's the argument I'll be making for the next four installments.
The part teams don't want to hear
If your engineering practices are weak, AI doesn't route around them. It finds them.
A team with no shared conventions, thin code review, and no isolation between changes can't safely run three agents. It can barely run one, because every generated change lands in a place where nobody can tell quickly whether it's right. The practices that felt like overhead when a human wrote 500 lines a day are the exact practices that determine your throughput ceiling when a machine can write 2,000.
The teams pulling real gains from this aren't the ones with the best prompts. They're the ones who already had strong review, good test coverage, and clear conventions, and who now get to point a very fast tool at a codebase that can absorb it.
Discipline isn't what slows you down. It has become the meaningful factor that determines how fast you can sustainably go.
Over the next four installments I'll go through each tool: what it does, where it earned its place, and what broke before I had it. Then I'll close with the client engagement all of this came out of, including what changed when the team rolled off and I was the only one left reviewing anything.
Hit reply and tell me your number. How many agents can you actually run before you start approving work you haven't read? I'd like to know whether three is typical or whether I'm the slow one.
P.S. - If you're running one agent and it already feels like too much to review, that's not a tooling problem yet. That's a signal about the codebase.