AI coding tools arrive at a finance review as a seat count multiplied by a rate, which turns the decision into a procurement exercise. Procurement is the one part of this programme where almost nothing is at stake.
In the worked model below, the licence line is 19.6% of the enabling spend and under 0.6% of the payroll it exists to move, while the composition of the work swings the net position 5.38 times as far as the entire seat price range does. The inputs are illustrative. The structure is not.
Push one term at a time and hold the rest still. The seat price swings a full fifty per cent each way, wider than any negotiation will deliver, and never changes the sign of the answer. The other two do.
Run it at $450, $900 and $1,350 a seat with everything else held and the net moves between $793,000 and $343,000. That is a span of $450,000 across a swing no vendor would concede, and the programme returns a profit at every point on it. This is the term the organisation spends its negotiating effort on.
Hold the price at $900 and run the greenfield share at 10%, 30% and 60%. The net travels from a $400,000 loss to a $2,020,000 return, a span of $2,420,000, which is 5.38 times the whole seat price range. Identical tooling at an identical rate, and only this term carries the programme across zero.
The share of a task-level saving that survives review, release and rework. At 35%, 55% and 75% the net runs from a $600,000 loss to $1,736,000, a span of $2,336,000, nearly as wide again as the work mix. It is bought in reviewer hours, release machinery and evaluation code, and none of it appears on a rate card.
Delivery throughput, change failure rate and time to restore are the terms the model is written in. Activation and acceptance rate describe a login and will rise whatever happens downstream.
Time spent on new services against time spent on code that already has callers, then 37.5% and 10% applied separately. A blended average is exactly where an untested greenfield assumption survives.
Size reviewer hours and the evaluation function against the extra change you expect, not last year's volume. The gain is realised in capacities that already had queues in front of them.
Quote the 5% to 6% failure rate assumption and the $344,000 downtime cost beside any 39% modelled return. Half a model is not a forecast, and the discarded half pages someone at night.
In the worked example it is 19.6% of the enabling spend and under 0.6% of the engineering payroll it exists to move. It is also the only one of the six cost lines a procurement call will argue over.
Platform, review capacity and evaluation together run four times larger and rarely get a line of their own.
No. The model is illustrative throughout, run at DORA's 500-person scale with an assumed loaded cost, an assumed code share and an assumed seat price. The single figure taken from published work is the instability line, DORA's own assumption that change failure rate rises from 5% to 6%, and that assumption is itself part of an illustration rather than a measured outcome.
It is the share of a task-level saving that survives review, release and rework to become a delivered change. Measure it by comparing the time engineers report saving against the change your delivery metrics actually show arriving.
At 55% the worked model discards $2,628,000 of saving that never reaches a customer.
Negotiate by all means, but know what it buys. Halving or half-again the seat price moves the net $450,000 and leaves the programme profitable at every point on that range. The greenfield share moves it $2,420,000 and takes it below zero at the low end. Only one of those is worth a quarter of planning.
A task-level saving arrives as more candidate changes per week, and review is a senior engineer capacity that did not grow. Queued work is carried, not banked. DORA measured the opposite case in 2024 and put a 5% productivity improvement on developer independence, meaning a team able to finish work without queuing behind an enabling team.
It helps, and the two are built to pair. Benchmarking Engineering Team Design for AI scores whether an organisation is shaped to hold a gain; this paper prices that shape. A low score on review, release and evaluation is the same thing as a low realisation rate, arriving as a number you can put into the model.
Engineering and finance together, since neither holds all the inputs. Headcount, loaded cost and seat price come from one side; code share, work mix and realisation rate come from the other. A number produced by either alone is not defensible, which is usually why the licence line ends up standing in for the whole case.
Drop your details and we'll send The Economics of Engineering Team Design for AI straight to your inbox - no spam, unsubscribe anytime.
Send us your headcount, your loaded rate and an honest view of what your engineers actually work on. We will rebuild the model around those three inputs and tell you where your realisation rate currently sits. SECTION 7 - FAQ - 5 to 8 questions
Book an economics review