Mathematically speaking, you can't detect or act upon signals which are higher-frequency than half your sampling rate. This is the sampling theorem, and this upper limit of signal processing coherency is the Nyquist limit. Historically the process of software change management has not operated anywhere near this limit. Python creator Guido van Rossum widely socialized the phrase "code is read many more times than it's written," which could be rephrased to say we sample our technology's source and behavior many times more often than we change it. This puts your typical engineering organization, for the history of software up through the last ~year, well and clear beneath the Nyquist limit. However, various product organizations are betting big on pushing their rate of change ever-higher, up to the limit and beyond into the realm of signal-decoherence.
The evidence that these orgs do not understand their software is abundant, but I was jarred into perceiving this signal processing frame by a message a colleague who works at a tech unicorn (meaning a newer high-growth company with multi-billion dollar valuation) wrote me the other day (paraphrased:)
Everyone in tech brags about "disrupting" an industry but I do think AI is literally disrupting tech as a field. Everyone is acting like a startup, incumbents included. The whisper networks at hyperscalers abound with anecdotes of teams YOLOing in prod, with new bugs & security issues every day and the hot fix patches themselves introducing yet more bugs.
Every deployment is a unique haunted cemetery pet with its own impish personality and yet everyone feels too precarious to advocate for slowing down and getting things right.