4 minutes
Nyquist Limit
the frequency of changes in tech is invalidating our understanding
Product teams are using LLMs to increase the frequency of change in technology, and near a certain limit, the sample rate (the human decision maker's rate of understanding and evaluating technology) would need to more than double every time the frequency of changes does in order to retain validity, but that's not happening. The result is that these teams think they're measuring signal, but are actually measuring noise and filtering that through an LLM to produce signal-shaped noise.
Software orgs experiencing this effect are giving up any ability to control their development cycles, resulting in frequent and costly outages that arrive without any pre-warning, and neither better prompting nor clever engineering is going to resolve this problem because the high pace of change is incompatible with the pace at which we can form a mental model of a system and comprehend it.
This points towards a mathematically simple answer with profound organizational implications: if you want to go fast and also maintain coherency, you must identify a target frequency of changes to the systems you care about, such that you can sample at (ideally much higher than) twice their frequency. This works because our only connection to knowledge is through periodic sampling, via our senses and the natural cycles within which we can inhale information and exhale insight. We need to resist the temptation to say "I can handle it, maybe I'm just built different" and respect that the relationship between change and understanding is a fundamental reality that we can only engineer and automate up to a certain point: the Nyquist limit.
To step back
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.
You can't write off a fundamental mathematical limitation as an engineering challenge
The mathematical field of signals processing gives us a powerful analytical framework for relating sampling, what we know about data from measuring data points, to the real underlying structure of the data. The sampling theorem describes a point at which our ability to make valid inferences about data breaks down at a mathematical level: if the rate at which we take sample measurements is less than two times the rate of real changes in the data, this destroys at a fundamental level our ability to make valid inferences from the data.
The sampling theorem promises us, with proof, that we cannot defeat the Nyquist limit with better models or clever engineering. The inputs are A) the ground truth rate of change in the system of interest, and B) the rate at which actual human beings can make qualitative observations about the system and integrate them into their (and the organization's) working system model. As you approach the Nyquist limit, an increase to A without an increase to B by at least double pushes you into a regime where you are measuring noise and the signal is lost.
