Autonomy expands with instrumentation, not capability

The most autonomous AI system I operate is the one that builds my software: a kanban board of agents that spec, build, review, fix, verify, and ship — nearly fifteen hundred cards closed in five weeks, measured off the board’s own ledger. The autonomy did not come from smarter models. It came from instrumentation.

Early on, I went to bed with everything working and woke up to runaway agents that had burned through the usage caps of four Claude Code accounts and a Codex account overnight. The spend hurt. What hurt more was that the only way to reconstruct the night was reading chat logs — the fleet could not explain itself. So the fix wasn’t revoking autonomy — it was telemetry embedded in the platform, and a lineage graph that stores what happened on every card, so an agent can query one source instead of distilling the story out of a pile of logs.

Model capability cut the other way. When one model did everything, adversarial review kept coming back “good to go” and the bugs arrived later anyway — the reviewer shared the builder’s blind spots, and more than half of my tokens were going to review. Now the roles split across vendors: Fable architects, Sonnet builds, Codex reviews. It thinks differently, it sees problems differently, and it catches what the builder cannot. The full casting, stage by stage, is in a field note.

I run the fleet the way I would run a team of people. No one gets full autonomy to do everything: sensitive changes wait for an independent pass, merges fail closed, spend has a daily budget, and the throttle is a WIP limit I set by hand. The board has closed over a hundred cards in a day with the throttle open. Most days I keep it far lower, because it burns all my tokens.

A smarter model changes none of that. Autonomy is not a reward for capability. It is what a system earns when it can explain itself — measured and gated, no different than a team of humans.

More writing

Start