Robby Russell, founder of Planet Argon and creator of the Oh My Zsh framework, published a hands-on guide to using Claude Code in Rails development that cuts through the noise with actual production numbers: his team reduced backtrace debugging from roughly 45 minutes to under 10.
The guide is worth reading for one reason most AI coding content misses: it treats Claude Code as a maintenance tool, not a rewrite button. Russell's team uses it on existing Rails apps, not greenfield projects, and the advice reflects that.
The Model-Switching Workflow
Russell recommends starting every task with Claude Sonnet (the default, faster model) and only escalating to Opus when Sonnet's output needs repeated re-prompting. Sonnet handles the daily grind well: writing tests, generating migrations, boilerplate code, small refactors. Opus earns its keep on harder problems like debugging production stack traces, analyzing legacy code, architecture decisions, and security reviews.
The practical command: /model claude-opus-4-6 switches models mid-session without losing context. Shift+Tab twice enters "plan mode," where Claude reads and reasons through your code without making edits.
Testing and Debugging Patterns
The testing advice is specific to Rails conventions. Point Claude at your existing spec files so it matches your team's style, whether that's RSpec with FactoryBot or Minitest. Then have Claude run the tests immediately after writing them so it can iterate on failures in the same session rather than handing broken specs back to you.
For debugging, Russell's workflow: paste the full stack trace, have Claude read the relevant files first, explain the call chain, then propose a fix. He recommends requesting a regression test before the fix, not after. For error monitoring tools like Sentry or Honeybadger, feed Claude the complete payload rather than summarizing it yourself.
Keep Your CLAUDE.md Under 40 Lines
The configuration advice runs counter to the "stuff everything in CLAUDE.md" approach many teams default to. Russell keeps his project briefing files minimal: what the app does, key commands (bin/dev, test runners), current work-in-progress, and known quirks. Company-wide conventions go in ~/.claude/rules/ with path-scoping frontmatter, so Rails-specific rules only load when working on Rails files.
His team treats the shared rules files like any other code: changes go through pull requests, and the configuration evolves through team discussion rather than one person's preferences.
The most grounded takeaway: run a 2-3 month experiment on a specific pain point, measure the results concretely, and let the numbers decide whether to expand usage. No grand transformation required.