SpotOn: How I Run an AI Team of One

Everyone’s selling the same dream. Spin up fifty agents, drop one line into Telegram, and a few of them wake up, talk to each other, and out comes the result. Code and all. I could build that. But I won’t.

That thing gets nowhere near a team. It’s a machine for stamping out slop.

Don’t get me wrong. AI made me much faster. It let me start things I’d never have dared to start alone. One person pushing firmware, app, ML, and a PCB at the same time used to be impossible, and now most of the first draft is written by an AI team. All of that is true.

What I don’t hand off is exactly one thing. The parts I have to know, and the parts I decide. Those I keep, understood, all the way through. So the shape of a team of one isn’t set by autonomy. It’s set by two things: what each task costs when it goes wrong, and whether I’m passing its output on with real understanding.

The cost of failure sets the team

When I first split the agents up, I split them by “what kind of work is this.” Research, coding, review. That axis broke fast. The real dividing line was somewhere else. How expensive is this task when it’s wrong.

Market research, competitive audits, doc drafts are cheap to get wrong. One subagent talks nonsense, and it’s one voice out of fifteen, filtered out at the synthesis step. So I spread this work wide. One orchestrator throws the job at a fan of subagents and gathers the results back.

Coding sits at the opposite end. Let two agents touch interdependent core code at once and they step on each other’s assumptions. The ABI drifts, shared state breaks, and the merge turns into hell. Errors don’t get filtered here; they compound. So there’s always exactly one coding agent. A single author.

There’s a second reason for the single author: it’s the only way I can still follow the code later. Two of them, and I’m the first to lose track of what happened.

Read wide, write in one lane

I’m not the only one doing this. Anthropic and Cognition landed in the same place: fan the reading out in parallel, keep the writing to a single thread.

For a solo builder the reason just bites harder. On a team, a broken parallel-coding session gets cleaned up by someone else. My someone else is me. With no slack to undo things, I’d rather never create the place where errors merge in the first place.

The cost structure backs it up too. One research round burns more than ten times the tokens of a coding session. Of course it does, since fan-out runs fifteen or sixteen agents at once. That’s a lot of waste, and all of it sits on the cheap side, the side where a wrong answer gets filtered anyway. The expensive coding stays thin. Choosing where the waste piles up is the design.

Green but wrong

Splitting work by cost doesn’t finish the job. Cheap or expensive, the code an agent hands back can still be wrong. So verification comes next. No compromise here. I stack the cheap checks first: compile, tests, then adversarial review.

There’s a reason the cheap ones go first. Code passes the tests and is still wrong. Green but wrong. That contract bug I mentioned in part 2 was exactly this: two modules broke a promise they’d made to each other. Here’s a different angle on it. The tests waved that bug straight through. What caught it was the adversarial reviewer I’d bolted on because I didn’t trust the tests. It got caught because I’d placed verification to match the failure mode.

Green-but-wrong code, and reviewers that fool themselves, are both documented failure modes. So verification runs cheap-first, and adversarial.

Review isn’t approval, it’s knowing

This is the heart of it.

This is the one thing I said I don’t hand off. There are three human checkpoints: approving the plan, the verify gate, and the moment right before the merge. At those three I don’t just stamp and move on. I hold until it makes sense to me.

A big design decision only goes through while I understand the architecture. If I don’t get it, it doesn’t pass. I ask again, read, break it down. However long that takes.

What happens when fifty agents talk among themselves and finish the thing? You get speed. And nobody knows what got built. I refuse that trade. The AI team can write most of the draft, but the decisive parts and the big design are things I make sure I know. The moment a person stops knowing, the team turns into a slop machine.

Where this arrangement breaks

Honestly, the model leaks in a few places.

Knowing has a cost, so the real bottleneck is me. Bolt on a hundred agents and the queue for understanding and approving is still one person. The urge to delete that bottleneck is the doorway to the slop machine.

There’s a spot where I cave, too. Anything that looks trivial, I pass without understanding. The danger is drawing the line between “trivial” and “decisive” in the wrong place. Something I waved through as trivial turned out to be architecture later.

A long single-author session forgets earlier decisions: context rot. And when adversarial review becomes a formality, green-but-wrong walks straight through, and the confidence verification gave you goes fake.

Irreversible physical decisions, like placing an order or signing a contract, sit entirely outside this model. That’s the ground the last post covered.

Spine before roster

Before you worry about who to spin up, build how you’ll catch the wrongness. Verify spine before roster.

So every time I want to add an agent, I ask two things. How expensive is this task when it’s wrong? Cheap, spread it out. Expensive, narrow it to one lane. And am I passing this on with real understanding? If it’s a decisive part, there’s no approval without it.

Adding a sixth agent is easy. Understanding what the sixth agent did, well enough to sign off on it, is the part that doesn’t scale. That’s the real ceiling, and I keep bumping into it at the merge queue, one review at a time.