One Person + A Fleet of Agents = A Product Studio

Facts and scope first: over the past six months, working alone (no team), I shipped 50+ Git repositories across TypeScript, Electron, Tauri, Go, Rust, and Swift. Among them: a desktop workbench past 4,000 TS files and 2,500 commits, a local-first AI image app live on the Mac App Store, several enterprise-grade platforms, and a dozen reusable agent skills.

I know how that number sounds. So let me say the important thing upfront: repo count and file count are approximately zero as a signal of ability. In the AI era, generating code is not remarkable. What’s remarkable is making generated code controllable, verifiable, and shippable. This post is about the latter — how one person organizes themselves into a studio.

Division of labor: I make judgments, agents execute, other agents verify

My daily toolkit is role-differentiated, not “whatever’s handy”:

Claude Code is the primary executor: CLI-first, hooks as deterministic add-ons, subagents for context isolation;
Codex is the second opinion: async in the cloud, dedicated read-only reviewer — different models have different blind spots. The same code yields only partially overlapping bug sets from two models; cross-model review is free blind-spot coverage;
Cursor handles in-editor micro-edits;
My own orchestration system runs pipeline work: 17 roles, 11 declarative workflows — triage, development, review, QA, acceptance, each in its lane.

The point isn’t the tool count. It’s where the human sits: I don’t write most of the code, but I write every task’s spec and acceptance criteria. I don’t review line-by-line, but I designed the machinery that makes agents review each other — and makes those verdicts trustworthy.

Three survival mechanisms

Commanding a fleet of agents alone, your biggest enemy isn’t insufficient model capability — it’s compounding uncertainty: 95% reliability per step leaves you 60% after ten chained steps. Six months distilled three mechanisms, each purchased with a real crash:

One: deterministic orchestration beats LLM improvisation. Agent-to-agent handoffs don’t travel as natural language; they travel as structured contracts — where to start (locus), what evidence shows a problem (signal), what counts as done (done), and whether completion verifies automatically or by a human (done-v). All four are generated at task intake. Natural-language handoffs add fresh uncertainty at every hop; structured specs turn “is it done” into a decidable question.

Two: never trust an agent’s self-report. “I finished, all tests pass” has zero standing in my system. The coordinator independently re-runs the tests (not the executor’s copy of the results), checks the Done Definition, verifies artifact completeness — only then is it a delivery. Overkill? Before this gate existed, I got burned by an agent swearing a feature was complete when it didn’t even compile. The model isn’t lying — it genuinely believes it finished. Self-evaluation bias is structural, and only independent verification hedges it.

Three: failures need graded recovery, not blind retries. First failure: standard bounce-back with logs — might be transient. Second: bounce-back plus a direction review — consecutive failures usually mean the approach is wrong. Third: decide between restart (wrong direction) and repair (wrong execution). Fourth: stop and escalate to me. Success rates on naive retries collapse after the second attempt, and infinite retries burn real money.

Costs and boundaries (anyone who skips this part is selling something)

This mode is not a free lunch. Three real costs:

Token consumption is heavy. At peak I burn tokens measured in billions per day. Cross-model review, independent re-verification, parallel agents — every layer of reliability is bought with inference cost. For me the trade is good — it’s what lets one person maintain 50 repos. Run your own numbers.
Seventeen roles isn’t capability — it’s cost. My most important lesson. Every added agent role adds context overhead and one more link that can distort information. The 17-role system was my laboratory: it mapped the mechanism boundaries of dispatch, acceptance, and recovery. But if I started over, I’d start with three roles and force every addition to justify itself.
“Production-scale” is not “in production.” Some of my projects have real users; others stopped at “complete form that runs.” Distinguishing these honestly is respect for the reader — and sobriety for myself.

What this series will cover

Studio Logs will keep recording how this studio actually runs: full teardowns of single projects from idea to delivery, real crashes and repairs, the cost ledger, and the complexity I built and then deleted — which usually carries more information than what stayed.

If you’re also using AI to multiply yourself into a team, take what’s useful. If you’re about to start, I hope this series saves you a few of the craters I climbed out of.

This is the first post of the Studio Logs series. Next: “My Agent Skills Toolbox: Ten Skills That Chain the Delivery Pipeline.”