What if the most useful software in your life isn’t a product, but something you built for yourself in an evening? That’s the spark for this conversation with Travis Dockter, a Rails developer and organizer of Blast Off Rails, where we dig into how AI turns personal ideas into working tools—fast. From a “house health” app that scores chores to a suite of single-user utilities, we break down what’s changed: ideation is quicker, boilerplate is lighter, and the cost of experimentation has never been lower.

We get real about security for personal apps and why network-level access with Tailscale can be the right fit when you’re the only user. It’s a conversation about risk, not dogma—matching controls to stakes and keeping momentum. We also examine the blurry space around AI-assisted pen testing, the difference between “won’t” and “can’t” in model behavior, and how to navigate that responsibly. Then we push forward: what happens when an agent can manage a Markdown knowledge base or a SQLite file directly? If the UI becomes conversation, design becomes orchestration and feedback, not screens.

Docs turn out to be the sleeper blocker. Travis details a pragmatic Obsidian workflow: agents.md files scoped to code areas, linked session notes, and templates that help models find the right context when it counts. We round it out with hard-won lessons on token efficiency, choosing the right model for planning vs building, and experimenting with multi-model “counselors” to balance cost and quality. Finally, we share why a Rails-focused, single-track conference in Albuquerque can actually boost your day-to-day work: tighter content, lower travel costs, and rooms full of people solving the same problems.

If you’ve been itching to ship something small and useful, this is your nudge. Subscribe for more builder-first conversations, share this episode with a friend who loves Rails, and leave a quick review so others can find the show.

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show

What if you could keep Rails pages fast, accessible, and SEO‑friendly, yet still get modern interactivity without shipping a mountain of JavaScript? We sit down with Cameron Dutro to unpack Live Component, a server‑first approach that breathes life into ViewComponent by treating state as data, rendering on the server, and morphing the DOM with Hotwire. No fragile ID wiring. No React by default. Just clear state, small payloads, and focused updates.

We trace the path that led here: experiments rendering Ruby in the browser with Ruby.wasm, Opal, and even a TypeScript Ruby interpreter, and why those payloads and debugging pain pushed the work back to the server. Cameron explains the Live Component mental model—initializer‑defined state, slots, and a sidecar Stimulus controller—plus how targeted re‑renders make forms and micro‑interactions feel instant. We talk transports (HTTP vs WebSockets), serialization best practices for Active Record data, and where React still shines for high‑intensity builders and editors.

Beyond the code, we dig into the bigger web story: how DX‑first choices often punish users on slower devices and networks, and why a balanced, server‑driven approach can close that gap. You’ll hear real‑world tradeoffs, debugging techniques that feel like home to Rails devs, and a clever fix born from a Snake game that surfaced timing issues and led to a preempt option for queued renders. If your team wants dynamic islands without adopting a full SPA, this conversation offers a practical roadmap.

Explore Live Component at livecomponent.org and the GitHub org at github.com/livecomponent. If this resonated, follow, share with a Rails friend, and leave a review so more builders can find it.

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show

Rails upgrades don’t have to feel like crossing a minefield. We sit down with Ernesto, founder and CTO of FastRuby and Ombu Labs, to unpack a pragmatic path from legacy Rails to Rails 8.1 and how AI can accelerate the work without sacrificing quality. From Ruby 4.0 landing over the holidays to a near-release of RubyCritic 5.0, we dig into the tools, the traps, and the test-suite realities that make or break an upgrade.

Ernesto walks us through a free AI-powered upgrade roadmap that analyzes your repo, dependencies, and code to chart a step-by-step plan—covering everything from Rails 2.3 onward. We compare it to their paid roadmap that adds time and cost estimates for stakeholders who need budgets before they commit. Along the way, we talk strategy: why 5.2 marked a turning point for smoother jumps, where major versions still bite, and how to avoid the “big bang” deployment that topples fragile apps.

AI shows up as a sharp tool, not an autopilot. Ombu is experimenting with agent-driven PRs that draft changes while humans review and refine. We assess hallucinations (better, not gone), verbose code that bloats review cycles, and the mixed evidence on productivity. Then we get practical about safe AI adoption: organization licenses, editor integrations, and enforcing your existing quality gates like RuboCop, Reek, RubyCritic, and coverage checks so “faster” still means “safer.”

We also celebrate community. Philly.rb is back in person at Indy Hall with talks on AI agents and Hotwire Native, and we swap tips on discoverability, speaker sourcing, and venues. Rails remains a strong choice for startups and teams because convention over configuration helps both humans and AI produce sane, testable code. If you care about getting upgrades right and using AI responsibly, this conversation offers clear steps and real-world guardrails.

Enjoy the episode? Subscribe, share it with a teammate wrestling an upgrade, and leave a quick review so more Rubyists can find us. Have a talk idea for Philly.rb? Reach out—we’d love to host you.

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show