Edit this page


Pencils Down, Intent Up — AI as the new abstraction above Ruby
The new abstraction boundary: from human intent to agents, then into programming languages and systems.

Pencils down. Intent up. If AI becomes the abstraction closest to human intent, Ruby may matter less as what we type—and more as what we still want to understand.

DHH walked onto the Rails World 2026 stage with a message that would have sounded almost heretical a few years earlier: put the pencils down.

Not because programming no longer matters. Not because software engineering has disappeared. But because the highest-leverage work is rapidly moving away from manually typing every implementation detail and toward delegating as much as possible to AI agents—then improving how we specify, evaluate, correct, and evolve what those agents produce.

For someone whose work helped make programming itself feel more human, that is a remarkable turn.

I had been critical of DHH for spending so much energy on Omarchy while, from my perspective, Ruby on Rails seemed to be moving more cautiously around AI. But perhaps I was looking at it backward. Omarchy may have been part of the path that made this shift visible. Its own site now presents it as an agentic Linux and explicitly describes an environment where agents can debug problems, customize the system, and help users change it continuously.

The interesting question is therefore not whether DHH changed his mind.

The interesting question is what he finally saw.

The abstraction closest to the programmer is no longer necessarily a programming language. It may be AI itself.

And that changes the Ruby conversation completely.

Contents

The pencils-down moment

The Rails World 2026 opening keynote is useful precisely because the message is not subtle. DHH is describing a new default: instead of beginning with handwritten implementation, begin with delegation.

That does not mean engineering judgment disappears. In fact, it makes judgment more important.

The engineer still has to decide:

  • what should exist;
  • what constraints matter;
  • what trade-offs are acceptable;
  • what evidence is sufficient;
  • whether the result is understandable;
  • whether it belongs in the system at all.

The mechanical act of producing source code is only one part of that work—and increasingly, it is a part an agent can perform.

The provocative phrase is therefore useful because it forces us to separate two things we often treated as the same:

programming and typing programs.

They are no longer synonymous.

The abstraction moved again

Programming has always been a history of abstraction.

We stopped thinking directly in electrical states. Then we stopped writing machine instructions. Assembly gave way to higher-level languages. Higher-level languages moved closer to the domain. Ruby went unusually far in that direction by making expressiveness, readability, and programmer happiness central design concerns.

Then another layer appeared.

The important thing about this diagram is not the exact order of every technology. It is the direction of travel.

Each major abstraction layer lets the human express more intent with less concern for mechanism.

Ruby was important because it moved programming closer to the way developers wanted to think.

AI moves the interface closer still.

When AI became the new Ruby

The abstraction stack from machine and assembly through programming languages, Ruby, AI agents, and human intent
AI moves the abstraction boundary closer to human intent; programming languages remain implementation layers beneath it.

In my earlier post, When Ruby Made the Industry Rethink Programming, I ended a section called The question for today with this thought:

Today’s Ruby might become tomorrow’s assembly.
And AI, tomorrow’s Ruby.

The phrase can sound like a demotion of Ruby. I increasingly think it is the opposite.

Ruby’s historical advantage was that it felt unusually close to the programmer. It removed ceremony. It let ideas surface with less syntactic friction. It treated source code as something humans should enjoy reading and writing.

But natural language is closer to human intent than Ruby syntax can ever be.

That means AI is now occupying the position that Ruby once occupied relative to lower-level languages: the most human-facing abstraction in the stack.

The interface becomes something like:

Human intent
    ↓
Natural language
    ↓
AI / agents
    ↓
Ruby / Elixir / Java / Rust / ...
    ↓
Runtime / hardware

The consequence is profound: the programming language may increasingly become an implementation target rather than the primary interface through which the human expresses the system.

Omarchy may have been the laboratory

Omarchy represented as an agentic operating environment where user intent flows through agents into terminal, files, plugins, themes, debugging, and automation
Omarchy as an agentic environment: intent is delegated into tools, diagnosis, configuration, and continuous change.

This is why I now see Omarchy differently.

I used to look at DHH’s attention on Omarchy and think: why invest so heavily there while AI is changing the development model around Rails?

But Omarchy itself may have been an experiment in exactly that new model.

The project’s current language is explicit: Omarchy describes itself as “Beautiful, fun & agentic Linux” and as a malleable operating system for the age of agents. Its site says agents can debug issues and that users should be able to modify the operating system with the same ease with which they can vibe-code an application.

That moves AI out of the editor sidebar.

The agent is no longer just autocomplete.

It can become a participant in the environment:

The environment becomes malleable.

That is a very different mental model from “AI helps me write code faster.”

And it helps explain the Rails World message: once you experience software as something that can be changed through intent and delegation, manually writing every line begins to feel like starting one abstraction layer too low.

Performance is becoming cheaper to explore

Another clue came shortly afterward in DHH’s post about converting an implementation to Ruby with AI.

The interesting part is not simply that a Ruby version could perform well in a particular experiment. Performance comparisons are highly workload-specific, and one result should not be turned into a universal benchmark.

The larger point is this:

DHH did not have to personally perform every step of the rewrite. The AI could explore the implementation space for him.

That changes the economics of experimentation.

Historically, a rewrite carried a large human cost:

idea → design → rewrite → debug → benchmark → reconsider

Now the loop can become:

idea → delegate → inspect → benchmark → redirect → repeat

The cost of asking “What if we implemented this differently?” collapses.

That matters more than any single benchmark result.

Ruby does not need to beat Rust at being Rust

For years, programming-language discussions often became contests:

Which language is faster? Which runtime uses less memory? Which compiler produces the best machine code? Which ecosystem wins the benchmark?

Those questions still matter. Infrastructure does not become free because an agent wrote the code.

But the strategic meaning changes.

If an AI agent can generate a specialized Rust implementation when a hot path genuinely needs Rust, Ruby does not necessarily need to transform itself into Rust to remain relevant.

Likewise, if Java is the better fit for a particular deployment environment, an agent can explore that path. A reply to DHH’s performance discussion even raised exactly that question: why not consider Java rather than Rust?

This is where the new abstraction layer becomes liberating.

The language does not need to win every category.

The system needs to make it cheap to select the right implementation while preserving a surface humans can understand.

The language we still want to read

AI agents producing implementations in Ruby, Rust, Java, and Elixir, with Ruby highlighted as a readable artifact for human review
When agents can generate many implementations, the human bottleneck shifts toward reading, reviewing, and maintaining the result.

There is a paradox here.

As AI makes writing code cheaper, reading code may become more important.

Agents can produce far more code than a human can review. They can generate alternatives in Ruby, Rust, Java, Elixir, or whatever else is available. Human attention, however, remains scarce.

That means a new optimization target appears:

In an agentic world, readability may become more valuable than writability.

Imagine assigning an agent a substantial task. It returns an implementation. You now need to decide whether to trust it, modify it, maintain it, explain it to another engineer, or debug it six months later.

Which language do you want to encounter?

That question gives Ruby a powerful new role.

Not necessarily the language humans type the most.

Perhaps the language humans most want to read.

Ruby’s human orientation becomes an interface for verification.

The question is no longer just, “What is easiest to produce?”

It becomes, “What leaves behind the clearest artifact for humans and agents to reason about together?”

Ruby has an unusually strong answer to that question.

Spinel, JRuby, and the cost of opportunity

This is also where projects such as Spinel become interesting in a different way.

Spinel is an ahead-of-time Ruby compiler. Its current README describes a pipeline that parses Ruby with Prism, performs whole-program type inference, emits optimized C, invokes the system compiler, and produces a standalone native executable.

That is technically fascinating.

But the arrival of agentic development introduces another question beyond technical merit:

Where should the Ruby community spend its finite attention in a world where agents make cross-language experimentation dramatically cheaper?

That is not an argument that Spinel should not exist. Experiments that push Ruby into new execution models can teach us a great deal.

It is an argument that the opportunity cost has changed.

If the goal is to reach different runtime characteristics, perhaps some experiments should also revisit paths that already connect Ruby to mature execution environments.

JRuby is the obvious example. JRuby is Ruby on the JVM. Its current project site highlights real threading, the JVM library ecosystem, platform independence, and Ruby 4.0 compatibility in the current JRuby 10.1.x line.

That suggests a different kind of question:

Instead of asking only:

How do we make Ruby itself compile into something faster?

we can also ask:

How can agents make the cost of moving Ruby workloads across execution models almost trivial?

Those are not mutually exclusive paths.

They are experiments in a much larger search space.

What if the answer is not Ruby?

And then comes the uncomfortable—but useful—question.

What if the best answer for a particular subsystem is not Ruby at all?

Perhaps the system needs the JVM ecosystem.

Perhaps it needs Rust at a performance boundary.

Perhaps it needs the BEAM.

Elixir is especially interesting in this context because its strengths are not merely syntactic. It sits on decades of Erlang experience around concurrency, distribution, and fault tolerance. Its official site emphasizes vertical and horizontal scalability, message-oriented systems, and robust recovery from failures.

In the old model, adopting another language could mean a steep organizational cost: new expertise, tooling, conventions, deployment, and maintenance burden.

Agents do not eliminate those costs.

But they can lower the friction of exploring them.

That means the Ruby community may benefit from becoming more open, not more defensive.

Ruby can be the language in which we express and inspect much of a product while agents help us cross boundaries when another runtime or paradigm is genuinely useful.

That is not defeat.

That is leverage.

A wider opportunity landscape

Ruby at a crossroads with paths toward CRuby and YJIT, JRuby and the JVM, Spinel AOT, Elixir and the BEAM, and polyglot AI agents
The Ruby ecosystem does not need a single answer: agents make multiple runtime and language paths cheaper to explore.

The future of Ruby does not need to collapse into a single bet.

It can expand.

CRuby and YJIT can continue improving the mainstream runtime.

JRuby can make the JVM an increasingly accessible execution target.

Spinel can explore ahead-of-time compilation and native deployment.

Elixir can inspire—or directly participate in—systems where the BEAM’s concurrency model is the stronger fit.

Agents can sit above all of them and make experimentation less expensive.

The strategic shift is from language loyalty as a constraint to language choice as a delegated implementation decision.

And that can actually make Ruby more valuable, because Ruby no longer has to pretend to be the optimal substrate for every problem.

Pencils down does not mean Ruby down

There is understandable euphoria around AI right now, including in DHH’s recent remarks. Some of it will be right. Some of it will be exaggerated. The tools will improve, fail, surprise us, and force us to revise our assumptions repeatedly.

So this is not a prediction that handwritten programming disappears tomorrow.

It is a recognition that the center of gravity is moving.

For decades, we improved programming by creating languages that let humans talk to computers at higher and higher levels of abstraction.

Ruby became one of the clearest expressions of that movement.

AI now moves the boundary again.

Our native language can increasingly become the abstraction through which we describe what we want, while agents translate intent into programs, tests, configurations, migrations, deployments, and perhaps entire environments.

That does not make programming languages irrelevant.

It changes what we need from them.

We may care less about how pleasant they are to type for eight hours a day and more about whether they produce systems that are easy to inspect, explain, modify, and trust.

Which brings us back to Ruby.

Ruby may no longer be the highest abstraction in the stack.

But it can still be one of the best places for humans to meet the code that agents leave behind.

And if an agent needs to generate something I am expected to understand, review, and live with, I still know which language I would rather open first.

Today’s Ruby might become tomorrow’s assembly.
And AI, tomorrow’s Ruby.

But that does not make Ruby less important.

It may finally allow Ruby to become exactly what it always wanted to be:

a language for humans.

Pencils down does not mean Ruby down.

It may mean the field around Ruby just became much larger.

References