Ruby AI News - October 2nd, 2026

Welcome to the 38th edition of Ruby AI News! This edition features… well you know what we’re talking about this edition. This is a special edition, the 39th edition will follow next week.

Read on the web

Here We Go

There are some weeks where it feels like nothing happens. Then there are some weeks where it feels like everything happens.

The Future of Rails

After David’s keynote, I asked around the community for reactions. People I see eye to eye with on the future. Dewayne VanHoozer, one of the Rubyists who was far earlier to Ruby + AI than I was, someone I agree with on the past, present, and future of software, had a different takeaway. He agrees with David’s presentation 100%, and I think David completely missed the mark. It’s important that you have multiple perspectives, so I encourage you to read Dewayne’s beautifully written piece.

Fifteen months ago I briefly met David at the last RailsConf. I asked him for an interview for the Ruby AI Newsletter, and he agreed on one condition: that I only ask one question. I emailed him a question about Ruby’s future with AI. He never responded.

I emailed David again a couple days before the conference. I had a feeling what was coming. I urged him to take a different route, and he obviously did not. But as much as I feel he missed an opportunity here, his lack of vision for the framework he created has undeniably lit a fire under the Ruby community.

How did we get here?

A lot of people unsubscribed from the newsletter after David’s keynote. That was expected. What was surprising is that there were far more new subscribers. So I want to quickly recap what’s happened with AI and where we’re at.

2017: Attention Is All You Need showed a transformer architecture that could train in parallel, which made a corpus of the whole internet possible.

2018: OpenAI’s GPT-1 proved generative pre-training works.

2019: OpenAI’s GPT-2 demonstrated fluency in machine text.

2020: Scaling laws showed that bigger models trained on more text get predictably better.

2021: GitHub announced Copilot, the first mainstream AI coding tool.

2022: OpenAI launched ChatGPT and gained 100 million users in the first two months.

2023: OpenAI introduced function calling, allowing models to return JSON to invoke tools.

2024: Cursor showed the product is the harness around the model, not just the model itself.

2025: Claude Code launched early in the year and Opus 4.5 later, making code generation at scale feasible.

2026: TypeSafe AI released Jev, a probabilistic machine learning model for returning structured decisions.

Large language models use mathematical representations of language (and therefore code) to predict the next part of a sequence. They are trained on known, accessible knowledge. That means there is still a lot of knowledge and expertise outside of the model’s training corpus, and that makes automating knowledge work harder than code generation. Most software engineering knowledge lives online.

Without more knowledge, LLMs struggle to improve, so the labs have turned elsewhere. The improvements we see are a result of post-training, inference scaling, function calling, harness engineering, data quality, and distillation - smaller models trained to imitate larger, more expensive models. Verification loops, a practical application of neuro-symbolic AI, have provided the biggest gains. The idea pairs a probabilistic model with a deterministic system that can verify its work.

Coding just happens to be the biggest beneficiary. Look no further than the frustration with LLM-generated writing. Known knowledge gets you generation, but it is verification that ensures it’s correct.

For coding, the deterministic side already exists in many projects: compilers, linters, test suites. Legal arguments or marketing plans are much harder to verify (I’m excited to see how calibrated decision models like Jev could help fill this gap). Rails has conventions and verifiers, practices that worked for decades and steer an agent in the right direction. PHP, JavaScript, Elixir, .NET, Java, Go, and Rust all have frameworks inspired by Rails. Rails, for the most part, has led the way on best practices.

AI has definitely brought about a transition period. I’ve been telling people AI will require you to move “up the stack”. But I heard a better term recently and I’m not sure who coined it. And that is, you need to move “up the abstraction ladder”. And the tools, techniques, and skill sets you use need to as well. When the language, the framework, and the workflow become an afterthought, you are free to work on the problems that matter, and that was always the role of an engineer.

The Keynote

I was going to do a point by point breakdown of David’s presentation, but after the last week, that just feels like a waste of time. The community responded. I feel he failed to meet the moment, and chose to elevate himself over the community. David didn’t really say anything factually incorrect. It’s what he left unsaid that speaks volumes.

What We Needed From the Keynote

I keep coming back to people. Where do engineers fit when we drill down into computing bedrock and AI generates all the code? Ruby and Rails work so well with AI because decades of decisions, conventions, examples, and best practices have provided strong foundations for the LLMs’ training data. It’s time to build on that foundation instead of abandoning it. As engineers and problem solvers, we have to answer what comes next, as a community.

How can Rails get simpler?

How can Rails get faster?

How can we onboard new agentic engineers?

How can Rails become part of something greater?

I think most of the pieces are already in place. Let’s take a look:

The Community Steps Up

Following David’s presentation, Sam Ruby immediately delivered the keynote the community deserved with Pencils Down, Notation Up. LLMs are a game changer, the moment is real, and David's post-keynote line about the agentic drill bit reaching "computing bedrock" is a real possibility. Sam's question is the one the keynote didn’t address. What sits at the top of the drill? What do we keep, edit, and trust as the single source of truth?

Using Roundhouse, his Rails compiler, and Spinel, Matz's Ruby-to-C compiler, he compiled ONCE’s Campfire, unmodified, into a single C file of 202,000 lines that builds into a Docker image with no Ruby in it. Then he asked which version an agent should edit. The Rails app is about 60,000 tokens and fits in context whole. The C version is about four million tokens, seventy times too large, and the twenty lines that mention the boosts in the Rails app become 1,220 lines of C. Every one of them exists because of the declarations, and the C loses that context.

You or your agent shouldn’t be maintaining the C, it is a compilation target. The “pencils down” answer is that you maintain the prompt and regenerate. A prompt precise enough to produce the same Campfire every time has to pin down every association, validation, callback, and route, once, compactly. A prompt that precise is a program. We already have that program: Rails.

Compiled with Spinel, Campfire serves pages 7 to 8 times faster than Rails as its own Dockerfile deploys it, in 92 percent less memory, with 6 to 14 times lower tail latency. He concluded that “the emitted code running on plain CRuby is already 6–10× faster than Rails. Most of the cost was never Ruby. It was deciding, on every request, what the app's declarations mean: has_many :comments, the routes, the callbacks, the views. Decide that once, at compile time, and most of the cost goes away.” "Let the drill go as deep as it can," he wrote. "Just keep the notation at the top."

Matz Responds

David went on to demonstrate porting Campfire to Rust, "ugly as sin, and 6x as verbose, but the conversion was free” and he never had to look at the Rust directly. Yukihiro Matsumoto replied. "Campfire compiled with Roundhouse + Spinel runs 5.4 times faster in rps, and consumes 1/12 of memory. No modification needed."

Sam put both into perspective. The Rust port’s build before diverging from Rails is about 11 times Rails on the room page against 7.6 for the compiled binary, measured on different machines with different compression settings, and his estimate is that the hand port is 2 to 4 times faster than the compiler's output. He is not claiming Spinel wins, he is claiming it is in the same order of magnitude from source nobody had to rewrite, and that everything after the rewrite is where the cost lives.

That cost is the subject of As If, which takes Aaron Patterson's closing keynote on the compiler's "as-if rule" and applies it to both projects. Neither the port nor the compiler relies on a promise from a model. Both rely on an “oracle”, the running Rails app, and both check their output against it mechanically. The port's Playwright harness passed all 5,018 cells of its parity matrix, pixel for pixel. Roundhouse diffs the DOM of every page and runs Campfire's own test suite against the compiled binary.

After parity was proven, the port diverged from Rails about two dozen times, including behavior changes and bug fixes, and recorded them in a README instead of the Rails app. Every change that stays there is a hole in the oracle, and as Sam puts it, "there is no as-if rule for English." He lays out three ways to ship the next Campfire release. Compile it, port it again, or maintain the Rust. The maintained port is the fastest and the only path where nothing has to go upstream, which is the trap here. An improvement to Rails or to the compiler's runtime helps every app built on it. An improvement to the port helps one.

Rails as a Fourth-Generation Language

Sam’s Partly in the Right presents a parable: “six blind men meet an elephant”. David touched ports, where an existing system holds all the information and checks the result. Jorge Manrubia touched a refactor. Obie Fernandez touched greenfield code with tests and conventions. Obie's friend touched a monolith with no tests, where nothing checked anything.

The accounts contradict each other and Sam believes every one of them, because each answers the same two questions differently. Where did the information come from, and what checked the result? "Port HEY to Rust" is four words that borrow an entire mail server. A new feature has nothing to borrow from, so someone has to supply the distinctions, and the size of what you have to say matters more than anything the model does. Conventions are how you say less. Declarations are how you say what matters.

Sam is taking this thesis to Deccan Queen on Rails next week, and summed it up with a tweet. "We need to build a 4GL. The reasons why 4GLs other than SQL failed no longer apply. We then use our tokens to build a compiler for that 4GL." A fourth-generation language was the 1980s name for a declarative, domain-specific tool like dBase, Informix 4GL, or SQL, where you say what rather than how. They were productive for a database with forms and reports, and every one but SQL died because 4GL vendors had no financial incentive to compile for other platforms while the tech landscape shifted underneath them.

In The Hidden 4GL Sam argues Rails has been one all along, hiding inside a third-generation language. validates :title, presence: true is not a call. It is a statement about what an article is, and the schema, the form, the controller, the route, and the test are all derivable from it by convention. The boundary runs through the middle of every model, and “the moment the conventions run out you write a def, and you are back in a 3GL”.

What changed this year is that a compiler costs an afternoon. What did not is knowing whether it is right. Rails’ homepage says "token-efficient code that's easy for agents to write." Sam says “a 4GL was always the answer to how little must the human say? Agents are asking that question again”.

Immediate Momentum

On September 29th, Tobi Lütke opened a pull request for Roundhouse after running roundhouse check on Shopify core, 96,000 Ruby files across 140 components. Two quadratic costs in constant resolution had pushed a full check toward two hours. His patch took the initial typing pass from 756 seconds to 11.6 and the full check to seven minutes. Sam merged it the same day, and it is the base of a five pull request stack from "getting roundhouse through Shopify core."

Since Rails World, Roundhouse has taken 135 pull requests from eleven contributors, 115 of them merged. Spinel is getting the same treatment. Compiling Nokogiri, Loofah, and Crass turned an HTML sanitizer into a 2 to 3 megabyte binary that runs in 5 to 9 milliseconds, byte identical to the gems across roughly 25,000 lines of their own test output, and identified seven defects in Spinel along the way, six of them fixed upstream the same day.

The pace has not come at the cost of review and careful consideration. When Matz declined a refactoring patch from Abdelkader Boudih last week, he diffed the generated C for the whole test corpus first, named the macro risk he was weighing, and merged five of Abdelkader's other patches the same afternoon.

A Familiar Friend

Former Rubyists felt the keynote lacked vision as well. José Valim, who created Elixir after years in Ruby, asked the question the HEY port skips. "You have the most powerful tool you ever had, you have become a 1000x maker, and you can't think of how to make your stack 10x better?" Why not make Ruby ten times faster, make it great at concurrency, give it a type system with guarantees beyond Rust, embed SQLite with a replication protocol?

In a follow-up tweet José highlighted the contradiction. If agents are as powerful as the keynote says, using them to evolve the language is a no brainer. If they are not, humans still review and architect, and language choice has not fundamentally changed. Believing the first while assuming your stack cannot evolve is the position he cannot reconcile.

Other Avenues

On Thursday night Andi Idogawa launched IronRuby 4, the first stable release of Ruby on .NET since 1.1.3 in 2011. He forked the abandoned project on September 9th, swapped its hand-ported Ruby 1.9 grammar for prism, CRuby's own parser, added a method JIT, got RubyGems and Bundler installing over real TLS, and booted Rails 8.1 on the CLR.

It is a launch rather than a finished runtime. Calls and strings still run two to four times slower than CRuby, and a complete Rails app is blocked on nokogiri. But Spinel took Matz a month, and bringing back a dead runtime took one Rubyist three weeks.

Eileen Alayce said English is "wildly imprecise" and that she expects a new spec language for telling bots what we want, "not because it saves tokens, but because it makes building easier." Freedom Dumlao agreed. So did Sam, with a suggestion. Rails is a good first approximation of that language, and models are already trained on it.

Obie Fernandez is building toward this from the other direction. He predicts teams will distill a codebase into "a rock-solid contract layer," delete the source, and have the latest frontier agents write it again, possibly with Rust instead of Rails if that is what results require.

Obie went on to state that "Configuration is approaching infinity. Clearly it's time to focus on conventions again." I asked him for a quote on what he’s cooking up, and he told me it’s “a convention-driven framework for programmers who plan to remain programmers”. Sam did note that regeneration is “fine for a major version and awkward for a security patch”. But I’m curious to see how this works!

Sam has a notation plan. Matz has a compiler plan. Obie has a convention plan. There is still a lot of work to be done and hurdles to overcome, but this community always seems to come out better off on the other side of a challenge.

David’s Approach

David is taking a different approach. Rust is a "prompt compilation target," in his words, checked by adversarial agents and automated tests rather than a person, and nobody is expected to read it. This has some detractors.

Matija Sosic called the prompt-as-compiler analogy "extremely misleading and even dangerous," because a compiler's biggest benefit is delegation of responsibility, and a prompt gives you none.

Ralph Kuepper, who builds a TypeScript-to-native compiler, had Claude hand-write macOS binaries byte by byte to test the claim that models will skip compilers entirely. It got through Mach-O headers, dynamic linking, and code signing, then produced a valid, signed binary that printed the wrong number, a register assumption nothing in the toolchain could catch. The bug surfaced only because a reference implementation existed. "Source code is the contract," he wrote. "The binary is just one derivation of it."

Mitchell Hashimoto ran an agent loop on a renderer in May and watched it cut frame times from 88 milliseconds to 1.5, an incredible result unless you knew his hand-written version did it in 20 microseconds.

Simon Willison thinks coding agents make software engineering harder, not easier, because unlocking them "requires extraordinary discipline and knowledge."

None of them are arguing against Rust. They are arguing for an oracle, which is exactly what Sam is proposing above.

What about Rust?

There is nothing wrong with Rust, and Ruby can use it to its advantage. Nick Schwaderer announced that Scarpe, the modern rewrite of why the lucky stiff's Shoes, now draws with a native engine, about 20,000 lines of Rust that lays out, paints, and reads the mouse while Ruby runs the app. His four words for it are "Ruby thinks, Rust draws."

It packages a Shoes program into a signed Mac app, ships a FOR_AGENTS.md that walks a coding agent from clone to .dmg without ever putting a window on your screen, and Nick is demoing a new app every day until a Shoes App Store opens next week.

Samuel Williams is copying "all the good parts of the socketry design to Rust," a fiber scheduler style interface that runs on Tokio or its own executor, which is Ruby's concurrency design shaping Rust rather than Ruby fleeing to it.

For the everyday case, Magnus 0.9 lets you write a gem in Rust, with the caveat Jean Boussier left in the thread. It binds against private Ruby APIs, breaks between versions, and he removed every Magnus gem at work to keep its Ruby current.

Sam's compiler went the other direction and found something useful. Adding Rust as a Roundhouse target made the Spinel output faster, and the CRuby output too, because making things monomorphic enables optimization. Rails as written has everything as a hash.

We Can Do Better

Irina Nazarova wrote that tech is expanding because normal people are building apps with agents for their team, their friends, and their family, and "the last thing they need is Rust." They need simplicity, security, and batteries included, and they should pick idiomatic Ruby, Rails, and plain SQLite.

Sam's reply is the logical conclusion this whole week was building toward. It is not either or. Keep your Rails app and transpile it to the deployment target your app needs. Offline first, shared nothing, and other architectures matter more than runtimes.

A person with an idea writes a Rails app, or an agent writes it for them inside the conventions, and the declarations at the top are the specification. The agent writes the defs where the conventions run out, and the test suite decides whether they ship.

A compiler reads the same source and emits whatever the deployment needs. A native binary on a five dollar VPS that answers in a third of a second and holds a thousand WebSocket clients in 222 megabytes. A Durable Object at the edge. A Vercel function in front of a Neon database.

The same three tier app running entirely in the browser with breakpoints and source maps, which Sam’s latest post shows working today, with the test suite transpiled and rerunning on every save. Kotlin and Swift for a native client from the same definition. Stimulus controllers written in Ruby with direct access to the DOM and Active Record. Where measurement says a hot path deserves a hand port, the oracle keeps it honest.

Ruby ten times faster is a reasonable ask of a language whose creator wrote an ahead-of-time compiler in a month. A real type system is a reasonable ask of a compiler that already does whole-program inference on Shopify's monolith in seven minutes.

That is what pencils down looks like when the notation stays at the top. The app is the spec, the agent fills in the remainder, the compiler supplies the performance, and the tests decide. Nobody has to leave Ruby to get there, and the beginner who shows up next year never needs to know Rust exists to ship something that runs like it.

Where Do We Go From Here

Rails itself needs to move up the abstraction ladder. The good news is that nothing is stopping us. Rails can become just one primitive, one piece of the puzzle, of a much greater abstraction and workflow. I see this as a software factory, one that allows you to focus your knowledge and expertise on bigger and better domain problems.

I’m navigating the AI transition along with everyone else, but having the stability and simplicity of Ruby and Rails takes one more variable out of the equation in solving much larger issues. And if you don’t think Rails can be performant enough to solve your particular technical challenges, then I encourage you to explore Rust and other alternatives. My sense of AI optimism tells me there’s no right or wrong answer here. Fixing everything will require approaching solutions from multiple angles.

I’m grateful that the brightest minds in the community are tackling the performance and AI abstraction problems. I’m approaching this from a different direction. How do we make Ruby and Rails as easy as possible for someone just getting started with agentic software engineering. If someone is new to software, and wants to build an application to solve a problem, where do they begin?

Here’s what I think that looks like:

A Starting Line

A beginner on a Mac, a Windows laptop, or a Linux machine should be able to run one command and finish with Ruby, Rails, and a coding agent installed, a new app open in the browser, and a first prompt ready to send. Nothing like that exists today. The official install guide walks through four or five blocks of terminal commands per platform and never mentions an agent, and the Rails and AI page explains why Rails suits agents without telling anyone how to start.

The best agent-first guide, written by Julian Rubisch after he watched a user freeze at a copy-paste step, only covers the Mac. The community needs to pick one path, give it a home, and test it against fresh installs every week so it keeps working.

A New Rails New

Forking Rails would be an incredibly short-sighted decision right now. The framework carries twenty years of technical judgment, corporate backing, and community goodwill, and nothing about the keynote changed that. But the agent layer is not going to come from core.

Rails declined to generate an AGENTS.md for new applications in May, on the grounds that models already know how to write Rails apps, and that is a fair reading of the model and a poor reading of the person sitting in front of it. Hotwire, Kamal, and Thruster all started outside the framework and earned their way in. The agent workflow can take the same route.

We need a CLI that wraps rails new. Today rails new stops at a working skeleton, and everything a beginner needs after that is scattered across a dozen competing starter kits and guides. We need to collectively pick a path and work to establish the necessary AI-native conventions.

The defaults come from the lessons of the last week. Proper bin/setup, bin/dev, and bin/ci, with the CI script deciding whether a change ships. rails query wired up so the agent can read the database without a custom MCP server.

Rails is still the centerpiece, but the CLI becomes the foundation for the factory.

A Modern Rails Frontend

Marco Roth announced that Herb, a toolchain that understands your HTML and your Ruby together, is the default ERB engine in Rails 8.2, bringing the framework’s view tooling into the modern era. ReActionView v0.6 builds on it to deliver "everything a client-side framework gives you, without adopting one." The shape of this is the one Sam described. A compiler decides at compile time what the template means, and the notation at the top is still ERB.

What the notation lacks is a vocabulary. That’s why at the beginning of the year I set out to establish a component DSL and port the entire Shadcn ecosystem to Rails as a sample UI layer. It just didn’t become feasible until the release of Fable 5. Poetry is the missing frontend convention for Rails, it’s built to integrate with coding agents, and it supports frontend AI standards such as WebMCP, AG-UI and A2UI. And it’s built to leverage the Herb ecosystem as each piece of that toolchain leaves experimental mode.

A component is to an interface what has_many is to a model, a declaration that says what rather than how. Herb and ReActionView already compile those declarations into reactive HTML, and Roundhouse is working toward Kotlin and Swift from the same source. A component library that agents can read, install, and verify is the notation for every screen an application has, on the web today and native when the compilers get there.

Rails deserves a beautiful frontend, and for the first time the pieces to build it as a specification rather than a pile of JavaScript exist. Based on the developments of the last week, I’m left envisioning how Poetry can be the interface half of the 4GL Sam says was hiding in Rails all along.

Community Skills

A skill is a folder of instructions an agent loads when it needs them, and the format is now an open standard among Claude Code, Codex, Cursor, and GitHub. While skill files are likely to become less important as LLMs improve, these can bridge a critical gap in the short term and make newcomers more productive on day one. Right now, the most common install path is npx skills add, and RubyGems could be a better home for Ruby specific context files.

The convention is simpler than a directory. A gem that ships a skills/ folder, discovered by Bundler the way its README is, means the knowledge travels with the code that needs it and updates when the gem does. bundle skills to install what your Gemfile already pulled in. RubyGems indexes what ships, so the directory builds itself. The gem is the unit of distribution Ruby has trusted for twenty years. Skills should ship the same way.

Convention Enforcement

Vladimir Dementyev framed this problem well. "One thing is to drop a bunch of MDs and pray that your agent will follow the constraints, but having a static analysis tool to truly enforce them is totally different." Skills and agent files tell the model what you want. Something else has to check what it did, and Ruby has most of the tools.

RuboCop for coding style. Brakeman for security. Herb's linter for HTML, now with 166 rules. Carmine Paolino's ArchSpec holds the architecture line, reading your source with Prism in seconds, models.cannot_use :controllers, nine bundled architectures, and a written reason required for every suppression.

The newest line is compilability. Roundhouse defines the apps it can compile as the ones that produce no diagnostics, and its ledger of what it cannot compile reads like a list of what agents should not write anyway, method_missing, define_method, answers that exist only at runtime. Put roundhouse check in bin/ci beside the others and a new app stays inside the compilable subset from its first commit.

Conventions were always load bearing. Now they have to be executable, because the test suite decides what ships, and the agent is the one reading the results.

Embedded Knowledge Bases

Sam's question for every agent result was where the information came from. In most Rails apps the answer is the model's training data plus whatever is included in AGENTS.md. The tools to do better exist, Tobi Lütke's QMD for searching Markdown knowledge, Basic Memory and mnemos for serving a project's decisions over MCP, GitMCP and Context7 for upstream source and docs, but every one of them lives beside your app, not inside it, and none of them knows about the other.

I see a solution in the form of a Rails engine. Mount it and the app carries its own knowledge base, decisions, design notes, and the reasoning behind them, versioned in git and indexed at boot, and it connects to whatever coding agent you use. The social part is the standard. A gem that mounts the same engine ships its knowledge with its code, so when your agent works with Turbo or ViewComponent, it reads what those maintainers know, at the version you have installed, instead of guessing from training data.

Your teammates' knowledge bases connect the same way, with permissions down to the note, so the senior engineer's reasoning about the payments module is available to the agent sitting with the junior. One protocol, every gem a node, and the information an agent needs travels with the code that needs it. Chad Fowler lists what outlasts code as behavior, boundaries, evaluations, evidence, and provenance. This is where a Rails app should keep them.

Agentic Deployments

A beginner's first real win is a result they can see live. Lovable and Bolt hand one over in the time it takes to type a sentence, and that is a big part of why most newcomers start there. Rails asks for a server, a domain, Docker, and a Kamal config first, which is a solid answer for a team and the wrong one for someone on day one. The last step of the starting line should be a running app on the internet, in minutes, with the agent doing the deploying.

Agentic means two things here. The agent runs the deploy, watches the logs, and rolls back when the health check fails, so the platform has to speak to agents in structured output rather than dashboards, the way bin/kamal query already does for production data.

Roundhouse's tagline is "the deployment target is a build flag," and Sam has the same app running as a Puma process, a Spinel binary, and a serverless function with no rewrite. Deploy to the simplest thing that works, and let the compiler move you when the numbers provide the proof.

Install → Prompt → Compile → Deploy

A beginner runs one command and gets a Rails app and an agent. The agent writes inside the conventions and the test suite decides what ships. A compiler takes the same source to whatever the deployment needs, and a platform the agent can talk to puts it on the internet. Every piece of that exists today in some form, built by the people in this edition, and none of it required leaving Ruby. David gave us the framework. The rest is on us now. It’s not year 22 of Rails anymore, it’s day one.

That’s all for this edition! Be sure to reach out if you have any stories, content, jobs, or events you want featured in the newsletter.