I liked the commentary and the metaphor with the Nyquist theorem. Mathematically speaking it's invalid but the problem being discussed is real - when the velocity of code generation (accelerated by LLMs) outpaces human cognitive capacity to review, test, and mentally model the system, structural coherence collapses.

And we're already there, it's beyond our cognitive capacity to fully understand the (AI) produced volume of work for given unit of time.

In order to really mitigate the human bottleneck, we will either have to reach the AGI, which might not come in the next 10 years or so, or change the form of how we're doing work, review included.

It's an interesting metaphor, but the math is not directly applicable to software engineering, because the shape of the problem (not to mention the terms) doesn't translate.

The main problem is that shannon-nyquist is concerned with discrete representation of a continuous/analog signal. But TA is applying it backwards: software is discrete and human understanding is analog. So human "sampling" of software is not something an A->D theory can speak to.

Funnily enough, there are techniques that allows to go under the Nyquist limit, eg compressive sensing.

I don't like the analogy, it supposed that AI generated code will always be badly organized underneath if it is automatic, however, as time goes, I find the code better and better..

Seems like a forced analogy. Is the signal a periodic and regular frequency?

If its a straight line you need 2 samples.

If its not you probably need more.

Id argue codebase understanding is neither of these simplifications

Thank you for the article. However, I wholeheartedly disagree. AI available to the general public may produce both code and fixes to code as an endless accretion of bugs but that's not necessarily how it will always be. Human analytics with regard to any code within a system is essentially a result of accumulated (analytics) knowledge toolified as checks and constraints. What stops, say a military application of AI from having those analytics present during code generation?

It would be really interesting to see an AI create a new kernel for Linux that every piece of it's code was written and verified-secure by having it analyzed and exploited simultaneously.

We, humans, don't need to be as fast as our tools.

On a personal note, I can't wait to see new silicone and operating systems made specifically for AI. That will be cool!

I personally found hard to see this analogy at first, because the assumption of human understanding as fs seems hard to make, as I don't see human understanding as linear and measurable. Also if fs mapped well, we could just increase fs to be able to reconstruct the signal better by interleaving more brains at it and we know of manmonthian consequences, and this kinda what the main point of the post is, that human comprehension don't scale. In fact, to me, some sort of digital inteligence seems more fs-shaped than a human one.

But overall cool read to make you think, where you can see a dev brain as an ADC, design paradigms or microservices as band pass filters, apis as low pass, frameworks as downsampling, legacy code as DC signal that you don't touch, etc.

The amount of app updates - I don't have auto update turned on - is now completely ridiculous.

LLMs plus continuous delivery - what a gruesome twosome.

You change what the signal is. Simple as.

The author assumes that human understanding and modeling is essential. However, this no longer appears to be the expressed preference of the industry.

AI advocates nowadays are calling for abolishing human code review. So code moves from read-often-write-rarely to read-once-write-once to read-never-write-often. The assumption is that we can rely on the agents to decipher the code if needed.

My feeling is that software "engineering" in the future will be basically a cargo cult or the Adeptus Mechanicus from Warhammer 40k: all detailed technical knowledge comes from the gods, humans only manage the rituals around technology.

It's like you've ended up inside your own OODA loop.