I’ll be honest: I was skeptical. Not in the “I hate AI” way, more in the “I’ve tried enough hype-driven tools to know most of them just shift the frustration around” way. But Claude Code kept showing up in conversations I trusted, so in January I made a deal with myself. Thirty days. Real project. No cherry-picking the easy wins.
This is what actually happened.
The Project
I was working on a mid-size Rails 8 app. A SaaS product with a fairly standard setup: PostgreSQL, Sidekiq for background jobs, some API integrations, a Hotwire frontend. Not a toy project. Real users, real data, things that could break in production.
The codebase had about 40k lines of Ruby. Some legacy corners I hadn’t touched in over a year. The kind of project where you sometimes open a file and just… stare.
Week 1: The Honeymoon Period (and Its Limits)
The first week was genuinely impressive. I pointed Claude Code at some of the more mechanical tasks: writing RSpec tests for existing methods, generating migration files, refactoring repetitive controller code. It handled these really well.
The autocomplete-style suggestions inside the terminal felt different from GitHub Copilot. Claude Code seems more willing to look at broader context, across multiple files, before suggesting something. I had it generate a service object for a complex checkout flow and it actually picked up that we were using a specific currency formatting helper from a concern somewhere in the codebase. Didn’t have to tell it.
But I hit the first wall around day 5. I asked it to help trace a performance issue we’d been seeing in a background job. It gave me a solid analysis of the code I showed it, suggested some improvements, but it couldn’t actually run anything, couldn’t see the real query plans, couldn’t connect the dots between the job and the database behavior. The insight was good. The diagnosis needed me.
Week 2: Where It Actually Saved Me Time
This is where things got interesting. I stopped trying to use Claude Code as a senior dev and started treating it more like a very fast junior who needs clear direction.
The biggest win was documentation and test writing. We had a whole module of financial calculations, some of which had been written by someone who clearly loved one-liners but not comments. I asked Claude Code to read through, explain what each method did in plain English, then generate RSpec examples for each. It did this in maybe 15 minutes. Doing it manually would have taken me a couple of hours minimum
A concrete example:
# Original method (no docs, no tests)
def calculate_proration(amount, days_used, days_in_period)
(amount * (days_used.to_f / days_in_period)).round(2)
end
# Claude Code generated test:
RSpec.describe '#calculate_proration' do
it 'returns correct proration for partial period' do
expect(calculate_proration(100.0, 15, 30)).to eq(50.0)
end
it 'rounds to 2 decimal places' do
expect(calculate_proration(100.0, 10, 30)).to eq(33.33)
end
it 'handles full period' do
expect(calculate_proration(100.0, 30, 30)).to eq(100.0)
end
end
Not revolutionary, but genuinely useful. And it caught an edge case I hadn’t thought about (what happens when days_in_period is 0). I added a guard clause after that conversation.
Week 3: The Frustrations
Let’s talk about the bad stuff, because there was bad stuff.
The context window is real. On a large Rails app, you constantly hit the limit of what Claude Code can hold in mind at once. I’d be deep in a refactor conversation, and then I’d have to re-explain something it seemed to have forgotten about from earlier in the session. This got annoying.
It also occasionally does something I’d call confident wrongness. It’ll suggest an approach that sounds reasonable, uses correct Ruby syntax, but doesn’t account for something specific about your app’s architecture. If you’re junior enough not to catch it, you might ship something subtly broken. This is a real risk and I think it’s undersold in the hype.
One time it suggested adding an index to a table that already had that exact index, just worded differently. Not harmful, but a reminder that it doesn’t actually know your schema, it’s reasoning from what you’ve shown it.
Week 4: Finding the Right Workflow
By week four I’d settled into something that actually worked. Here’s the breakdown:
Tasks where Claude Code genuinely helped:
Writing boilerplate (migrations, serializers, basic CRUD). Generating test cases from existing code. Explaining unfamiliar code or gems. Refactoring specific methods when given clear constraints. Writing first drafts of API documentation.
Tasks where I stopped relying on it:
Debugging production issues. Performance optimization that requires real query plans. Architectural decisions. Anything touching security logic. Code that requires deep knowledge of your specific data model.
The mental model I landed on: Claude Code is a force multiplier for the work you already understand. It’s not a replacement for understanding. When I knew exactly what I wanted but just didn’t want to type it out, it was fantastic. When I was genuinely uncertain about the right approach, it sometimes gave me confident-sounding guidance that I had to sanity check anyway.
The Numbers, Roughly
I didn’t track this scientifically, but my rough estimate: around 20–25% faster on the tasks where it was useful. Test coverage on the financial module went from embarrassing to solid in a couple of sessions. I closed 3 tickets that had been sitting in the backlog for weeks because the friction of “I’ll need to write all those tests” was lower.
One thing I didn’t expect: it made me a better reviewer of my own code. When you’re explaining a problem to Claude Code clearly enough for it to help, you often figure out the answer yourself in the process. Rubber duck debugging, but the duck sometimes responds.
Would I Keep Using It?
Yes. With caveats.
If you’re expecting it to write your app for you, you’ll be disappointed and you’ll ship bugs. If you treat it as a fast, tireless pair programmer who needs direction and fact-checking, it’s genuinely valuable.
The Ruby LSP integration is worth mentioning too. Running Claude Code alongside a solid LSP setup in VS Code or Neovim makes the experience noticeably smoother. Autocomplete, inline docs, go-to-definition, all working together with the AI assistance on top. That combination is the closest thing I’ve felt to actual pair programming with someone who’s always available.
Thirty days in, I’m not going back to working without it. But I’m also not pretending it’s magic. It’s a tool. A good one. Use it like one.
Enjoyed this?
If this saved you some headaches, consider following me on Medium. I write about Ruby, Rails, and JavaScript with a focus on real-world problems and honest takes.