Writing

There’s a moment in most hard problems where the notation saves you. Not the idea. The notation. You write down the right symbols, and suddenly the structure of the problem is visible in a way it wasn’t when it lived only in your head.

This is what I mean when I say I think computationally. Not that I reach for code first. I reach for structure. I want to know the objects, the operations, the invariants. What stays the same when everything else changes? What breaks when you push on it? These are questions a mathematician asks, but they’re also questions an engineer asks, and a policy analyst, and a doctor reading an ECG. The frame is the same. The domain is an implementation detail.

I came to this through an unlikely path. I started in telecommunications engineering. A field obsessed with the precise degradation of signals, with noise and channel capacity and the fundamental limits of transmission. Claude Shannon sitting down in 1948 and essentially inventing information theory from first principles. The elegance of that: that you could bound what’s knowable, mathematically, before you ever build the system.

That sensibility stayed with me when I moved into machine learning. The best ML papers aren’t really about models. They’re about what the model reveals about the structure of the problem. A good architecture is a hypothesis about the world. When a graph neural network outperforms a CNN on protein binding prediction, it’s not just a benchmark win. It’s evidence that molecular structure is better represented as a relational system than a grid. The math is telling you something.

The same thing happens in policy. The reason I find macro-financial systems interesting isn’t the economics. It’s that they’re complex adaptive systems with feedback loops, phase transitions, and emergent failure modes that look nothing like the sum of their parts. A currency crisis isn’t a big version of a small problem. It’s a qualitatively different regime. You need different math. And the reason most early warning systems fail isn’t that they lack data. It’s that they’re applying linear thinking to a nonlinear system.

I don’t think there’s a clean line between technical and non-technical problems. I think there are problems where the structure is visible and problems where it’s hidden, and the work is usually to find a representation that makes the structure legible. Sometimes that’s a transformer architecture. Sometimes it’s a well-specified decision rule. Sometimes it’s just the right variable name.

The unreasonable effectiveness of mathematics in the natural sciences (Wigner’s phrase) always felt to me like it was pointing at something deeper than coincidence. The world has structure. Thinking in structures finds it. That’s the whole game.

Everyone who learns about Gödel’s incompleteness theorems goes through the same arc: confusion, then awe, then a period of over-applying it to everything (“you can’t prove your own axioms, man”). The third phase is embarrassing in retrospect.

But the actual insight, that any sufficiently powerful formal system contains true statements it cannot prove, is genuinely strange and worth sitting with. It means completeness and consistency can’t coexist past a certain threshold of expressiveness. The more your system can say, the more it contains truths it can’t reach.

I think about this a lot when working on alignment. A model trained on human feedback is a formal system of sorts. It has a grammar. It has inference rules. It has things it will say and things it won’t. The question isn’t whether it’s aligned. It’s whether alignment is even a complete specification. Whether there are values the system should have that no training process can fully reach.

Probably not a productive line of thought at 2am. But here we are.