The Two Cost Lines Nobody Counts

The Two Cost Lines Nobody Counts is the costing chapter, and it is deliberately not a survey of tool prices. Seats and usage appear on an invoice, so finance already tracks them. Reviewer hours and incident cost are paid in people's weeks, which means they are real, large, and absent from every business case I have seen.

Key takeaways

• Cost the unit that ships, not the unit that merges. A merged pull request is inventory, and Chapter 1 showed inventory rising while default-branch throughput fell.
• Sadowski and colleagues measured developers spending an average of 3.2 hours and a median of 2.6 hours per week reviewing code, in a 2018 study of Google's review logs. Weight those hours by seniority, because the reading that generated code demands is senior reading.
• Faros AI, which sells engineering-productivity analytics, reports incidents per pull request up 242.7% and monthly incidents up 57.9% as of March 2026. That is the second uncounted line, and it is the one with a customer attached.
• Seat cost is the easiest and least interesting line. As listed on 29 July 2026, Anthropic's Claude Team standard seat is 20 US dollars per seat per month billed annually, with Enterprise described as seat price plus usage at API rates.
• This chapter deliberately prints no worked total. Any figure I invented would be read as a benchmark, and there is no primary that would justify one.

Read this after Chapter 11, because costing against delivered change requires the metric set that chapter settles, and before Chapter 14, which sequences the spending. Chapters 5 and 8 supply the two inputs that are hardest to obtain.

The finance conversation goes well for four minutes. Seat count times seat price, plus a usage figure from last month, against a headcount saving somebody has assumed.

Then somebody asks what the review time costs. Nobody has that number, so it is treated as zero, which means the business case is comparing a real invoice against an imaginary saving.

The same thing happens with incidents. They are on a reliability dashboard rather than in a budget, so they do not appear in the comparison at all.

The invoice is the easy half

Two of the four cost lines are billed, which makes them visible, controlled and roughly correct. Two are absorbed, which makes them invisible, uncontrolled and usually larger.

That asymmetry is not an accounting curiosity. It systematically biases the decision, because the costs you can see are the costs you optimise, and the costs you cannot see are the ones that grow.

The consequence in practice is a familiar shape. Seat spend gets negotiated hard, usage gets a dashboard and an alert, and the fourteen hours a week your three most senior engineers now spend reading generated code gets described as a culture problem.

So this chapter has one job. Put all four lines on the same page, in the same unit, with the reader's own numbers.

Cost per unit of shipped change, defined

The unit to cost is one change that reached production and stayed there. Not a merged pull request, not a commit, and not a story point.

Three exclusions make that definition sharp. A merged change that has not deployed is inventory, and counting it flatters you in exactly the way Chapter 1 warned about. A change that deployed and was reverted has consumed its costs and delivered nothing. And a change that shipped and caused an incident has a cost line of its own, which is section six.

The denominator matters as much as the numerator. Divide by shipped changes and cost per unit falls as the operating model improves. Divide by merged pull requests and cost per unit falls whenever the queue grows, which is the wrong incentive to install in a finance conversation.

DX's AI measurement framework proposes three dimensions, utilisation, impact and cost, and recommends direct measures such as AI-driven time saved per developer per week alongside indirect regression analysis on existing delivery metrics. That is a reasonable structure to hang this on.

Line one: seats, and the utilisation question

Seat cost is the line everybody has and the least interesting one, so it gets the shortest section.

One dated anchor, and prices move, so the date is part of the sentence. As listed on 29 July 2026, Anthropic's Claude pricing page shows a Team standard seat at 20 US dollars per seat per month if billed annually or 25 if billed monthly, a premium seat at 100 annually or 125 monthly, and Enterprise described as seat price plus usage at API rates. I am naming one vendor because I read its page today, not because this chapter compares vendors. It does not.

The interesting number is not the price. It is utilisation, meaning the share of purchased seats being used weekly, and the distribution of use within that share.

Two mistakes recur. Buying seats for a whole organisation when a quarter of it will not use them this year, and treating a low utilisation figure as a training problem when it is often a correctness signal about who benefits.

Line two: tokens, compute and the pipeline

Usage cost scales with volume, which means it scales with everything else in this book. That makes it the line most likely to surprise a quarterly forecast.

Three drivers sit behind it. Model usage during authoring, which rises with adoption and with iteration depth. Model usage during automated review, which is a per-change cost that Chapter 6 deliberately increased. And pipeline compute, which is the one people forget.

Chapter 7's decomposition of one change into eight multiplies pipeline runs. Chapter 8's fast revert path needs a warm target. Chapter 4's pre-open gates run the suite before a human sees anything, several times per change. Every one of those is correct and every one of them bills.

Track this per shipped change rather than per month. A rising monthly bill with a falling per-change cost is a business succeeding, and the monthly figure alone cannot tell you which you have.

Line three: reviewer hours, priced

This is the first uncounted line and it is the one that changes the answer most often.

The only public per-developer anchor is old and should be cited as such. Sadowski and colleagues, at ICSE-SEIP in May 2018, measured developers at Google spending an average of 3.2 hours and a median of 2.6 hours per week reviewing code, from review logs covering 9 million changes.

Two adjustments are required before that number means anything for you. Measure your own figure rather than adopting theirs, because your codebase and your review policy differ. And weight the hours by who is spending them, because Faros AI's account of why generated code is slow to review, that it is superficially convincing with failures beneath the surface, describes work that lands on senior engineers.

The uncomfortable arithmetic is that senior reviewer hours are among the most expensive hours in the organisation, and they are being consumed by a cost line nobody has ever put in a budget. Put it in one. It is the strongest argument you have for the upstream investment in Chapters 2 through 4, because that investment is what reduces it.

Line four: incident cost per shipped change

The second uncounted line has a customer on the end of it, which is why it belongs in a budget rather than only on a reliability dashboard.

Faros AI reports incidents per pull request up 242.7%, monthly incidents up 57.9%, bugs per developer up 54% and bugs per pull request up 28.7%, from between-quarter comparisons across 22,000 developers as of March 2026. CircleCI's report of 18 February 2026 gives a duration anchor, with median recovery to green at 72 minutes, up 13% year over year.

Cost an incident with three inputs you already hold. Engineer hours consumed, including the people pulled in who were not on call. Customer impact, in whatever unit your business already uses for that, which is usually credits, churn risk or support volume. And the delay cost of the work those engineers were not doing.

None of those is precise. All of them are closer to correct than zero, which is the number currently in the model.

The four lines on one page

The table below is the artifact, and the third column is the reason this is doable rather than theoretical.

Notice which two rows have no invoice behind them. Those are also the two rows that respond to the operating model rather than to a procurement negotiation, which is why they are the two worth measuring first.

The exercise, and why it prints no total here

The details of this exercise are composited from ordinary production shapes rather than one system, and the shape is exact.

A team runs the four lines for one quarter. Seats come from the invoice in five minutes. Usage comes from two exports and takes an afternoon. Reviewer hours come from pull request timestamps already in the tooling, weighted by the grade of whoever commented. Incident cost comes from the incident records, with a deliberately crude hourly rate.

The output is one page with four numbers per shipped change. Its value is not precision. It is that the two unshaded lines turn out to be the same order of magnitude as the invoice, or larger, which reverses the conclusion the finance conversation was heading towards.

I am not going to print numbers for those four lines, and the reason is a rule rather than modesty. There is no primary that would justify a benchmark here, so anything I invented would be repeated as one. Your seat count, your seniority mix and your incident profile are the whole answer, and none of them is transferable.

What I will commit to is the ordering I expect you to find. Reviewer hours above tokens, and incident cost above both, in any organisation where the queue from Chapter 1 has already formed. That is a prediction you can falsify with your own data in a week.

The objection: the return is real even if the costs are

Two objections arrive together here, and they pull in opposite directions, which is why both need answering.

The first is that this chapter is an argument against adoption. It is not. The upstream investment in Chapters 2 through 4 exists precisely because it moves cost from the uncounted lines to the counted ones, where compute is cheap and reviewer attention is not, and that trade is the whole economic case for this book.

The second is that a dip in the numbers early on proves the investment is failing. DORA maintains a report on the return of AI-assisted software development, whose landing page was last updated 22 April 2026, and which describes managing the initial productivity dip of a new rollout. The report body sits behind a form and I have not read it, so I am citing only that framing and no figures from it. The framing is enough to make the point: expect a dip, plan for it, and do not let a quarter of worse numbers reverse a decision.

There is one thing I would not do with this page, and it is the thing it will be used for. Do not convert the reviewer-hour line into a headcount reduction. Faros AI's own recommendation is to repurpose engineering capacity rather than reduce it, warning that the engineers you are considering cutting are in many cases the ones absorbing the quality gap, and that the risk is rehiring within months. Chapter 14 takes that seriously.

Chapter summary

Agentic delivery has four cost lines and only two of them arrive as invoices, which biases every business case, because visible costs get optimised and absorbed ones grow. The unit to cost is one change that reached production and stayed there, not a merged pull request, since merged inventory flatters the denominator exactly as Chapter 1 described, and a reverted change consumed its costs while delivering nothing. Seat cost is the least interesting line: as listed on 29 July 2026, Anthropic's Claude Team standard seat is 20 US dollars per seat per month billed annually with Enterprise described as seat price plus usage at API rates, and the number that matters is utilisation rather than price. Usage cost scales with volume across authoring, automated review and pipeline compute, and every recommendation in Chapters 4, 6, 7 and 8 increases it deliberately, so track it per shipped change rather than per month. The third line is reviewer hours, anchored only by Sadowski and colleagues measuring an average of 3.2 hours and a median of 2.6 hours per developer per week in 2018, which must be measured locally and weighted by seniority because generated code demands senior reading. The fourth is incident cost per shipped change, with Faros AI reporting incidents per pull request up 242.7% and monthly incidents up 57.9%, and CircleCI reporting median recovery to green at 72 minutes, costed from engineer hours, customer impact and delayed work. This chapter prints no total on purpose, because no primary would justify a benchmark and an invented one would be quoted as fact. Expect a dip, which is DORA's own framing on rollout, and do not convert the reviewer-hour line into redundancies.

Costing the reviewer-hour line raises a question the spreadsheet cannot answer. The people whose hours are being consumed learned to review by writing the easy version first, and the next cohort will not. Chapter 13 is Juniors, Craft, and Not Deskilling the Team.