Engineering economics · Feature report
AI sped up the code. Did it lower the cost of running the feature?
A faster pull request is only an early cost signal. To learn whether AI lowered the cost of a feature, follow the change into production and count the recovery and rework it creates.
By Nythrex team3 min read
A feature merges on Tuesday afternoon. The code took less time to produce, and the team celebrates the faster cycle. On Wednesday, an alert fires; an engineer pauses planned work to investigate. The merge-time saving is real, but it is not yet the feature’s total cost.
That distinction matters as AI-assisted coding becomes ordinary. Google Cloud’s 2025 DORA report found that respondents associated AI adoption with higher software delivery throughput and product performance, while also finding a negative relationship with delivery stability. Those are survey relationships, not proof that AI caused any one team’s outcome. The practical question for a leader is narrower: after release, did this feature require less engineering effort overall, and did it deliver the intended user outcome?
- Technology professionals contributed survey responses to the 2025 DORA report, announced September 24, 2025 by Google Cloud.
- Nearly 5,000
- Of DORA report respondents said they used AI at work, according to Google Cloud’s September 2025 report announcement.
- 90%
- Reported little or no trust in AI-generated code in the same 2025 DORA report announcement; this describes respondents, not all developers.
- 30%
The release is a boundary, not the finish line
DORA’s 2025 findings are useful precisely because they resist a simple productivity story: AI use was positively associated with throughput, but negatively associated with delivery stability. The report does not establish that AI-generated code itself caused incidents or quantify a per-feature cost. It points leaders toward the delivery system around the code—testing, version control, feedback loops and the ability to manage change volume.
DORA’s current delivery metrics guide gives teams a practical way to look beyond coding time. It distinguishes throughput—change lead time, deployment frequency and failed deployment recovery time—from instability—change fail rate and deployment rework rate. DORA advises applying the measures to an application or service over time, with context, rather than treating one metric as a universal score or comparing unlike teams.
AI adoption is associated with higher throughput and product performance, while delivery stability remains a concern.
Count the work that follows the merge
For a team lead, the overlooked cost often appears as interrupted work: incident investigation, rollback or hotfix effort, customer support, and follow-up changes. These hours may belong to different teams or cost centres, so a feature can look cheap in the development board while consuming time in operations. A release that causes no incident can still create ongoing support or maintenance work; record those categories separately instead of assuming they are zero.
Google’s SRE team describes using observability data, system topology and past incident knowledge to support incident investigation, while emphasizing transparency and controls that prevent unwanted production changes. That is an account of Google’s own approach, not evidence that a similar setup will save another organization money. The transferable lesson is to make post-release work visible and attributable before claiming a cost reduction.
Run a small, fair comparison this month
Choose one service and a set of comparable changes, and define the observation window before reviewing results. Record which changes used AI assistance without treating that label as proof of causation. For each change, capture engineering effort through merge, time to production, change failures, recovery time, incident-related rework and support effort. Add the user or business outcome the feature was meant to improve. Compare similar work and release contexts; note confounders such as team experience, architecture changes, traffic and release size. Use a baseline and a follow-up period, and report uncertainty when the sample is small.
Sources
Frequently asked questions
How can a team tell whether AI lowered the cost of a feature?
Compare similar changes over a defined period and include post-release recovery, rework and support effort alongside implementation effort. Also check whether the feature achieved its intended user outcome; association alone does not prove AI caused a change.
Which delivery metrics help assess post-release cost?
DORA’s guide includes change fail rate, deployment rework rate and failed deployment recovery time, alongside throughput measures. Use them for a specific service over time and interpret them in context.
Does faster AI-assisted coding guarantee more stable releases?
No. Google Cloud’s 2025 DORA report found a positive relationship between AI adoption and throughput, but a negative relationship with delivery stability. The report describes survey relationships and does not prove causation for an individual team.
Read next
Stop guessing.
Start seeing.
No card and no subscription: paid plans have not launched yet.