The on-call model is now the wrong unit of work

Production software no longer fails where it breaks. A checkout API times out, and the bug lives in a queue consumer two hops upstream, behind a schema change that a different team deployed two days ago. The on-call engineer's spatial, runbook-scoped, team-bounded mental model of production was built for a release cadence AI coding has just ended.

This is the production-complexity gap. InfoWorld's analysis makes the shape precise: the time it takes to create production complexity has collapsed, and the time it takes to understand it has not. The Cursor Developer Habits Report puts a number on the volume shift. One percent of AI-active developers now generate 46 times more AI-written lines of code per day than the median active user, which points to a growing gap between the time to create production complexity and the time to understand it. The implication that AI has compressed creation time but not understanding time is inference drawn from this volume premise, not a direct measurement. The new lines ship. The new mental models to hold them do not.

The old reading of an outage was single-hop, the failing service holding both symptom and cause. The new reading is multi-hop, and it has become the default in systems running that volume. The team owning the failing service is increasingly not the team that caused the failure. Runbooks scoped to a service, on-call rotations mirroring org boundaries, postmortems written by the team paged at 3 a.m.: each was designed for the previous shape of failure.

The question for every ops team this year is not which tool to buy. It is whether the unit of work in incident response is still the service, or whether it has become the chain.