San Francisco Ruby Conference 2026

Let's celebrate the new and ambitious companies choosing Ruby and Rails today. We'll hear their stories, learn from their wins, and find out what's missing: what we as the Ruby community need to build to help them grow into the big Ruby success stories of the future. Based on interviews with founders.

Founded a Ruby startup in the last 2-3 years? Let's talk: cal.com/inazarova/feedback

Every scaled Rails app has a stretch of backcountry nobody dares hike into: the part no one fully understands, so you patch it for years, until you can't. Ours had a critical bridge out there. The map showed it, the report said passable; I hiked in and it was all but gone. Our dashboards, our tenured engineers, and our AI were all confidently wrong. This is how we learned to trust only the ground.

Ten years ago I helped build and scale a welfare benefits app to aid more than 1 million people a year. Now, I'm doing it all again from the beginning. I'll compare the original 2016 product roadmap to what's possible in 2026, including feature appetites, team composition and enablement, and very, very different build-vs-buy decisions for an even more monolithic product.

One founder plus thirty agents ships more than a team of ten. Hire a second engineer and everything slows down. Why? You didn't add an engineer, you added a second team. We'll look at the fixes that fail, then at those I believe work well with Rails, and finally at what a founder must give up to get faster.

RubyLLM made Ruby an AI language: one beautiful API for every provider, 11+ million downloads. 2.0 makes it a full framework: the agentic loop as public API, durable approval-gated agents, the most precise cost ledger in AI, caching, batches, fallbacks, citations, cancellation, server tools, speech, video, OCR, reranking, and a generator that writes provider gems. Ruby is where you ship AI.

Most AI features are a chat box bolted onto the product. The good ones are woven through it: an agent you assign a card to, that triages the ticket before you read it, that spots a bad deploy and opens the incident itself. We'll build all three live in one Rails app on Claude Managed Agents (MCP, custom tools, memory, human approvals) and leave you a map of the agent-shaped holes in your product.

At Fin, over 95% of pull requests are Agent-driven and most are approved without human review.

This talk follows changes through our fifteen-year-old, three-million-line Rails monolith, from automated review and selective testing to production monitoring and rollback. Safe speed comes from layers of evidence, bounded authority, and fast recovery, not one perfect reviewer.

Solid Queue 1.0 was released in September 2024 as the default Active Job backend in Rails. 2.0 is ready, but the world is completely different now! Let's explore the path to that new version and the new features, as well as how maintaining an open-source project has changed since Solid Queue was started.

What if your existing Rails views could become reactive without rewriting them?

In this talk, we'll explore how ReActionView brings fine-grained reactivity to HTML+ERB while staying compatible with Action View. We'll look at how existing templates can become reactive, how updates are tracked and rendered, and what this could mean for the future of the Rails view layer.

Ruby applications depend on execution-scoped state, but Threads, Fibers, requests, and jobs can lose it, leak it, or restore it incorrectly. This talk introduces Persona’s Context abstraction for safely inheriting and overriding that state, shows how we built dynamic configuration systems on top of it, and offers patterns you can apply in your own Ruby applications.

An update/extension/reformulation of my talk from Rocky Mountain Ruby www.youtube.com/watch?v=aY_yKeZYzko

The open source software that powers our businesses is maintained primarily by volunteers but funded by too few companies. This talk reframes open source support as not charity, but rather a critical part of the business’ infrastructure. We will be discussing why your company needs a team to manage your open source stack, how to manage this team, and the benefits they could provide.

COSMOS began at Ball Aerospace to scratch an itch: can I make an easy to use and configure command and control system? This talk traces that journey — from an internal tool at a big aerospace company, to open source in an industry where almost nothing is open, to OpenC3, the company we founded to steward COSMOS. Ends with how we built line-by-line Ruby script execution.