Tuned: What I Don't Hand Off to My AI Team

A lot of people are selling the same dream these days. You spin up fifty agents, send one line into Telegram, and a few of them respond on their own, talk among themselves, and produce the code as well. I could build something like that. I still won’t.

To me it is hard to call that a team. It is closer to a machine for stamping out slop.

I don’t mean that as a knock on AI. AI made me much faster. It let me start work I would never have dared to start alone. One person carrying firmware, an app, ML, and a PCB at the same time used to be impossible, and now an AI team writes most of the first draft. All of that is true.

There is still one thing I don’t hand off. The parts I have to know, and the parts I decide. Those I keep in my own hands, understood, all the way through. Seen that way, the shape of a team of one was never set by autonomy. It was set by two things: what each task costs when it goes wrong, and whether I understand its output when I pass it on.

The cost of failure sets the team

When I first split up the agents, I split them by the kind of work. Research, coding, review. That division did not last. Once I used it, the real line turned out to be somewhere else. It was how expensive the task is when it’s wrong.

Market research, competitive audits, and doc drafts are cheap to get wrong. If one subagent says something off, it is one voice out of fifteen, and the synthesis step filters it out. So I spread this work wide. One orchestrator hands the job to a group of subagents and gathers the results back.

Coding sits at the opposite end. When two agents touch interdependent core code at once, one walks over the other’s assumptions. The ABI drifts, shared state breaks, and the merge becomes something hard to recover from. Errors don’t get filtered here; they pile on each other. So there is always exactly one coding agent. A single author.

There is a second reason for that. With one author, I can still follow the code later. With two, I am the first one to lose track of what happened.

Read wide, write in one lane

I am not the only one who works this way. Anthropic and Cognition reached a similar place: spread the reading out in parallel, and keep the writing to a single thread.

For someone working alone, though, the reason weighs more. On a team, when parallel coding gets tangled, someone else cleans it up. The only person who can clean it up for me is me. With no room to undo things, I choose not to create the place where errors merge in the first place.

The costs point the same way. One research round uses more than ten times the tokens of a coding session. That is no surprise, since fan-out runs fifteen or sixteen agents at once. It is a lot of waste, but all of it sits on the cheap side, where a wrong answer gets filtered anyway. The expensive coding stays thin. Looking back, design came down to choosing where the waste piles up.

Green but wrong

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

There is a reason the cheap ones go first. Code can pass the tests and still be wrong. Green but wrong. That contract bug I mentioned in part 2 was exactly this: two modules broke a promise they had made to each other. This time I look at it from a different side. The tests let that bug straight through. What caught it was the adversarial reviewer I had added behind them because I didn’t fully trust the tests. It got caught because I had placed verification to match the failure mode.

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

Review isn’t approval, it’s knowing

This is the part I most wanted to write about.

It is the one thing I said I don’t hand off. There are three points where a person checks: 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 stay with it until it makes sense to me.

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

What would happen if fifty agents talked among themselves and finished the thing? You would get speed. And nobody would know what got built. I don’t accept 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. I think the moment a person stops knowing, the team turns into a slop machine.

Where this arrangement breaks

To be honest, this way of working leaks in a few places.

The clearest case I have measured is PCB routing, where the agent’s own registry names the half it cannot execute. Knowing has a cost, so the real bottleneck is me. Add a hundred agents and the queue for understanding and approving still ends at one person. There are times I want to remove that bottleneck. Following that wish leads to the slop machine.

There is also a place where I don’t keep my own rule. Anything that looks trivial, I pass without understanding it. The trouble comes when I draw the line between “trivial” and “decisive” in the wrong place. Something I let through as trivial once turned out, later, to be architecture.

When a single-author session runs long, it forgets earlier decisions: context rot. And when adversarial review becomes a formality, green-but-wrong code walks straight through, and the confidence verification gave me turns out to be fake.

Irreversible physical decisions, like placing an order or signing a contract, sit outside this way of working from the start. The last post was about that ground.

Spine before roster

Before worrying about which agents to spin up, I think you have to build how you will catch what is wrong. Verify spine before roster.

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

Adding a sixth agent is easy. The hard part is understanding what the sixth agent did well enough to sign off on it, and that does not grow the way the agent count does. That is the real ceiling. I keep reaching it at the merge queue, one review at a time.