Code and the Coding Coders who Code it

That RailsWorld keynote didn’t just start a debate, it forced a reset on how we talk about Ruby on Rails in the age of AI. We’re live from the Buzzsprout podcast booth with Joël Quenneville (principal developer at thoughtbot and Bike Shed co-host) and Tom Rossi (Buzzsprout co-founder) to unpack what’s changing when many of us barely write code by hand anymore and instead “coach” an LLM agent.We dig into the practical side of AI-driven development: why Rails conventions still matter, why generators suddenly feel new again, and how token efficiency and consistency become real engineering constraints. Then we get honest about software design. Do classic abstractions and object-oriented patterns help agents reason, or do they just get in the way when explicit code ships faster? We trade stories about broken integrations, duplicated methods that still pass tests, and why naming and domain language remain a steering mechanism for both humans and models.From there, we zoom out to the future of software products. If personal AI assistants become the primary interface, the “UI” might shift toward CLIs, MCP-style structured endpoints, and agent-friendly actions instead of screens and forms. That opens big questions about APIs reopening, who controls the agent layer, and whether we’re about to repeat the same platform power cycles we saw in the API boom years.If you’re building on Rails, experimenting with LLM coding tools, or wondering what your job looks like when the craft shifts from typing to verification, this conversation will help you think clearer. Subscribe, share this with a friend from your dev team, and leave a review with your hottest take on where AI is pushing Rails next.Send us some love. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

Your database is slow, your Sentry is screaming, and the backlog is full of “we’ll fix it later.” What if an AI agent handled the boring but high-impact work while you slept and just opened a clean pull request for review the next morning?We’re joined by Mike Coutermarsh, a software engineer who helped build GitHub Actions and later left GitHub for PlanetScale. We talk candidly about the trade-offs: walking away from big-company comfort, choosing impact over feeling like a cog, and learning to thrive in a flatter org where the best “process” is ownership. Mike shares how he leads the team responsible for everything users see at PlanetScale, from dashboards to APIs to CLIs, and why speeding up CI, reducing bugs, and protecting reliability can matter more than chasing the flashiest feature.Then we get practical about AI coding tools. Mike breaks down how Cursor, Claude Code, and MCP servers can connect production query patterns and Sentry errors to scoped “bot army” automations that propose fixes, optimize performance, and even keep error queues from becoming a garbage fire. We also dig into AI code review, responsibility (“if your name is on the commit, you own it”), and the uncomfortable question of whether code quality still matters when models can generate code fast. Along the way we touch token costs, local models, and why conventions like Rails can actually help AI work better.On the database side, Mike explains why PlanetScale started with MySQL via Vitess, how sharding changes operations like backups and restores, why Postgres demand forced a new product push, and what it could mean to bring Vitess-style scaling to Postgres. We wrap with a small but surprisingly powerful workflow upgrade: fast dictation using Spokenly and local speech-to-text.Subscribe, share this with a teammate who lives in dashboards and PRs, and leave a review with the one workflow you’d want an AI agent to automate next.Send us some love. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

React made a lot of us feel powerful, then maintenance made a lot of us feel tired. Drew Bragg sits down with Delaney Gillilan, creator of Datastar, to argue for a different kind of “modern web” one that keeps the browser’s strengths front and center and keeps your app logic where it belongs: on the server. If you’ve ever looked at your dependency graph and wondered how you got here, this conversation is a reset.We get concrete about what Datastar is and how it works: a tiny reactive framework built around HTML, data attributes, and signals, with a plugin system that stays out of the way. Delaney explains why most state should live on the backend, why duplicating validation and business rules in the client is wasted effort, and why hypermedia is still the simplest way to communicate what a user can do next. We also unpack the “send strings to the browser” philosophy and how that changes performance, complexity, and even team collaboration.Real-time is where it gets spicy. Delaney makes the case for Server-Sent Events (SSE) over WebSockets for many apps, leaning on normal HTTP semantics, built-in reconnects, and streaming compression to ship tiny DOM diffs efficiently. From there we talk CQRS as a mental model for command intent vs view updates, plus what this means for Ruby on Rails developers weighing Hotwire, Stimulus, and upgrades. We close with two bold companion projects: Rocket, which makes Web Components more declarative, and Stellar, a Tailwind alternative that uses parametric CSS variables for a modern design system workflow.If you enjoy deep technical takes on reactive UI, server-driven rendering, SSE, Rails, and modern CSS, subscribe, share the episode with a friend who’s stuck in SPA fatigue, and leave a review with the part you disagreed with most.Send us some love. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

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. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.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. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.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. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

What makes a small Ruby conference feel electric instead of ordinary? We unpack the craft behind Blue Ridge Ruby—why we chose a newly renovated, accessible venue, how a single-track format keeps the room together, and the little details that turn a meetup into a memory. From open lunches across Asheville to surprise sponsor moments, we share the thinking that goes into designing an event that celebrates Ruby, supports new speakers, and still feels human-scale.Jeremy breaks down the CFP playbook: write clear abstracts with specific outcomes, submit widely, and rehearse before acceptance so you’re not rushing at the end. With only ten talk slots, curation is both art and constraint. We talk honestly about the selection process, why “no” often means “not now,” and how meetups can incubate a 10-minute idea into a conference-ready talk. We also explore the real costs—venues, video, capacity—and why accessibility drove the move to the YMI Cultural Center.Then we zoom out to the work behind the work: choosing bounded risk to stay motivated, planning sustainable volunteer roles, and creating a container that invites the community to bring their best. On the engineering front, we share how voice-first AI workflows changed our Rails practice. Whisperflow plus LLMs accelerate iteration when conventions set guardrails. We describe using diverge–converge patterns to try multiple implementations, keeping architectural intent while rejecting unnecessary complexity. AI is the nail gun; we’re still the builders who decide what the house should be.Want to be part of it? The CFP is open, sponsors are welcome, and volunteers make the magic real. Subscribe, share this episode with a Ruby friend, and drop us a review—then send your proposal or reach out about helping in Asheville at BlueRidgeRuby.com.Send us some love. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

What if AI could make your work more creative instead of more crowded? We sit down with Scott Werner to unpack a practical path for Ruby developers who want the leverage of AI without sacrificing taste, clarity, or joy. From agentic coding with Claude Code to context-rich tools like Tidewave, we walk through how better inputs—logs, DOM access, database state—turn generic suggestions into usable plans that reduce cognitive load and speed up real problem solving.Scott shares the origin story of Artificial Ruby, a New York meetup that started as a casual happy hour and became a monthly mini conference. That community energy matters: many devs began their careers remotely and missed the spark of live conversations. By focusing on play and curiosity, the group channels the early Ruby vibe—ship small experiments, trade sharp feedback, and rediscover the fun of making software together. That ethos powers Scott’s projects: Monkey’s Paw, a prompt-based web framework that leans into expressive generation, and Latent Library, a hallucinatory book explorer that asks what new interfaces AI enables.We also tackle the “slop generator” problem and how to curb it. Different models have different tendencies, so route tasks where they fit: broad ideation to one, surgical changes to another. Constrain edits, ask for reasoning before code, and hand the model real context so it can propose focused steps. The same philosophy informs testing with computer-use models: if an agent can’t find your logout or complete checkout by looking at the UI, maybe your users struggle too. Rather than replacing developers, these tools elevate the craft—pushing commodity work downward while widening the canvas for design, problem framing, and tasteful implementation.Want more? Check out ArtificialRuby.ai for upcoming events and videos, explore LatentLibrary.xyz, and find Scott’s essays and tutorials at WorksOnMyMachine.ai. If this conversation helps you rethink your workflow, follow, share with a teammate, and leave a review so more builders can join the experiment.Send us some love. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

In this episode of C4, Andrew Mason and Rachael Wright-Munn join Drew to unpack recent controversies surrounding Ruby Central and its alleged takeover of Ruby Gems and Bundler. The trio delves into the timeline of events, conflicting narratives, communication failures, and the underlying security concerns. They address theories and facts, scrutinize the governance of Ruby Central, and discuss the implications for the Ruby community. The episode emphasizes the importance of asking questions and seeking clarity, while advocating for a balanced and constructive approach to resolving the community's issues.Sources discussed*:Ellen's first post on the RubyGems controversy  A board member's perspective on the RubyGems controversyAn Update From Ruby Central (Video)Investigation (allegedly) reveals Shopify manipulated Ruby Central to force takeover of Bundler and RubyGemsStrengthening the Stewardship of RubyGems and BundlerMartin Emde's post on Bluesky Reddit post for "An update from Ruby Central"  Bundler Policies on GitHub  Ruby Central "About" page  Advocacy for Reduced Rails Usage  Alpha-Omega ProjectOrganization & Structure of Open Source Software Development Initiatives - Cyberlaw ClinicRuby Central News Post: Alpha-Omega supportStepSecurity: npm supply chain compromiseSocket: npm supply chain attackPalo Alto Networks Unit 42: npm supply chain attack* Some sources include unverified information being presented as fact. Read with caution.Send us some love. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

Ruby core team member Aaron Patterson (tenderlove) takes us deep into the cutting edge of Ruby's performance frontier in this technical exploration of how one of the world's most beloved programming languages continues to evolve.At Shopify, Aaron works on two transformative projects: ZJIT, a method-based JIT compiler that builds on YJIT's success by optimizing register allocation to reduce memory spills, and enhanced Ractor support to enable true CPU parallelism in Ruby applications. He explains the fundamental differences between these approaches - ZJIT makes single CPU utilization more efficient, while Ractors allow Ruby code to run across multiple CPUs simultaneously.The conversation reveals how real business needs drive language development. Shopify's production workloads unpredictably alternate between CPU-bound and IO-bound tasks, creating resource utilization challenges. Aaron's team aims to build auto-scaling web server infrastructure using Ractors that can dynamically adjust to workload characteristics - potentially revolutionizing how Ruby applications handle variable traffic patterns.For developers interested in contributing to Rails, Aaron offers practical advice: start reading the source code, understand the architecture, and look for ways to improve it. He shares insights on the challenges of making Rails Ractor-safe, particularly around passing lambdas between Ractors while maintaining memory safety.The episode concludes with a delightful tangent into Aaron's latest hardware project - building a color temperature sensor for camera calibration that combines his photography hobby with his programming expertise. True to form, even his leisure activities inevitably transform into coding projects.Whether you're a seasoned Ruby developer or simply curious about language design and performance optimization, Aaron's unique blend of deep technical knowledge and playful enthusiasm makes this an engaging journey through Ruby's exciting future.Send us some love. HoneybadgerHoneybadger delivers best-in-class error tracking, intelligent logging, and Just Enough APM™. JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show