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

Cris Joseph — Mon, 23 Mar 2026 04:43:46 +0000

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")

→ 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")

→ 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")

→ 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")

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

Static context files (~150 lines)
Loaded at session start — zero cost mental map
Conditional rules (.cursor/rules/)
Loaded only when relevant (model, controller, view, etc.)
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.

DEV Community: Cris Joseph