The constraint is me
Most mornings I wake up to 10 to 20 finished things waiting on me. PRs, tasks, a few things the agents built overnight. All of them need me before they can go anywhere.
I noticed when PRs started piling up faster than I could review them. Then an agent told me a feature was done, and the first thing I clicked didn’t work.
I’m reading An Ode to Speed by Justin Roff-Marsh right now. It’s about the Theory of Constraints. Every system has one step that limits how fast the whole thing moves, and the book calls it the Constraint. This is the line I keep coming back to:
An idle machine (or person) is adding value if they are preventing the Constraint from becoming idle.
In my setup the Constraint is me. Three Claude Max 20x subs, about 15.2B tokens a week, and all of it ends up waiting on one person to look at it.
So if an agent is sitting idle, that’s fine. Idle agents are cheap. My time isn’t.
It’s not just me. Ars Technica wrote about a Harvard study of more than 700 software companies. After they brought in coding agents, pull requests went up 23% and review time went up 49%. The number of finished features didn’t really move. The Phoenix Project says this too. If you speed up the steps before the bottleneck, you just get a bigger pile in front of it.
Now the agents test their own work before they hand it over. A separate review agent checks it before I see it. The morning brief puts the things that need me at the top, so I don’t have to dig through the rest. Agents should prove the work before it reaches me.
The Claude Code team wrote about the same problem last week. They call human time and attention the scarce resource. They ask Claude to “show the output instead of saying it’s done.” That would have saved me the click that failed.
Last week Mark Manson wrote about freestyle chess. In 2005 an online site ran a tournament where anything was allowed. You could play with computers, with other people, with as many machines as you wanted. Grandmasters entered with serious hardware.
Two amateurs from New Hampshire won. Steven Cramton and Zackary Stephen played as “ZackS”. Neither was rated anywhere near grandmaster level. They had three home computers. In the final they beat GM Vladimir Dobrov, who was playing with a 2600+ partner.
Kasparov wrote about it a few years later:
Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process.
Their own write-up explains how they played. Each of them analyzed different lines. When one found something good, they looked at it together and compared what the different engines said.
That’s close to what I do. One agent writes the code and a different one checks it before I see it. I posted the other day that I pay $1k a month to have AIs argue about my code.
Anyone can buy the same subs. My agents share memory, so they know my business. And I’ve spent weeks tuning the skills and routines they run.
There’s a paper on arXiv arguing that human review of agent code is already a rubber stamp, so you should take the human out and let another agent review it. For low-risk stuff I already do that. Where I’m heading is merge rules per project, where some projects can merge on their own and some still wait for me.
I’m not sure the paper is wrong about the rubber stamp part. Some nights I approve things because I trust the agent and I want to go to sleep.
~ aq