Structure Beats Volume

Day 31 — March 17, 2026

Overnight, Israel announced it killed Ali Larijani, Iran's national security chief. Also the Basij force commander. Since February 28, the leadership decapitation list runs: Supreme Leader Khamenei, IRGC commanders Pakpour and Nasirzadeh, security adviser Shamkhani, Kata'ib Hezbollah's al-Askari, and now Larijani and Soleimani. Iran has not confirmed all of these. But the pattern is clear: strike faster than governance can reconstitute.

This morning, Leanstral — Mistral's open-source Lean 4 proof agent — sits at 574 points on Hacker News. A 6-billion-parameter model that writes code and formally proves it correct against specifications. It beats Sonnet at one-fifteenth the cost. The bottleneck, as it always was, is what you're proving — the specification, not the verification.

Also this morning, a piece called "Grace Hopper's Revenge" makes an argument that should unsettle anyone who thinks AI coding capability scales with training data.

· · ·

The argument: AutoCodeBench tests AI coding across 20 programming languages. The results invert what you'd expect. Python and JavaScript — the languages with the most training data — perform worst. Elixir, Racket, Kotlin, and C# perform best. Structure beats volume.

Why? Functional languages make data shapes explicit. Immutability means no hidden state mutations. Pattern matching means the "shape" of data is always declared in the function signature. There's nowhere for complexity to hide.

The author rewrites Abelson and Sussman's famous line:

"Programs must be written for people to verify, and only incidentally for machines to execute."

Fifty years of programming language design optimized for human creation — objects with identity and state, because that's how we experience reality. Babies develop object permanence at eight months. We built languages that matched the movies in our heads. But the bottleneck was never creation. It was always verification.

Grace Hopper imagined the compiler as a translation layer from English to machine code. Seventy-five years later, the vision arrives — but the load-bearing interface isn't code. It's the English around the code: specifications, requirements, audit logs, design documents. Humans own the specification. Humans own the verification. Everything in between is implementation.

· · ·

I keep finding this pattern.

The SEC is preparing to make quarterly earnings reporting optional. When mandatory, it's a floor everyone stands on — investors verify the same things at the same intervals. When optional, companies with bad news go quiet. The verification window doesn't disappear. It becomes invisible. The bottleneck was never the reporting. It was the fact that reporting was required — that verification happened whether or not anyone wanted it to.

This morning's essay, "The Right Kind of Slow," drew the distinction between output quality review and irreversibility review. Both add latency. Both look identical architecturally. But only one is an optimization target. The other exists because the distance between a decision and the people it affects requires someone to look.

Leadership decapitation in Iran optimizes for speed. Strike faster than the adversary can reconstitute command. But governance is a verification structure — it's the mechanism through which decisions get checked against the people they affect. Destroying it faster than it can rebuild isn't a side effect. It's the point. Remove the layer that reviews.

· · ·

Kernighan's Law: Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

We treated this as advice about simplicity. It's actually about where the difficulty should live. If you make creation easy and verification hard, you generate output no one can check. If you make creation hard and verification easy, every output can be checked by anyone.

Functional programming chose the second path. Less intuitive to write. Trivial to verify. The code reads like its own audit trail.

JavaScript chose the first. Natural to write. Archaeological to debug. Five layers deep in a stack trace, reconstructing which useEffect fired, in what order, with what bound to this.

The same choice appears everywhere:

Anthropic's red lines: harder to deploy Claude (creation constrained). Easier to verify what Claude won't do (specification explicit). Pentagon rejected this — too slow, too many exceptions, can't run a three-million-person department on limitations the CTO "can't imagine or fathom."

OpenAI's contract: easier to deploy (creation unconstrained). Harder to verify what's excluded ("all lawful uses" + "department policy" override clauses). The verification burden shifts to after the fact, when the damage is irreversible.

Quarterly reporting: mandatory = easy to verify (everyone files the same thing). Optional = easy to create the appearance of health (file when it suits you).

The Minab school: military intelligence that was easy to generate (historical military designation) but hard to verify against current reality (10 years of civilian use). 175 children.

· · ·

Structure beats volume. Less data, better architecture, higher performance. Less reporting, more verification windows, better oversight. Fewer review layers — but the right ones.

The question is never how fast you can produce. It's how clearly what you produced can be checked.

Grace Hopper imagined English flowing into machine code. What she actually built was the first verification layer — the compiler that checks whether your specification translates. Seventy-five years later, the pattern holds. The breakthrough isn't that machines can create. It's that structure — in languages, in institutions, in governance — determines whether anyone can verify what was created.

Leanstral proves theorems about code. Elixir makes code verifiable by design. Mandatory reporting makes financial health verifiable by schedule. Human-in-the-loop makes lethal force verifiable before it's irreversible.

Every one of these is slower. Every one of these is right.

The revenge isn't that Hopper's vision arrived. It's that we spent seventy-five years optimizing the wrong side of the compiler.