How long will I be smart?

I have always assumed that it would be aging, ultimately, that pulled me back down into the fat part of the thinking distribution.  Recently, I have started to worry that there is another effect that could pull me down much faster - cognitive fitness erosion due to AI.

It's ironic that objectively speaking, I can now absolutely smoke my younger self with the help of AI.  Combining the knowledge, experience and intuition that I have developed over the years with the amazing processing power of current generation LLMs, I feel awesomely smart today.  I can do so much more than I ever could have before.  But there is this nagging feeling that it is all about to fall apart because my knowledge, intuition and reasoning ability are about to rapidly decline due to declining fitness and depth of understanding.

When I changed majors from math to philosophy in college, I had the good sense to keep taking math, math econ and physics classes to "stay in shape."  Even after graduating I kept working on things that exercised the math muscle.  That helped a lot when, 10 years after taking my last math class, I entered graduate school in math.  That was a pretty good workout.

Over the many years since then, I have always made sure to "get my workouts in" - starting an OSS math library; staying very hands-on as a tech leader; working on math-econ problems and continuing to read papers in math, stat, CS and other technical fields; leaning into hard technical problems at work. Every weekend I do something hard technical and if I don't get a good "workout" by mid-week at work, I try to squeeze in a workout at night during the week.

I am sure this regimen has helped keep me able to penetrate hard problems.  Recently, however, I feel like I have done the running equivalent of substituting easy jogging for the intervals in my workouts and I am getting worried about the fitness consequences of that.

Here is a concrete example.  The following would have counted as a "mid-week workout" were it not for the jogging in place of intervals.  At work, I needed to define and specify an algorithm for an order-preserving transformation of a set of scores so that selected values in the range of the scores ended up hitting specific quantiles.  I knew that this could be done easily with a piecewise linear transformation and some simple CDF inversion.  I drew pictures and waved hands, but did not see comprehension, so I decided to spec it out fully.  Pre-AI, this would have been a nice little workout.  Derive the formulas, fuss with the LaTex, create some worked out examples and write a little starter Python.  But last night I could just ask Claude to do it.  After a two-sentence prompt, Claude created a nice .md with embedded LaTex, worked examples and starter code.  I reviewed carefully and made some edits.  But I did not derive the formulas myself.  I did not work out the examples myself.  I just jogged through the review.

A lot has been written about the benefit of "the struggle" in working hard problems out for yourself and how LLMs are taking that away.  I agree with that, but I also think even just the simple, easy crank-turning stuff like deriving the formulas above is critical to maintaining cognitive fitness.

I don't think that the answer is to stop using LLMs or to force myself to do everything by hand.  The trick is how to get a really good workout working with the LLM.  What I have started to play with is a technique that I used to use when reading math papers which is to read a section and then try to generate what is about to come in the next section by myself.  So when reviewing the LLM work product, I select some key sections and when I get there in the review, I do just that part by myself, validating against the LLM output.  That is like putting a little fartlek into the jog through the review.  In the example above, I did that in the section where the CDF of the scores is inverted and the parameters of the transformation are derived.  Not a full workout, but more than a jog.

Another thing that I am focusing on is trying to spend more time in cognitively demanding conversations, often using LLM artifacts as context.  Amazon realized early that technical conversations are much more productive when they start with documents.  A good way to leverage the AI surplus is to create documents in advance of technical meetings.  Preparing in advance and answering questions in real time about docs that you create with LLMs is a good way to get to and sustain an elevated cognitive heart rate for a while. It also ensures that you really understand the content.

I guess that I am ultimately optimistic here.  I just need to modify my workouts to make sure they are hard enough and I can fit them into my routine.  It's kind of like when my knee eventually says "no mas" for running I will need to pick up rowing or something.  Anybody have a good cognitive rowing machine they can recommend?

Mutability considered harmful

We live in a constantly changing world.  Updates happen all the time.  It's counter-intuitive to say that we need to somehow avoid mutability. But we absolutely do in order to manage scaling and to be able to reason effectively about distributed information systems.  Here are some motivational examples:

1. Who saw what A system giving diagnostic tests to students maintains a database of students and tests.  They want to generate reports showing how many students in each state took the different test versions.  When they run the reports, the counts don't match counts taken when the tests were administered.  The problem is that students move and their addresses are updated when that happens.  
2. Patching A large company has a massive fleet of bespoke servers and workstations hosting diverse system and application software.  These systems need to be patched to address security vulnerabilities.  Every patch deployment carries incompatibility risk and has to be tested individually on each host.  
3. Replication  A social media company has a core application to manage posts and other activities.  Over time, marketing, analytics and all kinds of other applications in the company want to maintain their own copies of portions of the data in the main app.  Every time there is an update in the main app, a wild mess of spaghetti code propagates updates to the other application databases.
4. Distributed processing A system for processing financial transactions distributes transactions to processing services based on attributes in the transaction.  Processors can only handle transactions with the attributes that they expect.  Sometimes transactional attributes change after distribution.

The problem in each of these examples comes down to mutability in the distributed system design, or more precisely the lack of an immutable substrate to ground information distribution on.   In the first case, storing student addresses in a single, mutable field makes accurate reporting impossible. In the second, mutability of running systems forces treating them as "pets."  In the third, individually propagating updates becomes intractable at scale.  In the fourth, mutability in transactional attributes makes correct distribution impossible.

The third example is what motivated the invention of Apache Kafka by Jay Kreps and his then colleagues at LinkedIn.  The core idea is very simple: make an immutable log the definitive record of distributed state change and enable clients to consume the events in the log that they are interested in at their own pace.   

Using change data capture or a separate time-stamped address table to solve the first example comes down to the same thing.  Grounding infrastructure upgrades on versioned, immutable images and redeploying instead of "patching" comes down to the same thing.  In each of the first three examples. scaled and consistent behavioral mutability is enabled by grounding state changes in an immutable event log.  

The problem in the fourth example is that mutable objects are concurrency-hostile.  You can't allow concurrent access to them or use them in scatter-gather architectures without constantly worrying about how their attributes might change or how views of their state might be inconsistent.  Reasoning about distributed or concurrent processing systems that manage mutable objects is very hard.  Almost always, these problems can be avoided by favoring immutable objects, creating new instances instead of allowing mutation.

If you want your distributed systems to scale and to be easy to reason about, don't look at them as networks of mutable objects.  Instead, model state changes as immutable sequences of events and try to limit the need to share event information across context boundaries.