I’ve been considering David’s opening Rails World keynote and realised that this is the main problem I have with it. Rails World is about “shaping the future of Ruby on Rails”. Instead what we got was opinionmaxxing: a lot of certainty about the destination, but in his own words, not much that was ‘practical’ or ‘prescriptive’ about getting there.
There’s a vibration of uncertainty in our community and the wider industry, even from folks, like me, who were early to playing with and then using the new LLM-powered coding tools and harnesses for real production work.
I was left with a “what’s the point?” feeling. I don’t believe this was the intention. I think David meant it as a provocation, to jolt the room. But the room was already there: when he polled the audience only five people out of 1,200 were still writing material amounts of code by hand. He seemed surprised at the scale of that. He shouldn’t have been, the Rails community are tinkerers, early adopters and pragmatists.
To be clear I think he’s directionally right on software. The way we make software has changed forever. Yesterday I shipped (and reviewed) 21 bug fix PRs to CoverageBook, upgraded a Rails app from 7.x and Tailwind 2 to latest versions and shipped a couple of feature PRs. I’m engaging more judgement on how much I code review when I can verify in other ways. I’ve never been so able to deliver well-made software, so fast.
I do believe however there’s a lot of interesting work to do in step 2. Software engineering has always been more than typing code. I’m not seeing evidence I can abdicate my taste to Anthropic, OpenAI or the fast-following open-weight models.
There were multiple version numbers mentioned in the keynote: all LLMs, not a single mention of Rails 8.2.
David’s attention is elsewhere. Ruby was “about 3%” of his work this year, and he’s “talked about nothing else but Omarchy for about 3 months.” Now the models can one-shot a calculator and convert existing applications to Rust. He seems uninterested in the useful guardrails, determinism and token efficiency1 that a battle-tested framework can provide when using agents.
He did concede, on the panel the next day, that he’d still spin up Rails apps for new web software. And in the keynote he admitted the designers’ vibe-coded work on Basecamp 5 left the architecture “a little like Swiss cheese”, and they went back to manual review.
Problem is, the rest of us need to work now, and the next model might not be perfect. The Rails Foundation’s own Agents on Rails benchmark says it isn’t there yet: the best result on real feature tickets is 53.3%2, and most models score 15–35%. The timeline is unclear. Of course, if the next model removes the need for anything but machine code, this is all moot. But we’re in the aftermath of one tipping point, not past a second, greater one.
Rails’s opinions used to be all about step 2. The keynote put all the certainty on the destination and handed the path to the next model release. That’s the only plan for step 2: “give it freaking 5 minutes.” Robby Russell reflected in his keynote that folks need “somebody willing to say, ‘We’ve learned enough from these experiments. We’re doing it this way now.’”
Jeremy Daer, moderating the fireside chat between Matz & David asked whether words like “slop” and “meat proxies” were diagnoses or coping mechanisms. David said “90% cope” and that “even the slop grenade is not long for this world.” Jeremy pushed back:
“Slop plus the delivery… when it’s being dumped on them”.
That made me reconsider the other elements of that metaphor that make it really sing: the inaccurate trajectory, lobbed and not watched, the implication of a timer and the difference in experience of the thrower and the receiver.
David said “I don’t mind slop grenades at all… I don’t have to catch”. That’s true for him, both in open source (you can refuse a drive-by PR) and at work (he’s in charge).
That’s not what slop grenades end up being for the rest of us though. Most of us can’t ignore PRs from our co-workers or a 3am page from the explosion of a slop-enabled production incident. It’s a thrower’s perspective. We have to catch.
If the models emulate human intelligence with machine determination why wouldn’t having higher level, verifiable, abstractions be useful? That’s why you can spin up a calculator or a Rust duplicate of an existing Rails app. The irresistible force of the agent has something to check its homework on: a bunch of industry standards, a test suite, an existing implementation. Aaron Patterson made this case from a lower level:
“I’ve heard the argument that AI is just our next compiler… [you don’t read its output] because the compiler made a promise to you… your AI has not made this promise. There is no as-if rule for your English.”
Step 2’s hard part is that the model can’t write your spec. The published failure mode in the foundation’s own AI research is hand-rolling. Matz said it: “we know how to define the goal for the agents… we have to formalize them and teach to the following generations.”
Clarity of aim turns a careless lob into a directed pass. I ported readability from JS to Ruby overnight - its test suite was the guard.3
How is David’s Rust-based HEY backend tested? How far along is it? If it’s checked against anything, the best spec is the Rails app it replaces. The six native apps are impressive and I absolutely agree I’d go for a performant API & native app combination when powered by LLMs. But they are all also based on well-established, native, well-maintained, well-documented, platform frameworks like SwiftUI, WinUI, Jetpack Compose, Qt.
The web has one of those too. As Kinsey Durham Grace put it: “If you designed a framework from scratch for agents, you’d land close to Rails.”
Without aim, a grenade just blows holes in whatever it lands on. Not sure waiting 5 minutes for the models is a good solution to having to solve problems now.
Hot Cell was the only feature that made the keynote4 but Mike Dalessio’s talk was absolutely about how AI is affecting open source (and specifically a Rails CVE) and a framework-shaped answer to holy shit the robots are coming to hack your systems.
Joël Quenneville & Rachael Wright-Munn talked about fixing the system and bolting deterministic hooks, or context-injecting generators, onto your agentic tools. Before Rachael’s custom generators carried RubyEvents’ conventions, the AI “would invent keys”. Merging Marco Roth’s Herb into Rails gives us a parsing tool for the view layer that can escalate errors into an agent’s context.
Kinsey also brought numbers from her time on GitHub’s Copilot coding agent team: 84% of developers use AI to write code, but only 29% trust it. “Generation is really, really cheap, and verification is not”, so reviewing harder won’t fix it. Her answer: “Constraints beat instruction”. A rule in AGENTS.md fades as the context fills; a CI check that fails the build applies every time and costs no tokens. It’s also why Rachael’s generators work. With a generator, “you’re making the command that puts [service objects] there cheaper than writing the file by hand. It’ll take the cheap path because agents always do.”
Robby argued for improving the “workshop” of our apps, making the preferred way obvious for humans and agents. Applying our curiosity to the problems we see in our day to day and leaving things better than we found them.
Jeremy asked what’s past Rails: “I want to keep Rails… what about the values of Rails?” The answer was “find your tribe… stick around.” That’s not a plan for Rails. David’s own tribe, and his energy, is clearly Omarchy, his agent-focussed Linux distribution.
People move on. That’s fine. There’s an entire army of people wanting to do, and already doing, the work before the models (maybe) do all software engineering and the framework doesn’t matter.
8.1.4, a bugfix release, came out on day 2 of the conference. There’s a bunch of cool stuff in 8.2. There’s no doubt an editing job to do to make Rails useful through the AI-chaos era that Mike identified in his talk.
There’s an alt-history version of this talk that pivots on the delight of David’s 21-year-old demo “look at all the things I’m not doing” into a vision for how Rails helps the models and the humans compress and accelerate. Then it was the framework, now it’s the framework and the model. David credited only the model.
Kinsey closed with the version I wanted from the keynote: “Convention over configuration was never really about productivity. It was about care. A predictable and clear place to put things is a message to whoever shows up next… We called it a framework, because somebody always comes next.”
No doubt Rails needs to change—some things in, some things out—but it felt to me like a resignation from this version of his world view. If David’s focus has moved on, that’s his call. There was enough can-do, roll-your-sleeves-up attitude in the rest of the conference to take on the uncertain future.
Mike opened with a timeline: prehistory to modern computing, then “you are here” in a band marked “CHAOS!”, and a giant question mark. That question mark is step 2. It won’t look like the old work. But it’s our work, and you don’t need permission to do it.
He praised it in the keynote and called it ‘a short-term consideration’ the next day. ↩︎
Stage 2 gives models 20 feature tickets, written the way a product person would, against 37signals’ Fizzy app, graded by hidden checks. At default settings the best score was 35%. The 53.3% is the same model, GPT-6 Astra, at maximum effort: 2.6 times the cost and almost three times the time. Claude Fable 5.1 spent twice as much at max for the same 32%. ↩︎
Simon Willison ported a standards-compliant HTML parser (JustHTML) from Python to JS in four and a half hours. ↩︎
class_names helper does this cleanly.
…interpolating conditional classes with ternaries or post-statement conditionals:
<div class="p-4 rounded <%= @error ? 'bg-red-50 border-red-500' : '' %> <%= 'opacity-50 cursor-not-allowed' if @disabled %>">
<%= @message %>
</div>
…the class_names helper:
<%= tag.div class: class_names(
"p-4 rounded",
"bg-red-50 border-red-500": @error,
"opacity-50 cursor-not-allowed": @disabled
) do %>
<%= @message %>
<% end %>
String arguments are always applied; trailing keyword-style entries are included when their value is truthy and silently dropped otherwise.
Better still — Rails tag helpers (tag.*, link_to, form builders) already run the class: argument through the process implicitly, so you can drop the wrapper and hand it an array directly. The trailing key: value pairs don’t need their own {} either; Ruby wraps them into a Hash for you:
<%= tag.div class: [
"p-4 rounded",
"bg-red-50 border-red-500": @error,
"opacity-50 cursor-not-allowed": @disabled
] do %>
<%= @message %>
<% end %>
An active nav link:
<%= link_to "Home", root_path,
class: ["nav-link px-3 py-2",
"text-blue-700 font-semibold": current_page?(root_path)] %>
A form field with errors:
<%= f.text_field :email,
class: ["field", "field--error": @user.errors[:email].any?] %>
A flash message:
<% flash.each do |type, message| %>
<%= tag.p message, class: ["flash",
notice: type == "notice",
alert: type == "alert"] %>
<% end %>
An active tab:
<%= link_to "Overview", project_path(@project),
class: ["tab", "tab--active": current_page?(project_path(@project))] %>
Or wrap a repeated pattern in a helper. Helpers often return Strings, which would be a case where you call class_names directly:
def class_names_for_project(project)
class_names("status-badge",
"status-badge--primary": project.active?,
"status-badge--muted": project.archived?)
end
<%= tag.span @project.status, class: class_names_for_project(@project) %>
The unsophisticated approach ends up with extra whitespace in the rendered HTML with ERB tags inside an HTML attribute (which I’m not a fan of visually), plus it’s hard to scan which classes are always present and which are conditional.
The tag helpers call token_list on whatever you pass to class:, which is aliased as class_names. It splits whitespace-separated tokens, deduplicates them, and returns an HTML-safe string. So ["p-4", "p-4 rounded"] collapses to "p-4 rounded" rather than repeating p-4.
You have to call class_names directly when you’re not inside a tag helper — building a string in a helper method, or interpolating into raw HTML. It’s available in all views and helpers in Rails since it’s defined in ActionView::Helpers::TagHelper. You might also see it referred to as token_list, which is the original method name.
If you’ve only got a single conditional class, plain ERB is readable enough:
<div class="p-4 <%= 'font-bold' if @important %>">
Though the array form does avoid the awkward whitespace issue when the condition is false:
<%= tag.div class: ["p-4", "font-bold": @important] do %>
html_safe on the result. This bypasses Rails’s built-in XSS protection entirely: any user input in that string goes straight to the browser unescaped.
The good news is you almost never need html_safe. Rails provides three underappreciated tools that handle escaping for you.
…calling html_safe on strings you’ve built by hand:
def status_badge(label, color)
"<span class=\"badge badge-#{color}\">#{label}</span>".html_safe
end
def formatted_address(user)
[user.street, user.city, user.postcode].compact.join("<br>").html_safe
end
def render_comment(comment)
comment.body_html.html_safe
end
…the right tool for each situation.
When you need to build HTML elements, use tag helpers:
def status_badge(label, color)
tag.span(label, class: "badge badge-#{color}")
end
The tag helper escapes the content and attributes automatically. It returns an HTML-safe string without you having to think about it.
When you need to join fragments that mix safe HTML with potentially unsafe text, use safe_join:
def formatted_address(user)
safe_join([user.street, user.city, user.postcode].compact, tag.br)
end
safe_join escapes any unsafe strings in the array and returns an HTML-safe result. It’s Array#join with protection built in.
When you need to accept user-provided HTML but strip dangerous tags, use sanitize:
def render_comment(comment)
sanitize(comment.body_html)
end
sanitize keeps safe tags like <p>, <strong>, and <em> while stripping <script>, event handlers, and other XSS vectors. You can customise the allowed tags and attributes, but beware of straying past the defaults — they are battle-tested and loosening them is a footgun.
Each of these tools lets Rails manage HTML safety for you. You describe what you want — an element, a joined list, sanitised content — and the framework handles the escaping.
html_safe does the opposite. It tells Rails “trust this string, don’t escape it”. That’s a promise you have to keep, and it’s easy to break when the inputs change or a future developer doesn’t realise user data flows through that path. Ask your friendly security consultant or penetration testing organisation why this is a bad idea.
The mental model is simple. Need an HTML element? tag. Joining fragments? safe_join. Accepting rich text? sanitize. If none of those fit, you probably need a partial or a component, not a string.
There are legitimate uses of html_safe. Some gems, like pagy, return pre-built HTML strings that are safe by construction. Calling html_safe on their output is fine because the gem controls the content.
You might also see html_safe on strings that are genuinely static with no user input, like " ".html_safe. That’s harmless, but you can include the actual Unicode character instead — "\u00A0" gives you a non-breaking space without needing html_safe at all. That is ugly as hell though, so it’s your call!
The key question is always: could user input end up in this string? If the answer is yes, or even maybe, reach for tag, safe_join, or sanitize instead.
ENV.fetch calls and credentials.dig lookups throughout the codebase, depending on where each secret lives.
Rails edge — and the upcoming 8.2 — fixes this.
…mixing ENV and credential lookups:
class StripeChargeService
def initialize
@api_key = ENV.fetch("STRIPE_API_KEY")
@webhook_secret = Rails.application.credentials.dig(:stripe, :webhook_secret)
@price_id = ENV.fetch("STRIPE_PRICE_ID") { Rails.application.credentials.dig(:stripe, :price_id) }
end
end
…the combined credentials API:
class StripeChargeService
def initialize
@api_key = Rails.app.creds.require(:stripe, :api_key)
@webhook_secret = Rails.app.creds.require(:stripe, :webhook_secret)
@price_id = Rails.app.creds.require(:stripe, :price_id)
end
end
require raises a KeyError if the key is missing from all backends. For optional values, use option:
Rails.app.creds.option(:appsignal, :push_api_key, default: nil)
# Returns nil if missing — AppSignal just won't report
To keep production secrets separate, run bin/rails credentials:edit --environment production. This creates a separate encrypted file with its own key:
config/credentials.yml.enc ← shared (dev/test)
config/master.key ← decrypts the shared file
config/credentials/production.yml.enc ← production only
config/credentials/production.key ← decrypts production
If production.yml.enc exists, Rails uses it exclusively in production — there’s no inheritance from the shared file, so duplicate any keys you need. To decrypt in production, set RAILS_MASTER_KEY in your hosting provider to the contents of production.key.
Rails.app.creds checks ENV first, then falls back to encrypted credentials. You don’t need to know or care where a value is stored.
Nested keys like :stripe, :api_key map to double-underscored ENV names (STRIPE__API_KEY). A single key like :postmark_api_token checks ENV["POSTMARK_API_TOKEN"].
This means you can move secrets between ENV and encrypted credentials without changing application code. Deploying to a provider that injects secrets via ENV? It just works. Want to move a key into the encrypted file instead? Remove the ENV variable and add it to your credentials. Your code stays the same.
I’ve previously recommended wrapping ENV in a custom Settings object. This built-in approach is better — the same clean interface with the added fallback to encrypted credentials.
This isn’t in a released version of Rails yet — you need Rails edge (main), and it’s expected in Rails 8.2. If you’re on 8.1 or older, a custom Settings wrapper still works well.
You can also create development.yml.enc and test.yml.enc, but I think the shared file plus a production override is clearer — and you shouldn’t be calling real APIs in your test environment anyhow.
Keep separate encryption keys for each environment. You could share one, but a leaked development key shouldn’t expose production secrets.
I originally published this post saying Rails.app.creds had shipped in Rails 8.1. It hasn’t — it’s on Rails main and is expected in 8.2. I’ve been running Rails edge on a couple of projects and assumed this had already been released. Apologies for the confusion, and thanks to everyone who pointed it out.
…accepting Rails’s best guess at a plural:
"criterion".pluralize #=> "criterions"
"matrix".pluralize #=> "matrices" # this one Rails knows!
…inflect.irregular to teach Rails the correct pair:
# config/initializers/inflections.rb
ActiveSupport::Inflector.inflections(:en) do |inflect|
inflect.irregular "criterion", "criteria"
end
Now:
"criterion".pluralize #=> "criteria"
"criteria".singularize #=> "criterion"
Give irregular the singular and plural forms and Rails handles both directions—pluralize and singularize both work correctly.
A Criterion model will look for a criteria table. resources :criteria will route to CriteriaController. Association names, fixtures, and factory names all follow suit.
class Criterion < ApplicationRecord
# table: criteria
end
class Survey < ApplicationRecord
has_many :criteria # works as expected
end
You can declare as many as you need:
ActiveSupport::Inflector.inflections(:en) do |inflect|
inflect.irregular "criterion", "criteria"
inflect.irregular "goose", "geese"
end
Although, unless you’re building some kind of flighted animal tracker, you probably won’t need that second one.
Rails already knows a handful of irregular plurals: person/people, man/men, child/children, sex/sexes, move/moves, and—crucially—zombie/zombies are built in. Rails’s pluralisation rules are regex-based, so the (m)an → (m)en pattern also covers woman/women. But that’s it—words like tooth/teeth, foot/feet, mouse/mice, and goose/geese are not handled by default. Check the default inflections to see what’s already covered.
See the ActiveSupport::Inflector::Inflections documentation for details.
Before adding an irregular inflection, check whether Rails already knows the word. Try it in a console:
"person".pluralize #=> "people" — already works
"axis".pluralize #=> "axes" — already works
If it’s already correct, adding it to your initialiser is just noise.
If the word never appears as a model or resource name, there’s no reason to declare it.
For words that don’t change between singular and plural (like “sheep” or “metadata”), you need inflect.uncountable. For casing issues with acronyms like API or CSV, look at inflect.acronym.