Plain is an open-source specification language whose thesis is that code should be regenerated, not maintained: you fix the spec, and the code is ash. I agree with almost all of it — the implementation is no longer the asset, and the cost of building what replaces it has collapsed. Where I differ is narrow and load-bearing: not whether to throw the code away, but what gives you the right to. History only ever issued two licenses for that — a proof or a reference — and Plain holds neither, regenerating from a prose spec and checking the result with tests generated from that same prose by the same probabilistic renderer: a court holding its own trials. My answer is to author the reference instead — write the app fast in Rails, validate it by watching it run, and keep the running thing as the oracle. We both start from a blank page; the difference is the medium: a prose spec can't run, so it can never be its own oracle. A Rails app can, so it is.
This week I'm at a retreat on the future of software development, and this is the perspective I'm bringing to explore, in one place. A few months of posts argues it strand by strand; here is the shape they make together. For a few months now, retired, I'm building a compiler I can't read against an oracle I could — and the through-line of everything since is what that arrangement implies once you notice that the cost of building it has collapsed, from an institution and years to a person and a few months. The asset relocates from the implementation to the oracle; rigor moves from comprehension to conformance; managing the agent inverts into managing by objective; and the abstraction ladder, stalled for a decade because each rung needed a funded team, starts climbing again. Which leaves one question for the room: when anyone can build the thing code answers to, do we still know which things are worth answering to? With links to where each piece is argued in full, and the sample-of-one caveat over all of it.
I was asked to speak to my experience using AI to build software, and it surprised me — I've been at this less than a year, in a field where the words you hear most are slop and hallucination. That hasn't been my experience, and the reason comes down to one change I made early, almost by accident: I stopped issuing choices — do A, do B — and started asking a question instead, what do you recommend? That was the unlock. It is the same move I learned leading a team in the nineties, where a good lead's value is rarely being the most knowledgeable person in the room — it is drawing out whoever is. Peter Drucker named the shape in 1959: when the worker knows more than the manager, you manage by objective, not method. What I haven't resolved is the word peer — the agent contributes like one and has the stake of a tool, and I've been navigating that mismatch by borrowing the instincts that worked on the human version and hoping it doesn't bite.
The durable asset in software keeps relocating — from the code you inspect to the thing the code answers to. Red Hat sold conformance and certification, not the kernel; Ecma standardized C# as a behavior, not a source tree; and over a few months, retired, I built a compiler I can't read against an oracle I authored. From that sample of one, two claims for a room convinced the axis is expressive-versus-safe: it is really annotated-versus-inferred, and the cost of authoring the artifacts that used to require institutions has collapsed. The harder claim is what that did to me. For three months conformance didn't augment comprehension — it replaced it; I never read the generated code and couldn't have judged it if I had. The rigor didn't vanish, it moved: to the oracle the code answers to, where the conformance test does the overwhelming work and the spec is only the court of last appeal.
For fifteen years the place where software gets defined has been rising — nobody chooses Ruby, they choose Rails — and that migration didn't stop. This walks the ladder one rung at a time: the framework becomes a whole-app compiler, the compiler goes full-stack, the targets stop being exercises left for the student, and finally the compiler turns around and answers questions about everything it made invisible. The motion is old; what's new is the engine. Building the tool that reaches each rung used to require an institution — a funded team, a standards body, years — and now requires a person and an afternoon. With the graveyard kept in view, because a ladder of rising abstraction has one at its base, and the only discipline that separates this from it is telling an artifact boundary from an essential one.
"Bring me a rock" is a slur — it names a manager who substitutes serial rejection for the work of saying what they want, and makes you pay for their unfinished thinking one rock at a time. I want to argue that under conditions that now exist, the dysfunction inverts into a defensible way to work: not because the manager got better, but because the three things that made it a slur — imposed cost, latency, and exploited patience — quietly go away once it is peers exploring together with a tireless agent instead of a boss imposing on a subordinate. What doesn't go away is harder. Cheap iteration removes the one signal, cost, that used to tell real discernment from expensive dithering, and the peer framing means the recognition behind each rejection has to be not just real but shared.
Roundhouse infers types across a whole Rails app in order to compile it to nine languages. Two earlier posts showed what those types buy: correct transpilation, and an order-of-magnitude performance win. But the inference is a product in its own right. The same engine that resolves Rails' metaprogramming to emit Rust can answer an editor's or an agent's questions — what's the type here, can this be nil, what won't survive ejection — with no annotations, no app boot, no database, no running server, and in a few milliseconds on a small app, a couple hundred on a large one. Static, deep, annotation-free, and fast enough to run on every keystroke: a cell of the design space no existing Ruby tool occupies.
Roundhouse has three browser demos — a blog, a playground, and a studio — and they look a lot like ones I've shown for Ruby2JS. The resemblance is real; the engines are not. Underneath is a typed cross-compiler instead of a heuristic Ruby-to-JS transpiler, and the playground is where you can see the difference: hover any expression and read the type, inferred by chasing back through the view, the controller, the model, to the schema.
In April I bet that Roundhouse and Spinel — two Ruby compilers started a month apart, by different people, neither aware of the other — would compose: that the metaprogramming-free Ruby Roundhouse emits is exactly the Ruby Spinel was built to compile. I enumerated the gaps in the way and filed the first one. Two hundred thirty-nine closed issues later, the round trip runs end to end: an arbitrary Rails app, lowered to a Ruby subset, compiled to a standalone native binary. This is what the bet looked like when it paid off — the numbers, the gap that turned out to dwarf the five I could see, and why the seam between the two compilers was never a coincidence.
Every post in this series so far has reported something measured. This one extrapolates. The bet: frameworks that are runtime libraries today will increasingly become transpilers, the interpreter will be demoted from runtime to referee, and the scarce asset will turn out to be neither the framework nor the compiler but the oracle they are tested against — where the oracle is a layered construction, not a single DOM diff. With the soft spots named up front and a falsifiability list, because an extrapolation that won't say what would sink it isn't worth your time.
Rails developers who know JRuby have a fair question for Roundhouse: what does compiling Rails to other languages offer that two decades of running Rails on the JVM doesn't? Part of the answer turns out not to be a competing pitch at all. The same Roundhouse-emitted Ruby that runs under CRuby runs unmodified under JRuby, and two effects compose: compiling away Rails' interpretive layers is worth an order of magnitude before the JVM enters the picture, and the static Ruby that remains is the program the JVM JIT was built to optimize — a further 5–6×, where stock Rails gains at most 2×. JRuby's JIT was never the limit. The input was.
Follow-up to Show Your Work: preliminary benchmark numbers across eight target surfaces, with an honest accounting of what the numbers do and don't tell you. The mechanism post argued for browseable code over benchmark trust; this one shows the measurements anyway, with enough caveats that nobody should overread them.
Thoughtworks published a thoughtful synthesis from a senior-practitioner retreat on the future of software engineering. From a sample of one — a retired developer working on a single project with an LLM co-author — three of its conclusions look different from where I sit. Not wrong; different. Probably because we are observing different regimes.
In 1959, Peter Drucker observed that knowledge workers know more about their work than their managers do, and that this required a different management discipline: managing by objective rather than by method. The relationship between a software developer and a coding agent has the same shape — inverted. The principal knows less than the worker. Drucker's prescription still applies.
The previous post argued that the compilers were already capable of more than Rails has been letting them do. This post is the how — three shape-stabilizing moves the lowerer makes, shown in actual emitted code, with the honest limit: only a subset of Rails fits through today, and the work ahead is widening it.
YJIT, ZJIT, V8's TurboFan, Spinel — sophisticated compilers, all of them, all operating near the limit of what their input shape allows. The Rails idioms that frustrate one frustrate the others. Roundhouse doesn't replace this work. It removes the barrier that keeps it from landing on Rails.
Yesterday's per-resource specialization PR took 24 minutes of commit time. The handoff document estimating it called for 3-5 days. The asymmetry between decision time and implementation time is the experience this post is about.
An architectural decision Roundhouse just made, forced by Spinel and validated by Prisma: specialize the closed axis, defer the open one. The Rails-blog real-blog → Spinel error count dropped from 22 to 6 in one PR. The principle is older than this work — but it generalizes cleanly to a multi-target transpiler.
Four days ago I argued the Spinel subset was the same intermediate language Roundhouse needed. The bet then was that the maturity gaps would close on both sides. Four days in: Matz called Roundhouse "a great forcing function," seven issues have been filed, six are closed, and the channel runs at roughly one fix per day.
Most type systems force a single bet about where to set the dial between programmer annotations and compiler inference. Today Roundhouse declined to set it. Ty::Untyped landed as a first-class type — the IR's load-bearing primitive for deferring per-target, per-code-category, per-stage strictness decisions until there's evidence about what to decide.