The Economics of an Agent-Heavy Team

A team where a large share of implementation is delegated has a different cost structure from one where it isn't, and the difference isn't just "we spend money on tokens now." Several line items move in directions that surprise people planning budgets.

The lines that move down

Implementation labour per unit of output. The headline, and it's real for the pattern-following share of work.

Time to first version. Prototypes, scaffolding, exploratory implementations.

The cost of coverage. Edge cases, tests, additional formats — work that was expensive because it was tedious.

The floor on small work. Things that never justified an engineer's week now cost an hour, which unlocks a backlog that was permanently deferred.

The lines that move up

Model spend. Obvious, and usually smaller than expected relative to salaries — which is why it's often the wrong thing to optimize first.

Review capacity as a constraint. ⚠️ The real cost. If review bounds throughput and review is human, the effective cost per merged change includes the reviewer's time, and that hasn't fallen. Teams measuring only implementation savings are measuring the smaller half.

Integration effort. More parallel work, more interactions between individually-correct changes.

Maintenance surface. More things created means more carried. Creation got cheap; carrying didn't.

Comprehension work. Understanding the systems you now have has to be resourced deliberately, because it stopped being a byproduct.

Evaluation and operations. The eval set, the monitoring, the sampled review, the model migrations. New permanent line items that didn't exist before.

💡 The unit that matters

Not cost per line of code, or even per feature. Cost per unit of value delivered to production, including everything downstream.

The rough shape:

old:  specify (human) + implement (human, dominant) + review (human) + carry
new:  specify (human, now dominant) + implement (cheap) + review (human, larger)
      + integrate (larger) + carry (larger, because more exists)
      + evaluate & operate (new)

→ Which is why teams report large implementation speedups and modest delivery improvements. The savings are real and they land on one term while several others grow.

What this implies for planning

Budget review capacity explicitly. If it's the constraint, it's the thing to resource. This may mean fewer producers and more reviewers, which is an uncomfortable conversation.

Budget comprehension. Someone reading and understanding critical systems is real work producing no artifact and preventing real incidents.

Budget agent operations and evaluation as permanent line items, not project costs.

Raise the bar on creation, since carrying cost is unchanged and the cost argument that used to hold the bar no longer does.

Track cost per completed task, at p95. Agent costs are tail-dominated; means hide the runs that matter.

✅ The measurement that reveals the truth

Elapsed time from decision to production, with a phase breakdown, before and after.

If implementation was a minority of elapsed time before, it's a smaller minority now, and the speedup you measured is real and mostly not where delivery time sits. That's not an argument against the tooling — it's an argument for knowing which constraint you're working on, because effort on a non-constraint produces no throughput at all.

The takeaway

Implementation labour, time-to-first-version, coverage cost, and the floor on small work all fall. Model spend, review capacity, integration, maintenance surface, comprehension, and evaluation all rise — and several of those are larger than the token bill. Measure cost per unit delivered to production rather than per unit produced, budget review and comprehension as real line items, and raise the bar on what gets built, because nothing else is holding it.