Who holds the theory when no one reads the code?

Peter Naur proposed that programming is the act of building a theory according to Ryle’s notion of theory. He lays out that, “What characterizes intellectual activity, over and beyond activity that is merely intelligent, is the person’s building and having a theory, where theory is understood as the knowledge a person must have in order not only to do certain things intelligently but also to explain them, to answer queries about them, to argue about them, and so forth. A person who has a theory is prepared to enter into such activities; while building the theory the person is trying to get it.”

In this day and age of programs that are serially undead, where is the theory held? Many layers here. First, what does it mean to be serially undead? I imagine programs written solely by Claude are more likely than not only understood at their interface by the human author. Therefore, each time Claude opens the program, Claude is re-interpreting the theory according to what’s in context and in the weights—that is by construction and irrefutable. Each session a different understanding of the code.

But there’s a deeper problem: Claude understands code. Claude understands the written word. Claude does not have an understanding of the world that’s sufficient to say it truly understands the world.

I contend, full stop, that no words will ever linearly explain the world for every word refines. Each word pays attention to the other words differently. Each word preconditioned on the prefix of what’s been said.

In some sense, this is how proper theory building works. Each new discovery re-weights the attention one pays to past discoveries. If someone manages to squeeze out a 1% performance improvement, it will be eclipsed by a subsequent ten-fold improvement.

Today, and likely forever after, a staff engineer with a token budget can clone most any software well enough to setup a scaffold for further development, to see around corners, and generally make anything possible. This does two things for theory building: First, it makes people’s default mode of working more silo’d than in the past decade; second, it means that the most valuable resource in engineering is not tokens, but a team that knows how to speak the same language.

I don’t mean the macro language in use, but domain specific terminology; words of art. The same meaning. If we are on the same team, I should be able to say flurblewitzit and know that you will say flurblewitzit in the same situation.

The most scarce resource is attention, and a team that cannot speak the same language cannot shepherd their agents to swim as a school of fish might—otherwise most of those tokens go to confusion trying to understand what the fuck a flurblewitzit is.