Press kit
Press kit
Cost per accepted change is a free, citable measurement standard for AI-augmented software delivery. This page collects the materials journalists, analysts, and researchers need to cover it.
Quick facts
| What it is | A measurement standard for the cost of producing software that reaches production and stays there. |
|---|---|
| Formula | (model cost + infrastructure + engineering time + review + rework) ÷ accepted change units |
| Defined in | The Delivery Gap (Brenn Hill, 2026), as the cost vertex of the Verification Triangle |
| Canonical reference | costperacceptedchange.org |
| Source | github.com/brennhill/cost-per-accepted-change · MIT-licensed |
| Calculator | costperacceptedchange.org/calculator — client-side; shareable via URL |
| Tracker template | XLSX for Google Sheets / Excel / LibreOffice / Numbers |
| Author | Brenn Hill — LinkedIn · Substack |
| Launched | May 2026 |
One-paragraph summary
For direct quotation:
Cost per accepted change is the fully-loaded cost of producing software that reached production and stayed there, divided by the number of accepted change units that did. It pairs FinOps cost-to-serve discipline with a development-side denominator. Where vanity metrics like "AI code share" or PRs-merged inflate as teams adopt AI tooling, cost per accepted change moves with actual delivery economics — making it the bottom-line number engineering leaders can put in front of a CFO.
Shorter quotable summaries
"Most AI productivity metrics measure activity, not outcomes. Cost per accepted change measures the cost of work that actually shipped and stayed in production."
"It is FinOps cost-to-serve, moved one layer upstream — measuring the cost of producing trusted software, not the cost of running it."
"The metric that catches the perception-reality gap independent studies have documented in AI-assisted development — including METR's 2025 finding that experienced developers self-reported a 20% speedup while measurably slowing by 19%."
Why it matters now
In 2026, enterprises are deploying AI dev tooling at scale but cannot reliably measure whether the investment is paying off. MIT-reported figures suggest 95% of AI pilots show no measurable P&L impact; only ~29% of executives say they can confidently measure AI ROI. The gap is not a math problem — it is a definitional one. There has been no canonical, vendor-neutral metric for the cost of AI-augmented software delivery. Cost per accepted change is one.
Downloadable graphics
All graphics are released for editorial and educational use without attribution requirement. Attribution to costperacceptedchange.org is appreciated where space allows.
CPAC formula graphic
The bordered "stamp" rendering of the formula. Suitable for slide decks, article headers, embeds.
Verification Triangle
The three-vertex framework (Intent clarity, Eval quality, Cost) from The Delivery Gap. Cost vertex highlighted.
$/AC fraction mark
The site's identity mark. Suitable for inline use, favicons, attribution.
About the author
Cost per accepted change was defined by Brenn Hill in The Delivery Gap: AI Adoption for Engineering Leaders (2026), where it appears as the cost vertex of the Verification Triangle framework. The book argues that AI did not make software delivery faster — it made code generation faster, and the distance between the two is the delivery gap that most organizations are measuring poorly or not at all.
Connect: LinkedIn · Substack · GitHub
Citation
BibTeX, plain text, and inline-mention formats are on the cite page. For working journalists, the simplest reference is:
Hill, B. (2026). The Delivery Gap. See costperacceptedchange.org for the canonical definition.
Contact
Corrections, clarifications, or interview requests:
- Public corrections and suggestions: github.com/brennhill/cost-per-accepted-change/issues
- Direct contact: via LinkedIn or reply to any post on brennhill.substack.com
Need a specific asset size, language version, or interview? Open an issue at the repo.