"We're building better observability" as a real capacity loop, versus the exact same sentence used to avoid shipping anything for a quarter. The words don't tell you which one you're looking at. On the business side, the same tell shows up as "we're investing in the team," right before a hire who never actually changes how fast anything ships.

Pricing the decision

A capacity loop, from Part 4, is only worth funding if it targets a rung whose queue (Part 2) is genuinely long and genuinely recurring. A one-time queue doesn't justify permanent capacity. This post is about pricing that decision properly.

A starting heuristic, offered as a shape, not a formula

Roughly: value unlocked per loop closure, times how often that loop actually runs, divided by cost to build the capacity. Not real math, and it never will be — nobody's plugging numbers into this on a spreadsheet. Most capacity decisions get made on gut feel and internal politics, and no heuristic replaces either one. What it's useful for is forcing the right question onto the table: does this loop run often enough that getting faster at it pays off, or is it a one-off wearing an infrastructure costume?

What a capacity loop concretely looks like right now

Picking up Part 3's citation, Osmani and Udasi's near-identical essays both name the same six specific things worth funding as capacity, and together they're a decent checklist for what "building the machine" from Part 4 actually means today.

Automations: scheduled discovery that runs without a person kicking it off — checking CI failures or open issues on its own. Worktrees: isolating parallel work so agents, or people, don't collide on the same files. Skills: a written-down, reusable piece of project knowledge, so it doesn't get re-derived from scratch on every single run. Plugins and connectors: the wiring that lets a system actually take an action — open a PR, file a ticket, post a message — instead of just suggesting one. Sub-agents: a second, separate pass that checks the first pass's work. Udasi calls it "the single most impactful structural pattern," and it maps directly onto why you don't let the same reviewer who wrote the code also approve it. And state: a durable, external record of what's active, what's already been tried, and what's still waiting on a human — so the next run doesn't start from zero.

None of these six ship value on their own. What they all do is make every future value loop run faster, which is exactly what makes them capacity loops in the Part 4 sense, not some special AI-only category.

One of these six has a real measured number behind it, not just branding. A 2025 paper out of Bristol, Robeyns, Szummer, and Aitchison's "A Self-Improving Coding Agent" (ICLR 2025 workshop), had an agent edit its own scaffold and tools based on execution feedback, and measured the result: SWE-bench Verified performance went from 17% to 53% on their test subset. That's one mechanism, self-editing scaffold, tested and measured, not the whole list. The other five are logical extensions of the same idea, not separately benchmarked.

A caution that applies just as much to the business side

Udasi names three. Token economics — uncontrolled runs get expensive fast. Verification burden — an unattended loop still makes mistakes and a human is still on the hook for them. And what he calls "cognitive surrender" — speed masking the fact that nobody actually understands what the system just did. The business equivalent is a team that's automated its reporting so well nobody reads the report anymore. A capacity loop that outruns anyone's ability to check it isn't capacity. It's exposure.

The backlash deserves a name too. A widely-shared July 2026 piece claimed a large company blew a year's AI budget in four months running unattended agent loops. That specific figure is unverified and shouldn't get repeated as fact. But the basic worry, that unattended loops can burn real money fast if nobody's watching the meter, doesn't need the anecdote to be true to be worth planning around.

The tell for a genuine investment versus avoidance

Does it target a loop that runs often and is currently slow or expensive, with a real path to it running much more often afterward? If the loop it targets barely runs at all, it isn't a capacity investment. It's busywork, whether that busywork takes the shape of a new internal tool or a new hire with no clear loop to speed up.

The first five posts add up to a framework. The closer is a worked exercise, applying it to a real stack end to end, in both languages, including the recursive move this post deliberately left out: treating the framework itself as something worth re-checking on a schedule.

The Capacity Bet: Knowing When to Stop Shipping and Go Build