Conformance vs Comprehension

In 1991, a young student from Finland changed the world.

In the mid-1990s I lead a team working on software configuration management tools for IBM — loosely an on-prem, pre-internet GitHub, with version control, issue tracking, and continuous integration. Overly ambitious for its time; trivial by today's standards — in no small part because that same student from Finland came back in 2005 and turned version control itself into a primitive, with Git. Hold that thought; I'll come back to it.

Our target market was enterprise, so we supported all the major Unix systems of the era: Solaris, HP-UX, and of course IBM's own AIX. Our code was C, and every source file opened with a thicket of #ifdefs to paper over OS differences. I saw this new thing called Linux, and one weekend I ported our code to it. My management appreciated the initiative, and as luck would have it, a visiting executive was coming to town — she had me present what I'd done to him.

Suffice it to say, he was not impressed. He saw no future in open source, least of all for enterprise customers. I could end the anecdote here by calling him an arrogant fool, or by noting that the distribution I'd happened to choose was Red Hat. But neither is my point.

Given the information available at the time, his call was eminently defensible. Open source was — and remains — chaotic and unpredictable. Enterprises require governance.

What I want to suggest is that he wasn't wrong about open source. He was wrong about where to look. He was governing the artifact — the code, the thing you inspect, certify, and support — and the artifact was not where the durable enterprise value was going to live. A decade and a half later, IBM paid thirty-four billion dollars for Red Hat. Red Hat did not sell the kernel. It sold conformance, certification, and indemnification: a way to govern open source without inspecting every line of it. The asset had relocated, from the code to the thing the code answered to, and the old model couldn't see the new location because it was busy guarding the old one.

I've spent a fair amount of my career standing near that relocation, on the side that builds the thing code answers to. Before I retired I spent years in the standards world — co-chairing HTML at the W3C, secretary for Atom at the IETF, ssitting in TC39 and convening the C# and CLI working groups at Ecma. That last one matters most for what I want to say today, because standardizing a language and a runtime is not standardizing an artifact. It's standardizing a behavior: the precise set of things an implementation must reproduce to count as conformant. ECMA-334 and 335 existed so that Mono could be a legitimate implementation of C# and the CLI without a line of Microsoft's source. The spec was the neutral oracle. The implementations were downstream of it.

So conformance-by-testing is the water I swim in. When I notice something, that's usually the shape I notice it in. I'm telling you this not to claim authority over the conclusions — a man with one project and a strong prior should not be claiming authority over anything — but so you understand why a particular thing jumped out at me, and why it might be worth a second look even though my sample size is one.

The project

Here is the thing that jumped out. Over a few months, retired, working with Claude as a co-author, I built a compiler called Roundhouse. It reads a Rails application — untyped Ruby — and emits standalone projects in several statically typed targets: Rust, Crystal, TypeScript, Go, Python, Elixir, plus a Ruby round-trip. The emitted projects compile clean and pass their tests. The way I know they're correct is a conformance oracle: the same URL fetched from Rails and from each target produces byte-identical responses, checked three ways — emitted unit tests against fixed expected values, a differential compare gate against live Rails, and end-to-end browser tests for the dynamic behavior a static diff can't reach.

I want to be careful here, because there are two different claims tangled in that paragraph, and they land very differently in a room like this. Let me pull them apart.

The first claim: the axis might be wrong

The retreat's findings land, in the section on languages for agents, on a sensible-sounding conclusion: languages that favor expressiveness over safety make both agent generation and human review harder. The room converged on strong static typing as a guardrail for agent output — make incorrect code unrepresentable.

Roundhouse is a small piece of evidence that the axis might be drawn in the wrong place. It performs whole-program type inference over an untyped Rails application and emits into typed targets that hold the safety property — without anyone writing a type annotation. The safety is real; the annotation tax is zero.

Now, I don't want to oversell this, because the typed-language people in this room will rightly hand me a counterexample if I do. Type...