I have a team — only one of us is human

Building my own products now, I actually already have a very small “team.”

ChatGPT and Claude mostly handle thinking: discussing the product with me, researching questions, breaking down plans, helping me judge.

Codex is currently the workhorse of development; most of the implementation inside the repo is done by it.

Claude Design handles design; Claude Code has lately mostly been bringing Claude Design’s results into the product. Choosing it for that is very practical too: the two are in the same Claude ecosystem, so design handoff is relatively smooth.

I’m the only human.

My work has changed because of it. I handle specific implementation myself less and less, and spend more time deciding: who to give this to, which tasks can move forward together, where a second agent should review, and when conflicts arise, which version to keep.

Using several AIs is easy. Getting them to really work like a team is much more trouble.

By default, agents don’t know what other agents are doing

In a human team, even when collaboration is bad, at least everyone knows there are colleagues next door.

Agents aren’t like that.

Codex doesn’t naturally know what Claude Code changed in another workspace; when Claude Design reads the code repo, it doesn’t necessarily see changes on my computer that haven’t been synced in yet.

So when two agents give different answers to the same question, it isn’t necessarily because one is less capable.

They may simply not be looking at the same version.

The most obvious case I hit was during a design handoff, when the same set of design rules kept changing on different lines of work. In the end, the same component had two opposite conclusions in two handoff documents.

A smarter model can’t solve that kind of problem.

At heart it’s already a team-collaboration problem: versions, division of labor, dependencies and handoffs.

Design tasks are harder to parallelize than they look

This is especially obvious in design work.

On the surface, I might be working on three completely different pages at once. By product feature, they’re independent of each other, perfect for running in parallel.

But the boundaries of design don’t line up with the boundaries of pages.

All three pages might simultaneously touch Button, Select, Dialog, typography, spacing, responsive rules, design tokens, even global CSS.

So a very ordinary page adjustment may end up changing a global component.

The boundaries of design tasks often aren’t the same as the boundaries of pages.

That also means judging whether two agents can start at the same time can’t rest only on “are these two different requirements.”

You also have to look at whether they touch the same shared layer.

If one agent is changing the global Button while another is redoing a page that uses Button heavily, the two tasks have nothing to do with each other in product structure, but are highly related in implementation.

In that case, forcing them to run in parallel probably just pushes the conflict further down the road.

Opening several chats isn’t the main problem; several “final versions” are

Splitting one requirement across several chats isn’t a problem in itself.

I can discuss the product structure in one chat, look at design in another, and do code review in a third. Many readers of the same material don’t automatically create conflict.

What really needs care is several places starting to maintain the same “final answer” at once.

For example, one chat produces a version of the design rules, another chat keeps editing the same rules based on an old version, and in the end both versions go into the code repo separately.

At that point the problem isn’t the number of chats.

It’s that the same shared content has several writers who don’t know about each other.

So these days I care more about whether the roles are clear:

who thinks and proposes, who actually implements, who reviews, and who closes it out at the end.

There can be lots of opinions; it’s best not to have many independent lines doing the final writing.

“The only human” now mainly manages three things

The first is ownership.

A task can pass through many agents, but it’s best to have one clear owner who carries it from start to finish.

Right now most development tasks are closed out by Codex; designs Claude Design produces are mostly handed to Claude Code to implement.

The second is shared surfaces.

Whether two tasks can run in parallel, I look at whether they both touch global components, design rules, base styles or other shared layers.

Different pages don’t mean the work is independent.

The third is dependencies.

If task B’s judgment depends on changes task A hasn’t finished, don’t pretend they’re two unrelated lines of work.

Either wait for A to finish, or explicitly have B continue from A’s result.

All of this is a lot like project management in a real team; the people have just been swapped for agents.

What I don’t need to manage so closely

I don’t intend to take back every Git operation myself just because I’ve started managing several agents.

How branches sync, how worktrees are created, how rebases are handled, how mechanical merge conflicts are resolved — coding agents know these better than I do.

What I need to manage is one level up:

why this task is being done; who owns it; whether it can run in parallel; what it depends on; what counts as product fact right now; and when there are two reasonable answers, who decides.

AI really does let me push more things forward on my own, but the work of coordinating hasn’t disappeared.

It’s just that I used to coordinate people, and now most of what I coordinate are agents.

When I’m about to open several agents at once now, I first confirm three questions:

will they modify the same shared layer? Does one depend on a result the other hasn’t finished? Who will ultimately be responsible for closing out each task?

If these three things aren’t clear, opening one more agent isn’t necessarily adding capacity.