How AI Actually Changes Rails Development
The Gap Between Demo and Reality
Every week there’s a new demo showing AI writing a full application from a single prompt. A todo app. A blog. A CRUD scaffold with authentication. The demos are real. They’re also irrelevant to the work most of us actually do.
Professional Rails development isn’t greenfield CRUD. It’s navigating a 200,000-line codebase with eight years of business logic baked into callbacks, service objects, and query scopes that nobody documented. It’s understanding why that before_action exists, what breaks if you change the serialization format, and which of the fourteen gems touching authentication actually controls the login flow.
AI doesn’t know any of that. Not on its own.
What AI does extraordinarily well is accelerate the work of someone who already understands the terrain. Hand a senior developer an AI coding assistant and they’ll move measurably faster — not because the AI writes better code than they do, but because it eliminates the mechanical friction that eats hours every week. Boilerplate. Lookup. Syntax they haven’t used in six months. The third test case for an edge condition they already identified.
Hand that same tool to someone who doesn’t understand Rails conventions, ActiveRecord pitfalls, or the architectural decisions embedded in the codebase, and they’ll produce code faster too. It’ll just be the wrong code, delivered with confidence.
This is the core reality that the hype cycle skips over: AI amplifies whatever you bring to it. Expertise or ignorance, speed or recklessness. The tool doesn’t care. It’s a multiplier, and multipliers work in both directions.
Where AI Genuinely Accelerates Rails Work
I use Claude Code daily on client projects. Not as a novelty — as a core part of my workflow. Here’s where it actually delivers value across the development lifecycle.
Exploration and Planning
The highest-leverage use of AI in Rails work isn’t writing code. It’s understanding code.
When I pick up a new client codebase, I point Claude Code at the project and start asking questions. How is authentication implemented? Walk me through a request from this controller action to the database. What gems are handling background jobs, and how are they configured? Which models have the most coupling?
Work that used to take days of manual exploration — tracing through initializers, reading gem source code, mapping model associations — now takes hours. The AI doesn’t replace the judgment about what matters. It replaces the mechanical work of finding and reading the code. I still decide what questions to ask. The answers come faster.
For planning, AI is excellent at identifying risk areas before you start building. Describe the feature you’re considering and ask what parts of the existing codebase it’ll touch. You’ll get a dependency map in minutes that would take an experienced developer an afternoon to build manually.
Implementation
This is where most people start, and where AI is simultaneously most useful and most dangerous. The useful part: boilerplate generation is essentially solved. Migrations, serializers, form objects, service class skeletons, Stimulus controllers — anything with a predictable structure, AI handles well. I treat Claude Code as a pairing partner. I describe the intent, review what it produces, and course-correct. The feedback loop is tight.
The dangerous part is trusting implementation output without reviewing it. More on that later.
Where implementation assistance really shines is the middle-complexity work. Not the trivial stuff you could type in your sleep, and not the hard architectural decisions that require deep context. The in-between: “write a concern that handles soft deletion with these specific scoping rules” or “build the Sidekiq job that processes this CSV import with these error handling requirements.” Give the AI enough context about your conventions and constraints, and it produces solid first drafts that need light editing rather than rewrites.
Testing
Test generation is one of AI’s strongest practical applications in Rails. Describe a class and its expected behavior, and you’ll get comprehensive test scaffolding in seconds. More importantly, AI is good at identifying edge cases you might not think of. Ask it to review a method and suggest test cases, and it’ll often surface boundary conditions and error paths that would have been your next production bug.
I routinely use AI to fill coverage gaps. Point it at an untested model or service object, give it the business context, and let it generate the test file. Then review, adjust for your testing conventions, and run. It won’t catch every meaningful scenario — you still need to think about what matters for the business — but it handles the structural work.
Tip: A concrete Claude Code workflow that saves me hours: after implementing a feature, I ask Claude Code to review the diff and write tests for every code path I changed. It catches the test cases I’d have written plus two or three I wouldn’t have thought to add. I review, adjust, and commit. What used to be an hour of test writing becomes fifteen minutes of test reviewing.
Debugging and Refactoring
When a bug spans multiple layers — a controller action that calls a service object that triggers a callback that enqueues a job that fails silently — AI is excellent at tracing the chain. Paste the error, point it at the relevant files, and ask it to trace the execution path. It’ll identify the likely failure point faster than stepping through with a debugger in many cases.
For refactoring, AI handles the mechanical transformations well. Extract this method. Convert this controller to use a form object. Replace these raw SQL fragments with Arel. The structural patterns are predictable, and AI executes them reliably. The judgment about what to refactor and why still requires a human who understands the codebase and the team’s priorities.
Documentation
This is the task every developer skips and AI makes painless. After building a feature, I ask Claude Code to generate documentation based on the code it just helped me write. It produces clear, accurate descriptions of what the code does, how to use it, and what the important edge cases are. I edit for voice and accuracy, but the heavy lifting is done.
Internal API documentation, README sections, inline comments for complex logic, onboarding guides for specific subsystems — all of this goes from “we should really write that someday” to “done in twenty minutes.” The barrier was never skill. It was tedium. AI removes the tedium.
The Prompt Gap
There’s a meaningful difference between how experienced and inexperienced developers use AI, and it shows up clearly in the prompts they write.
Naive prompt: “Implement Google CAPTCHA on the login form.” Experienced prompt: “What are the best approaches to prevent bot traffic and credential stuffing on our authentication endpoints? Consider rate limiting, CAPTCHA options, and device fingerprinting. What are the tradeoffs of each?”
The naive prompt gets you a specific implementation. The experienced prompt gets you an architectural discussion that leads to a better decision.
Naive prompt: “Add caching to this endpoint.” Experienced prompt: “This endpoint is slow under load. Here’s the query plan and the request profile from New Relic. What are the bottleneck candidates, and what are the tradeoffs between query optimization, fragment caching, and Russian doll caching for this specific access pattern?”
The pattern isn’t about prompt engineering tricks. It’s about knowing enough to ask the right question. An experienced developer frames the problem in terms of constraints and tradeoffs. An inexperienced one frames it in terms of a solution they’ve already picked. The AI will happily execute either request. Only one leads to good outcomes.
Where AI Makes Things Worse
This is the section that matters most, and the one that AI evangelists skip.
Plausible-Looking Code That Hides Subtle Bugs
AI-generated code compiles, passes a quick visual review, and often even passes basic tests. It looks right. That’s exactly what makes it dangerous. Plausible-looking code is harder to catch than obviously broken code, because it doesn’t trigger the alarm bells that a syntax error or a failed test does.
I’ve seen AI produce ActiveRecord queries that work correctly on small datasets but generate catastrophic N+1 patterns at scale. Callback chains that create subtle ordering dependencies. Serialization logic that silently drops edge-case data. Service objects that handle the happy path elegantly and swallow every exception in the sad path.
These bugs don’t surface in development. They surface in production, under load, with real data, at 2 AM. An experienced reviewer catches them because they’ve seen the patterns before. An inexperienced one ships them because the tests pass.
AI Doesn’t Understand Your Business
AI has no knowledge of your deployment constraints, your team’s conventions, your compliance requirements, or the business rules that live in your product manager’s head. It doesn’t know that your payment processing has to be idempotent because of a specific incident last year. It doesn’t know that your multi-tenant architecture requires scoping every query to the current account. It doesn’t know that your team uses form objects instead of strong parameters because of a decision made three years ago that half the codebase depends on.
Without that context, AI generates code that is technically correct and practically wrong. It works in isolation and breaks in your system.
The “Replace the Team” Pattern
This is the pattern I see most often from non-technical leadership, and it’s the most damaging. The logic seems sound on the surface: AI can write code, developers are expensive, therefore we need fewer developers. Or worse: we can hire junior developers and let AI make up the difference.
AI is a fantastic tool — so is a scalpel and a hammer — but hiring a carpenter to do surgery ends in disaster.
The teams that try to replace experienced engineers with AI-assisted junior developers don’t see the problems immediately. The first few months look productive. Features ship. Code gets merged. Then the compound interest kicks in. Performance degrades. Bugs get harder to trace. The architecture drifts in three directions at once because nobody on the team has the experience to maintain coherence. Six months later, you’re hiring senior engineers at a premium to untangle the mess — and they’re starting from a worse position than if you’d kept the experienced team in the first place.
Technical Debt Compounds Silently
AI-generated code that isn’t evaluated by experienced eyes accumulates technical debt at an accelerated rate. Not because AI writes bad code — it often writes perfectly acceptable code in isolation. But acceptable code without architectural awareness becomes debt. Every “it works” merge that ignores convention, performance, or maintainability makes the next change harder.
Note: Warning signs that AI-generated code is accumulating debt in your codebase: increasing time to implement features that should be simple, tests that are brittle and break on unrelated changes, multiple conflicting patterns for the same type of problem, and performance regressions that nobody can trace to a specific change. If your team is shipping faster but your codebase is getting harder to work in, the multiplier is working against you.
The Multiplier Effect
Here’s the thesis, stated plainly.
A senior architect using AI delivers dramatically faster than the same architect without it. The AI handles the mechanical work — boilerplate, lookup, test scaffolding, documentation — while the architect focuses on the decisions that actually matter: architecture, tradeoffs, system design, and the business context that no model has access to. This is the multiplier effect working in your favor. The architect’s expertise is amplified, not replaced. The quality stays high. The velocity increases.
In practice, that looks like a senior developer completing a feature branch in two days that would have taken four — not because the AI wrote it all, but because the feedback loop is tighter. The developer spots a problematic suggestion immediately, corrects course with a more specific prompt, and gets back a refined result in seconds. Each iteration is short because the developer knows what good looks like. They reject bad output fast. They accept good output and move on. The AI never sends them down a dead end for long, because they recognize dead ends.
An inexperienced developer using AI has the opposite feedback loop. They can’t distinguish a good suggestion from a plausible one, so they accept more bad output. When something doesn’t work, they don’t know whether to adjust the prompt, rethink the approach, or question the AI’s assumption — so they try all three, often making things worse. Every plausible-looking method that ignores a convention, every query that performs well on ten rows but falls apart at ten thousand, every service object that handles the happy path and nothing else — it all compounds. The multiplier effect works in both directions.
This isn’t an argument against AI. It’s an argument for expertise. AI amplifies expertise, not replaces it. The organizations getting the most value from AI in their Rails development are the ones that put the tools in the hands of their most experienced people, not the ones trying to use AI as a substitute for experience.
The question isn’t whether to adopt AI in your development workflow. That’s settled. The question is whether you have the experienced judgment to direct it well. The tool is neutral. The results depend entirely on who’s holding it.
Where This Leaves You
If you’re a technical leader evaluating how AI fits into your team’s workflow, the framework is straightforward: invest in the expertise first. AI makes your best people better. It doesn’t make inexperienced people experienced. The returns on AI tooling are directly proportional to the skill of the people using it.
If your team is figuring out where AI fits in your development workflow — or cleaning up after an experiment that went sideways — that’s the kind of problem I help solve. Not selling AI tools or hype. Practical integration into real Rails development, guided by someone who uses these tools on production codebases every day.
Note: Want to talk through how AI fits into your team’s Rails workflow? Get in touch — I’m happy to share what’s working on real projects.