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.
Coverage and appearances
Podcast appearance: 525 — The Delivery Gap: From Vibe Coding to Productive Coding
The book
Cost per accepted change is defined in The Delivery Gap by Brenn Hill (2026), as the cost vertex of the Verification Triangle framework.
Reviews
Praise for The Delivery Gap
"The 'Accelerate' for the age of AI."— Xavier Anguera, SVP of AI, Babbel
"The question was never whether AI could write code faster. The question is whether you can trust what it ships. Hill gives engineering leaders the framework they actually need."— Mark Morawski, Managing Director, JPMorgan Chase & Co.
"A book that will be cited belatedly in eng productivity postmortems."— Brad Moore, VP of Engineering, Delivery Hero (previously Spotify, Uber, Apple)
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 | aifinops.dev |
| Source | github.com/brennhill/cost-per-accepted-change · MIT-licensed |
| Calculator | aifinops.dev/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 activity metrics like "AI code share" or pull-requests-merged inflate as teams adopt AI tooling, cost per accepted change moves with actual delivery economics. It is designed for aggregate, time-series, group-level use as an executive bottom-line — not for ranking individuals, comparing unrelated teams, or setting targets.
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 is designed to catch the perception-reality gap independent studies document in AI-assisted development — including METR's July 2025 randomized trial, which found AI tools increased experienced developers' completion time by 19% (a 20% slowdown) while the same developers self-reported a 20% speedup."
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's NANDA initiative — in The GenAI Divide: State of AI in Business 2025 (52 executive interviews, 153 survey respondents, 300 public deployments analyzed) — found that 95% of generative AI pilots delivered no measurable P&L impact; only ~5% achieved rapid revenue acceleration (Fortune coverage, August 2025). McKinsey's State of AI 2025 independently found that only 39% of organizations attribute any EBIT impact to AI, most of those less than 5%. The gap is not a math problem — it is a definitional one. There has been no shared, vendor-neutral metric for the cost of AI-augmented software delivery. Cost per accepted change is one.
How the metric is and is not designed to be used
For accurate coverage, please reflect both sides:
- It is a steering metric for engineering and finance leaders at the team or organization level, reported as a time series, paired with a leading indicator (DORA change failure rate, AI tool acceptance rate, or DevEx pulse).
- It is not a per-change or per-engineer benchmark, a cross-team comparator without controls for work-mix, or a target to set against. See how to use cost per accepted change for the variance reasoning and the operating constraints.
Downloadable graphics
All graphics are released for editorial and educational use without attribution requirement. Attribution to aifinops.dev is appreciated where space allows.
Social post images
The "AI made code generation faster. Not delivery." hook image, sized for LinkedIn (portrait) and X / Bluesky / Mastodon (square). Free to repost.
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, Verification 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 aifinops.dev 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.