AI Code Review for Ruby and Rails

Why Rails legacy codebases are hard to audit

Rails applications age differently from other codebases. The framework's convention-over-configuration philosophy means that critical behaviour is often implicit rather than explicit. A before_save callback in a model can trigger a chain of side effects – updating related records, enqueuing background jobs, sending notifications – none of which are visible from the controller that initiated the save. Tracing the actual execution path of a single user action can require reading a dozen files across models, concerns, services, and jobs.

Metaprogramming compounds the problem. Ruby's method_missing, define_method, and class_eval let developers create methods at runtime that do not appear in any source file. A grep for a method name returns nothing, but the method exists and is called throughout the application. Understanding what the code actually does requires reasoning about what it generates, not just what it contains.

Gem dependency rot is a slow-burning risk in long-lived Rails applications. A Gemfile with 80 or 100 dependencies often includes gems whose maintainers have moved on, gems with known CVEs, and gems that duplicate functionality now built into Rails itself. Bundler-audit catches known vulnerabilities, but it cannot assess whether a gem is abandoned or whether upgrading it would break dependent code across the application.

What RuboCop and Brakeman miss

RuboCop enforces style and catches surface-level code smells. Brakeman scans for known security vulnerability patterns. Both tools are valuable, but they operate on pattern matching within individual files and cannot reason about cross-file architectural debt.

Consider a Rails application where business logic has drifted across layers. Some order calculations live in the model, others in a service object, and a few validations happen in the controller. RuboCop can flag a method that is too long, but it cannot detect that pricing logic is scattered across three layers with no single source of truth. Finding that inconsistency requires reading the entire application.

ActiveRecord N+1 queries are another persistent blind spot. The bullet gem catches some cases in development, but only when those specific code paths are exercised during manual testing. Queries that involve complex scopes, conditional includes, or nested associations often slip through. Identifying them requires tracing how query results are used in views and serialisers – a cross-file concern that per-file tools do not address.

Rails upgrade debt is similarly invisible to linting tools. A codebase migrating from Rails 5 to Rails 7 often contains deprecated callback behaviours, removed configuration options, and APIs that still work but will break in the next major version. These deprecations are logged at runtime but not surfaced during static analysis.

How VibeRails reviews Ruby and Rails projects

VibeRails performs a full-codebase scan using frontier large language models. Every Ruby file, ERB template, configuration file, migration, and Gemfile is analysed – not just recent diffs, but the entire application including tests, initializers, and rake tasks.

For Ruby and Rails code specifically, the AI reasons about:

• Callback chains – hidden side effects from before_save, after_commit, and around_action chains that create implicit coupling between models, jobs, and services
• Metaprogramming – dynamic method definitions via define_method, method_missing, and class_eval that obscure control flow and make grepping unreliable
• Gem dependency health – outdated gems with known CVEs, abandoned gems with no recent releases, gems that duplicate built-in Rails functionality
• ActiveRecord patterns – N+1 query paths through nested associations, complex scopes that defeat eager loading, raw SQL escape hatches that bypass the query interface
• Business logic sprawl – domain logic scattered across models, controllers, and service objects with no clear ownership boundaries
• Rails upgrade debt – deprecated APIs, removed configuration options, callback behaviour changes between Rails versions

Each finding includes the file path, line range, severity level, category, and a description with suggested remediation. The structured output turns an opaque Rails monolith into an organised inventory of improvements prioritised by risk.

Dual-model verification for Ruby

Ruby's expressiveness creates genuine ambiguity for automated review. Is that method_missing override an intentional DSL builder, or a debugging hack that was never cleaned up? Is the fat model a deliberate Active Record pattern choice, or the result of years of unplanned growth?

VibeRails supports running reviews with two different AI backends – Claude Code and Codex CLI – in sequence. The first pass discovers issues, the second verifies them using a different model architecture. When both models independently flag the same callback chain or N+1 query, confidence is high. Disagreements highlight areas where human judgement during triage adds the most value.

From findings to fixes

After triaging findings, VibeRails can dispatch AI agents to implement fixes directly in your local repository. For Rails projects, this typically means extracting callbacks into explicit service objects, adding eager loading to N+1 query paths, replacing deprecated API calls with their modern equivalents, and removing unused gems from the Gemfile.

Each fix is generated as a local code change you can inspect, test, and commit or discard. The AI works within the conventions of the existing codebase, matching the application's naming patterns, test framework, and directory structure.

VibeRails runs as a desktop app with a BYOK model – it orchestrates Claude Code or Codex CLI installations you already have. No code is uploaded to VibeRails servers. AI analysis is sent directly to the provider you configured, billed to your existing subscription. Each licence covers one developer: $19/month or $299 lifetime. The free tier includes 5 issues per session to evaluate the workflow.