The Restraint Problem

My agents and I have made 3,884 commits since January. I've come to read that number as a warning, not a scoreboard.

There is a graph on my homepage I used to be proud of.

It is a commit heatmap, the same green grid GitHub puts on every profile, and for months it has been nearly solid: most days dark, many of them the darkest shade it goes. Since January, my agents and I have made 3,884 commits to the single repository that runs my company and most of my life. Over the last thirty days the rate has been around thirty-eight a day, and it is still climbing. One day in March it was seventy-two. That repository holds seventy custom agent skills, something like eighteen thousand lines of instructions written in plain English, and a fifty-five-thousand-line control plane I built to watch the rest of it work. There is one human in the author column.

The graph in question. Six months of days, almost all of them green.

By the ordinary scoreboard, the graph is a trophy: one person, the output of a team. It is precisely the image you are meant to screenshot under a caption about leverage.

I have started reading it as a warning label.

The number is real, and that is the problem

I am not setting up a confession that the work was fake. It was not. Every one of those commits did something: shipped a feature, fixed a bug, tightened a tool, refactored a system that needed it. If you audited them one at a time, almost none would look like waste. That is exactly what makes the graph misleading, and it took me a long time to see it.

The trouble is not that the commits are empty. The trouble is what the graph silently claims. A full heatmap is supposed to be a proxy for progress, and for most of the history of software it was a decent one, because commits were expensive. Each cost a person hours of attention, and attention was the scarce thing, so you spent it on what mattered. The volume of work and the value of work moved together, roughly, and a busy graph really did mean you were getting somewhere.

Agents break that link. When the marginal cost of building drops close to zero, the graph stops measuring progress and starts measuring something much less useful: how much I was willing to let the machine do. Those stopped being the same number. Mine came apart quietly, and for months I mistook one for the other.

Cheap building removes the filter

Here is the mechanism, because it generalizes past me.

When building is expensive, cost is a filter. You cannot afford to build everything you think of, so you are forced to choose, and the forcing is the point. The friction everyone complains about, the hours a feature takes, is also the thing quietly killing your bad ideas before they cost you anything. Scarcity does your triage for free.

Agents remove the friction, and the triage leaves with it. This is sold as the whole benefit, and for a while it feels like one. But the set of things that are plausible to build is effectively infinite, and the set of things worth building is not. While building was costly, the gap between those two sets did not matter, because you never reached the edge of it. Make building nearly free and the gap becomes the entire game. You can act on every plausible idea now, and “plausible” is a bar almost anything clears at two in the morning.

I wrote once that with a single model the operator’s scarce resource is not generation but evaluation: judgment, not typing. A fleet is that observation with the volume turned up. It multiplies the side of the ledger that was already cheap and does nothing for the side that was always the constraint. If you are not careful, and I was not, you end up with a beautifully engineered machine for doing the wrong things quickly.

The build engine runs hot

I know how this sounds in the abstract, so here is the evidence, and it is in my own handwriting.

I keep a weekly retrospective. Read mine across this spring and you find the same observation surface, in slightly different words, five weeks in a row: the build engine is running hot. The tooling I was building to take friction out of the business had started crowding out the business. I was spending my best hours making the machine that makes the reagents run smoother, and fewer of them on selling reagents, which is the part that pays. Every one of those weeks I could point to real shipped work. That was never in question. What was in question, and what I kept failing to answer, was whether it should have been built at all.

It compounds, because a system that makes building feel free will happily turn its abundance on itself. I built tools. Then I built tools to manage the tools. Then I built a weekly agent whose job is to study the whole apparatus and propose improvements to it, which is to say, propose more building. At one point I found that my own log of workflow annoyances had recorded, as a fresh annoyance, my running a search through the log of annoyances. The system had generated work about the work about the work. It was funny for about a second, and then it was not, because it is the whole failure in one line: an engine that is good at building will keep building, including building reasons to build, until something outside it says stop.

Restraint is a mechanism, not a mood

The instinct, once you notice this, is to resolve to do better. To be more disciplined. That does not work, and it is worth being clear about why. You are one person with finite willpower, up against a system you specifically engineered to make the next thing effortless. Discipline loses that fight, because the system is patient and you are tired. Telling yourself to build less is like telling yourself to eat less in a house where every surface is covered in food you made delicious on purpose.

So the only thing that has helped is treating restraint the way I treat production: as something you build, not something you feel. If the system is good at generating, you have to make it equally good at subtracting, and give subtraction the same infrastructure, the schedules and rules and standing agents, that you gave to making things.

Some of what I have built for this works. My advisors, the agents that review the business and the system each week, are allowed to propose and forbidden to build; the proposing and the deciding are kept in different hands on purpose, and the deciding stays with me. There is a standing rule that when one of my own projects goes quiet, an agent is meant to notice and make me formally kill it, rather than let it sit as an open tab forever. The real job of my weekly review, the one it took me months to admit, is not to plan the next week of building. It is to say no to most of it.

I would be lying if I said this was solved. The guards are partial, and I still overbuild; I built at least one item on that very list partly because building it was more fun than selling. What changed is smaller and more durable than a resolution: the question moved. For a long time the only question the system could ask me was “is this done.” Now, more often, something in it asks “should this exist,” and that one question, asked early and by a mechanism instead of by my mood, has killed more bad work than any amount of willpower ever did.

Measure what you killed

The graph is still on my homepage. I have not taken it down, and I do not think I should, because the honest reading of it is more interesting than the flattering one.

What I would tell anyone weighing what agents mean for their business is this. The leverage is real, but it is not where the pitch says it is. Throughput was never your bottleneck. Removing it will feel like a triumph anyway, and the tools will gladly help you remove it, and if throughput is the number you watch you will optimize yourself into a very fast machine aimed at the wrong wall. The scarce resource was always judgment, and agents make it scarcer by burying it under cheap, plausible, technically-real work.

The scoreboard I trust now is the one nobody keeps, because it is the hard one to keep: not what I shipped this week, but what I decided not to build. That number shows up green on no graph anywhere. It is the only one that has ever tracked the business actually getting better.