Reliability & operations · Book notes
Accelerate and the four key metrics when an agent ships the change
When an agent ships the change in minutes, do the stability metrics carry the meaning that lead time and deploy frequency lose?
If you have an agent writing tested code for you and shipping it within minutes, your four key metrics from Accelerate will look great almost by default. Lead time drops to minutes, deploy frequency increases per merged change, and your dashboard lights up green no matter the quality of the work. It makes me wonder what those numbers even measure when the author of the code is a program.
Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim was published in 2018 and drew on 4 years of research from the State of DevOps survey. The metrics that came out of it have become a common vocabulary for engineering leaders to talk about delivery. Readers of the book often feel that the main thing it brings to the table is evidence to help justify practices that should be obvious in the first place.
Chapter 2 introduces the four metrics (split into two pairs: throughput (delivery lead time and deployment frequency) and stability (time to restore service and change fail rate)) and describes the research that shows that high performers excel at both (debunking the myth that you have to choose between speed and stability). The chapter also debunks common proxies (lines of code, velocity, utilization) as measures of productivity.
While metrics are outcomes, the book mostly discusses drivers: 24 capabilities that are measured alongside the four metrics. There are also separate chapters discussing continuous delivery practices and architecture. In particular, loosely coupled design (where a team can test and deploy their part without coordinating with other teams) is mentioned as one of the biggest contributors to continuous delivery.
One criticism of the research is that the data comes from surveys using an open questionnaire distributed via social media, which is snowball sampling. DORA’s own lead, Nathen Harvey, has warned against using the metrics as targets or for comparing teams, because any metric that becomes a goal will be gamed.
The metrics have changed since the book. DORA renamed time to restore to failed deployment recovery time and added a fifth metric later: rework rate. The 2024 report linked a 25 percent increase in AI adoption to an estimated 7.2 percent decrease in delivery stability. The 2025 report says AI now improves throughput but still harms stability, describing it as an amplifier of whatever system it enters.
My own fleet of agents is just one small data point, but my monitoring agent, Sentinel, filed a correct fix for a real outage, and the proposal went unapproved for some 13 hours. Approving it as-is would have edited deployed files, which would have been overwritten by the next push. The outcome is described in Running an agent fleet like a small team: infra fixes now arrive as repo changes.
The lead time of the fix was the time I took to say yes to the agent’s proposal. The agent had finished its part in minutes, so speed isn’t in that number. It makes me wonder: when the work itself is nearly instant, whose clock does the lead time measure?
If an agent ships the change, do lead time and deployment frequency measure the review gate more than the work? If so, maybe change fail rate and rework rate will continue to be the numbers that tell us something about the software itself.