If your SaaS company's engineers use AI coding tools, report the share of your deployments that fail next to how fast you ship, every month, and when that share rises, put the next dollar into automated testing and continuous integration ahead of more AI seats, keeping the seats you have.
Google Cloud's DORA research program surveyed nearly 5,000 technology professionals for its report published in September 2025. In that survey, 90 percent of respondents report using AI at work, and more than 80 percent believe it has made them more productive. The research found AI adoption linked to higher delivery throughput, and also that AI adoption does continue to have a negative relationship with software delivery stability.
DORA's reading is that faster work can expose weaknesses downstream: where automated testing, version control practices and feedback loops are weak, a rise in the volume of changes brings instability with it. The same report found that teams working in loosely coupled architectures with fast feedback loops see gains, while those constrained by tightly coupled systems and slow processes see little or no benefit.
DORA measures instability with two numbers an engineering team can pull from its deployment and incident records. Change fail rate is the ratio of deployments that require immediate intervention following a deployment, usually a rollback or a hotfix. Deployment rework rate is the share of deployments that were unplanned and happened because of an incident in production.
Put both on the monthly review for each main product, since DORA's guide says the metrics are best suited for measuring one application or service at a time. Beside them go what the AI seats cost that month and two of DORA's speed numbers: deployment frequency, and change lead time, the time a committed change takes to reach production. The same guide warns that setting metrics as a goal makes teams likelier to game them, so these numbers steer the next dollar and stay out of team targets. Then price a failed deployment the way finance would: the engineering hours on the incident and the rollback, plus any service credits owed under customer contracts. That puts the month's failures in dollars beside the month's seat cost, and gives finance a figure to size the testing budget against.
For a SaaS company selling scheduling software to clinics, the review might show deployments up since the rollout and change fail rate up with them, each failure carrying engineer hours and, where access dropped, a credit to the clinics affected. That company keeps its current seats, adds none, and puts the next dollar into automated tests and continuous integration, sized against the monthly cost of its failures, until change fail rate stops rising.
InfoQ's May 2026 summary of DORA's report on the return from these tools makes two separate points. The report expects most organizations to go through a temporary productivity dip before achieving long-term gains, partly from what the summary calls the verification tax imposed by reviewing AI-generated code, and warns that leaders who read the dip as failure risk pulling funding during the dip and losing the eventual return. Its return model also counts delivery instability as a cost, shown in its sample calculator as downtime from an assumed rise in change failure rate, and its authors say that cost is no reason to delay adoption and present it as a reason to invest in automated testing, continuous integration, and working in small batches.
For a PE-backed SaaS company, the failure numbers come from the same deployment and incident records a buyer's technical diligence can read.
