2026-06-16站内改写6 min readUpdated: 2026-06-16

Ruby AI News - June 16th, 2026

Welcome to the 32nd edition of Ruby AI News! This edition features a fabled introduction to US government intervention, a concrete playbook for making Ruby and Rails impossible for AI coding agents to overlook, the road to RubyLLM 2.0, and much more.

SourceHacker News AIAuthor: activefx

RoboRuby

Posts

Matt Solt June 16, 2026

I'm pleased to announce that SerpApi is now sponsoring the Ruby AI Newsletter. SerpApi is the world's leading provider of search data, pioneering APIs that turn search engine results into structured, developer-ready information. Founded in 2017, it enables developers, researchers, and Fortune 500 companies worldwide to integrate live search insights from sources like Google, Bing, and YouTube into their applications, analytics, and research workflows.

What makes this the right partnership is that SerpApi isn't backing Ruby AI from the outside, they are part of the community. SerpApi runs on a Rails monolith, joined the Rails Foundation as a contributing member, maintains a suite of open-source Ruby gems, and employs a dedicated Ruby Developer Advocate. And they are hiring Rails engineers! Their backing will directly fund expanded content and resources from the Ruby AI Newsletter. My sincerest thanks to the SerpApi team for their support!

Read on the web

Contents

Top Stories

Fables are Cautionary Tales

On June 9th, Anthropic released Claude Fable 5, the first publicly available "Mythos-class" model, alongside a restricted Mythos 5 reserved for vetted security partners under Project Glasswing, the same program we covered in the April 16th edition. Fittingly for this newsletter, the headline enterprise proof was a Ruby story: Anthropic reported that in a 50-million-line Ruby codebase, Fable 5 "performed a codebase-wide migration in a day that would otherwise have taken a whole team over two months by hand," with Stripe saying the model "compressed months of engineering into days." At $10 per million input tokens and $50 per million output tokens, roughly double Opus 4.8, Fable was positioned not as a chatbot but as an autonomous engineer for long-horizon, agentic work.

The initial reactions lit up the Ruby AI community. Simon Willison called it "something of a beast," slow and expensive but able to single-handedly build real tools, burning through $110 in one day of testing. RubyLLM creator Carmine Paolino said it was "another generational leap" whose best feature was that "it writes less code," and Obie Fernandez reported kicking off "four Fable 5 goal loops" on his agent-orchestration platform before his coffee got cold. The praise came with caveats. David Paluy, naming it the best coding model he'd ever used, still wasn't "that excited," arguing the contest has moved from "which model wins the benchmark" to "which model wins in the harness," and flagging Fable's expense, slowness, and trigger-happy guardrails on anything touching security. Brandon Casci's two-app UI migration drove that point home. Fable's agents caught ten issues on their own, but human review still caught five they missed, and using the model as visual "eyes" was the costly part of a 56-million-token run.

Avi Flombaum half-jokingly relayed that Kieran Klaassen had extrapolated a single week of heavy Fable usage to roughly $1.5 million a year at API pricing. And shadcn argued for treating "intelligence as borrowed" by draining a frontier model while it's available to build a backlog of plans now, and to "implement later with a cheaper, open source, or a model you control." In just a matter of days, that framing looked less like productivity advice and more like prophecy.

On June 12th, three days after launch, the US government issued an export-control directive citing national security, barring access to Fable 5 and Mythos 5 by any foreign national inside or outside the country, including Anthropic's own foreign-national employees. Unable to verify every user's nationality in real time, Anthropic had only one way to comply, and that was to turn the models off completely. The trigger, per Anthropic, was a demonstrated jailbreak that could surface "a small number of previously known, minor vulnerabilities," flaws the company said other models could find without any bypass. Anthropic disputed the decision, warning that applying such a standard "across the industry" would "essentially halt all new model deployments." The commentary that followed focused less on the flaw than the precedent. David Ospina observed that "physical borders now live in the cloud" and single-vendor lock-in had become "a massive operational risk," while Habib Baluwala, in a widely shared essay, named the pattern the "Recall Reflex" and concluded that "recall risk just became a national-security-grade reason to stay model-agnostic."

Which is exactly where this leaves Ruby. In the April 16th edition, "Can We Trust the Labs? Why Ruby May Need to Go Local," I argued that developers who depend solely on API calls to frontier models are "building on someone else's terms." The labs (and now, to some degree, governments) decide who qualifies, what's approved, and what it costs. Fable 5 turned that abstraction into operational reality in three days. Stripe's migration, Carmine's praise, Obie's loops, and a chunk of the community's best week of agentic Ruby work were all riding on a model that vanished not because of a price hike or a deprecation, but because of a government mandate. The AISLE research previously cited put it best: "the moat is the system, not the model." As RubyLLM's provider-agnostic design and growing local model support already show, the practical hedge isn't loyalty to any one lab but optionality. Focus on model-agnostic pipelines, local fallbacks, and the ability to keep shipping when the best tool in the room gets switched off. If the moat is the system and not the model, then Ruby's edge in this era is to make the agentic system the durable product.

We Must Do Better

Ruby & Rails LLM Discoverability Scorecard

A measured scorecard of how discoverable Ruby, Rails, and the wider ecosystem's documentation is to LLMs and AI coding agents, and what the community can do to move the needle.

ruby.evilmartians.com

At Blastoff Rails, Evil Martians CEO Irina Nazarova delivered an updated Startup on Rails 2026 keynote with a pointed thesis. Rails is the best stack for agentic software development, and almost no one building with AI knows it. Polling Ruby founders, she surfaced five gaps the ecosystem still needs to close. Lack of first-class asynchronous support in Rails, documentation that lags code and is not optimized for agents, a hiring disconnect between companies and candidates, a shortage of component libraries, and improved frontend tooling and interactivity. Some of these improvements are coming. The Falcon web server, fiber-aware Active Record with query pipelining, and a re-architected Action Cable should improve async capabilities, while Marco Roth is rebuilding frontend tooling with Herb and ReActionView. But others, like agent skills for Ruby frontend development, llms.txt for gem documentation, and Rails frontend component libraries are still lacking.

Going on to cite Chad Fowler's whichlang benchmark, where AI agents are handed real coding tasks and, crucially, never told which language to use, Irina revealed that across 210 product builds, agents chose Ruby zero times. This is not a capability gap. Ruby core committer Yusuke Endoh had Claude Code build the same project in 13 languages and found Ruby the cheapest in tokens to read and write, and async Ruby tops the runtime benchmarks. Models are simply trained on a web where Ruby stayed quiet. "A model reaches for what the corpus argues for," she said. The problem is discoverability, not capability.

The presentation concluded with the introduction of the Ruby & Rails LLM Discoverability Scorecard, which grades 92 Ruby sites on seven machine-readable signals and lays out a four-layer plan. One, get into the training corpus by unblocking AI crawlers in robots.txt and the web application firewall, as well as shipping sitemaps and server rendered content. Two, win LLM retrieval by serving clean markdown and an easily navigable llms.txt index file so agents can fetch documentation. Three, make agents fluent in gems and Ruby libraries by shipping a built-in MCP server or agent skill. And four, change the LLM model training defaults by getting idiomatic Rails into evaluation datasets like Multi-SWE-bench, since adding a language to an eval measurably improves models benchmarked on it.

The Ruby community must do better to surface all of the incredible work and accomplishments of the last 30 years for the new realities of the AI era, myself included. The newsletter has no sitemap, no llms.txt, no structured archive, and poor discoverability, and I will work to change that. Software was always meant for two audiences, humans and machines, and LLMs are just formalizing that duality. My hope is that by the time Evil Martians’ second San Francisco Ruby Conference rolls around in November that we’ve fixed these issues and we’ll see a new set of recommendations. For thirty years Ruby has produced software friendly to both humans and machines, which is exactly why it feels like we’re the right community for this moment. Nick Schwaderer captured the sentiment in a recent tweet:

— (@)

The Road to RubyLLM 2.0

Carmine Paolino shipped RubyLLM 1.16 and framed it as the release where the gem grows up. "A new LLM library answers the question 'does it work?'" he wrote. "In production the questions change: is it fast, can I see what it's doing, can I route it through my own infra?" RubyLLM 1.16 answers all three. Tool calls now run concurrently, via threads or the async gem's fibers, and stream back in completion order, on the logic that "when a model returns several tool calls in one response, it's telling you those calls are independent." Rails-style instrumentation emits structured events through ActiveSupport::Notifications, or a custom instrumenter for OpenTelemetry, with no monkey-patching. And a configurable base URL for every provider, along with a swappable Faraday adapter, lets teams route requests through their own infrastructure. Running it in production at Chat with Work, Carmine said the speed bump was "really noticeable."

RubyLLM has crossed 8 million downloads and 4,000 GitHub stars, climbing by nearly a million downloads in a month, with Carmine noting that "beautiful code still matters." Version 1.16 also lays the groundwork for what comes next, adding deprecation controls (config.deprecation_behavior = :warn, :silence, or :raise), so teams can flush out deprecated paths before the next major version. As he announced days later, "the work towards RubyLLM 2.0 has begun." This includes a Citations API, multi-protocol providers (OpenAI's Chat Completions and Responses API, plus Vertex AI), and a Batching API, with more on the way.

Carmine's also shipped Jekyll VitePress 1.5.0, improving his documentation theme under the banner "Ruby deserves beautiful documentation," an important contribution when documentation quality decides whether models can even find Ruby. And he’s building archspec, an architecture-linting tool that checks a Rails app's components, layers, and protocols against rules a team declares, runs them in CI, and aims to "give people and code-generating tools the same rules," including a dedicated mode to check AI-written code.

A fixture since the first edition, Carmine continues to lead the way, assembling the pieces of a production Ruby AI stack: the LLM library that d

[truncated for AI cost control]