DEV Community

Cris Joseph
Cris Joseph

Posted on

After 10 Years of Rails, Here's What AI Coding Agents Get Wrong (and How I Fixed It)

I’ve been writing Rails for ~10 years.
I started using AI coding agents (Claude Code, Cursor) daily last year.

And I kept hitting the same wall:

The agent can read files, but it doesn’t understand the app.

It sees schema.rb, but not constraints.
It sees controllers, but not inherited filters.
It sees models, but not concerns, optional associations, or runtime behavior.

Rails is convention over configuration - which means the real structure of the app is emergent at runtime, not visible in any single file.

So I built rails-ai-context.


What rails-ai-context does

Instead of dumping more files into the context window, it gives AI agents a structured, queryable introspection layer via MCP.

Examples:

Schema (real schema, not just schema.rb)

rails_get_schema(table: "users")
Enter fullscreen mode Exit fullscreen mode

→ columns, types, NOT NULL
→ defaults
→ indexes
→ foreign keys

Pulled from the live DB when available, with a smart schema.rb fallback.


Models (with concerns expanded)

rails_get_model_details(model: "Cook")
Enter fullscreen mode Exit fullscreen mode

→ associations (including optional: true)
→ validations
→ scopes
→ callbacks
→ concern methods shown inline
  PlanLimitable → can_cook?, limits


Controllers (actual execution path)

rails_get_controllers(controller: "cooks", action: "create")
Enter fullscreen mode Exit fullscreen mode

→ source of that one action only
→ inherited before_actions across the controller hierarchy
→ strong params body

No guessing. No missing filters.


Semantic validation (Rails-aware)

rails_validate(files: [...], level: "rails")
Enter fullscreen mode Exit fullscreen mode

Catches things static linters miss:

  • Non-existent columns
  • Missing partials
  • Broken route helpers
  • Undefined callbacks
  • Missing FK indexes

This is semantic validation, not syntax checking.


The key insight

Rails apps aren’t static.

Their structure is defined by:

  • schema constraints
  • inherited filters
  • concerns
  • association options
  • runtime reflection

AI agents don’t need more files.

They need a structured query layer that mirrors how Rails itself understands the app.


Architecture (high-level)

29 introspectors → 13 read-only MCP tools + static context

Three-layer progressive disclosure

  1. Static context files (~150 lines)
    Loaded at session start — zero cost mental map

  2. Conditional rules (.cursor/rules/)
    Loaded only when relevant (model, controller, view, etc.)

  3. Live MCP tools
    Queried on demand with:
    summary → standard → full detail levels


Results

  • 37% fewer tokens on a real production app
  • First-attempt success rate

    • Before: ~50%
    • After: ~90%

But the real win is accuracy, not token savings.


Technical notes (for the curious)

  • Built on the official MCP Ruby SDK (not a custom protocol)
  • All tools are read-only and annotated
  • Sensitive files auto-blocked: .env, master.key, credentials
  • ERB validation:

    • Compiles ERB → Ruby
    • Then syntax-checks the result
    • Catches missing <% end %> that ERB.new.src misses
  • Schema parser:

    • Live DB introspection first
    • Text-based schema.rb fallback
  • Controller filter extraction:

    • Hybrid reflection + source parsing
  • 510 tests

  • MIT license

  • Zero config (3 commands)


Repo

👉 https://github.com/crisnahine/rails-ai-context


If you’re using AI agents seriously on non-trivial Rails apps,
file-reading alone just doesn’t cut it anymore.

This gives them the same mental model you already have.

Top comments (0)