Part two of a four-part series. Part one: Your Toolchain Is Production Now. Parts three and four follow.
Part one of this series argued that your toolchain is now a production system. For decades its cost was carried by a human shock absorber: developers — salaried, patient, invisible on any bill — absorbing the slow builds and the flaky tests. Agents removed the developer as the default absorber and put that cost on a meter. But the human absorption did not end; it moved. This post follows where it went.
When the loop is fast, working with AI agents stops feeling like software development. I hold an idea of what I want to build, I keep three or four sessions moving, and the software takes shape about as fast as I can think it through. This is not the old work made incrementally faster — it is a different regime: the work is idea-limited — the toolchain does not set the pace. And for anyone who holds a product vision, the change is enormous: the binding constraint is finally the vision itself.
In that regime, the developer absorbs no toolchain cost — and this post could end here.
But many enterprise developers have never worked this way: their builds are slow and flaky, the flow breaks, and they get a fraction of that new potential.
The stakes did not appear with the agents; they multiplied. A wasteful toolchain used to cost time that your developers absorbed and nobody ever priced. Now it costs them the fast side of the new era.
The same loop bills you twice: once in token and compute cost, and once in developer productivity. And only half of that bill is visible. The token-and-compute half arrives itemized; the developer half hides where absorbed cost has always hidden — inside salaries, where none of your dashboards reach.
An agent works through a task in iterations: it usually starts by running the build and tests to get a baseline. When it makes a change, it runs the build and the tests again. If they pass, the change is verified. If they fail, the agent forms a hypothesis about the cause and changes the code accordingly. It cannot know whether the hypothesis is correct; to validate, it has to run the build and the tests again. The cost of a verified change is therefore the number of iterations it takes, times the cost of each.
A developer's wait used to be one build-and-test run. Now the agent does the troubleshooting, and one wait is the agent's whole turn. A turn contains as many runs as it takes.
Two factors set the length of a wait: how long each run takes, and how many runs it takes to reach a failure-free one. Speed matters on every run, whatever its outcome. Every run but the last ends in a failure, and failures come in two kinds. A real verification failure means the toolchain did its job: the change broke something in the code, and the break was caught in the loop instead of in production. Now the quality of the context the agent has for reasoning about the failure becomes a key input: the better the agent can reconstruct what happened, the fewer iterations — and the fewer tokens — the fix takes.
A false failure is different: a flaky test or broken infrastructure fails the build even though the change is correct. Here every iteration is waste, because there is nothing to fix. An agent that takes the failure for real fixes it anyway, and correct code ends up changed to satisfy a test that was lying. The hard part is knowing that. Whether a failure is real cannot be read off the failing run alone — it takes context beyond the run: does this test fail on other branches too? For other people? For changes that cannot have affected it? Sorting real from false has always been expensive for developers, and the defense they built is institutional knowledge — "that one does that, ignore it" — accumulated slowly and never complete. An agent starts with none of it. Unless that knowledge is available as context, it investigates the same flaky behavior every time the build fails.
Both kinds of failure share a worst case: the agent cannot figure it out. It gives up, or it runs on without converging. Getting the agent out of that dead end is developer work again.
And running more sessions will not compensate for an inefficient toolchain. Agent feedback is never instant, so a developer, even when the work is idea-limited, keeps a few sessions moving as it is. My own ceiling is three or four; Anthropic's own guidance for Claude Code recommends three to five. The limit is human — how much context one person can hold at once — and it does not grow when the waits do.
With a slow loop, the waits grow until covering them would take more sessions than a developer can hold. So the developer waits, with nothing to do inside that session; the work between runs is the agent's. At least there is still coffee. And a flaky loop adds the opposite burden: more false failures and more dead ends, each pulling the developer back in. That is where the absorption went.
When the work is idea-limited, the developer's pace is set by how fast they can think through the next idea. With a slow loop, it is set by the wait. The distance between the sides is the ratio of the two: I expect a multiple at least — and an order of magnitude when the waits stretch.
Agent programs are headed toward swarms — agents that run mostly alone and themselves approve what merges, with a handful of people supervising. When Anthropic had sixteen agents build a C compiler, one human was on the loop, not in it — building the harness and tests that covered what the toolchain could not. But a handful cannot absorb the failures of an entire swarm. Their day is triage: every dead end and every ambiguous failure across the fleet lands on the same few people. The human absorber has not left; the role has concentrated — and that buffer is small. When more failures land than the few can absorb, the fleet slows to the pace of its humans, and a swarm at human pace is no swarm at all. That is why a swarm can only operate if most of its changes merge without ever touching a human — governance included. And absorption is not the swarm's only ceiling: part one showed how drift — the mainline moving under every open change — caps a fleet all by itself. The toolchain has to fix this — no human can.
The fix is the toolchain, and part one made the argument: your toolchain is production now — treat it like a production system. Engineer it for speed, and the waits shrink. Engineer it for reliability, and the failures it reports are real. Instrument it, and an agent has the context that drives how long every turn runs: does this test fail elsewhere, for others, always?
None of this needs to wait: quarantining the flaky tests, feeding the agent your known-flaky list, analyzing and tuning the slow builds. Production treatment is what takes your developers out of the shock-absorber role and keeps their work idea-limited, whether you build or buy it.
The loop sets three numbers: how long the developer waits, what a verified change costs in tokens, and how much merged work comes out the other end — the throughput your delivery metrics already report. Part three builds the mathematical models for all three — including the drift math that caps the fleet — and names the numbers to pull from your own systems. If you want a head start: count last quarter's false build-and-test failures, local and CI — even a rough count from your senior engineers will do — and price them at agent iteration rates. If nobody can say which failures were false, that is a finding too.
And the change volume that outruns human review still has to clear governance. Part four takes the production argument there: supply chain security, proof of how every artifact was built, strong identity for everything that takes part, and policy that holds at machine pace.
