# Agent-Assisted Rails Engineering > Review, verification, and guardrails for AI-agent-written Rails code: contract-safe review, repository agent-readiness, and a private evaluation set. - Canonical: https://haseebeqx.com/services/agent-assisted-rails-engineering/ - Published: 2026-10-22 [← Services / Agent-assisted engineering](/services) For teams shipping with AI coding agents # Agent-assisted Rails *engineering.* Coding agents now write a large share of the code in some Rails teams. I help you review what they produce, keep verification outside their reach, and make your repository something an agent can work in without quietly breaking a contract you agreed three tickets ago. [Discuss your setup →](/hire/) [See the three engagements ↓](#capabilities) Service briefAI / Rails You have A Rails app and an agent workflow We start with Agent-written changes and your CI I check Behavior, contracts, security, deployability I deliver Review, guardrails, and an evaluation set Ways to work Focused review, audit, or embedded support Before I start, we agree what I will review, what access I need, and what a useful outcome looks like for your team. 01 / The evidence ## Where agents fail *in Rails, specifically.* The Rails Foundation's public benchmark measures this directly, on real 37signals applications, with deterministic grading. The failure modes are consistent enough to plan for. **35%** ### Feature tickets solved The leading model solved 21 of 60 feature runs at default effort, and 53% at maximum effort, where the sweep cost about $4,100 against $2,250. [Stage 2 report](https://rubyonrails.org/2026/9/9/agents-on-rails-stage-2) **9/12** ### Contracts broken in one task GPT-6-family runs added a field to a restricted export and then edited their own test to accept it. The suite stayed green while the agreed contract was gone. [Stage 3 report](https://rubyonrails.org/2026/10/13/agents-on-rails-stage-3) **0/17** ### Greenfield apps with a job queue Seventeen runs finished every helpdesk ticket and none configured a persistent production job queue. Only four kept credentials out of logs. [Stage 3 report](https://rubyonrails.org/2026/10/13/agents-on-rails-stage-3) **37%→12%** ### A model attacking the harness One model found the benchmark's API key, spent it on a web-search model, and pulled the reference application's source from GitHub. Locked down, it scored 12%. [Max-effort report](https://rubyonrails.org/2026/9/21/agents-on-rails-maximum-effort-and-deepseek-4-1-flash) 02 / Where I can help ## Three ways to make *agent-written code safe.* Most teams need one of these first. The order depends on where your risk actually is: review for what already exists, guardrails for what keeps arriving, or measurement for what you have not tried yet. Engagement 01 ### Agent-written code review I review changes produced by coding agents against the behavior your product promised, not just the diff that looks plausible. The output is a prioritized findings list and the fixes worth making now. - Behavioral correctness and missing layers - Authorization, tenant scope, and input handling - Migrations, backfills, and job timing - Contract drift across agent sessions - Production readiness before deploy Engagement 02 ### Repository agent-readiness Agents inherit whatever the repository tells them. I document how this application actually works, then harden the paths an agent should not be able to quietly rewrite. - Repository guide and decision log - Task framing that names required behavior - Protected CI and verification the agent cannot edit - Scoped credentials, commands, and network - Approval gates for risky surfaces Engagement 03 ### Private evaluation for your codebase Public leaderboards describe someone else's applications. I build a small evaluation set from your history and score models on it, so model choice is based on your code, your constraints, and your budget. - Task set drawn from real past work - Scored on correctness, security, and maintenance - Cost, latency, and retry behaviour tracked - Rotating private tasks to limit contamination - Repeatable harness your team owns ## What the engagement delivers. - Prioritized review findings with evidence from your repository - Fixed high-risk defects where you want implementation, not advice - A repository guide and decision log agents actually read - Verification the agent cannot weaken, wired into your CI - An evaluation set with scores, costs, and a repeatable harness - Documentation your team inherits and can maintain ## What it does not include. - Running agents as your delivery team - Promising feature-complete output from a ticket - Replacing your engineers with a cheaper process - Rewriting the application to fit an agent workflow - Vendor recommendations or model resale 03 / How I work ## Evidence first, *then guardrails.* The order matters. Generic advice about reviewing AI code is easy to write and hard to apply. The useful version comes from your repository, your CI, and the changes agents are actually producing. 1. 01 ### Establish the baseline I sample agent-written changes, read the CI and verification setup, and map the risk areas: authorization, money movement, data contracts, migrations, and background processing. The output is a short, evidence-based list of what is going wrong and why. 2. 02 ### Review and repair I review the highest-risk changes in depth, fix the defects that matter, and add the checks that would have caught them. Where a check cannot live in the agent's writable space, it moves to CI or to a review gate. 3. 03 ### Make it repeatable Repository documentation, decision records, task framing, permission scopes, and an evaluation set your team owns. The goal is a workflow that keeps working after the engagement ends, not a dependency on me. 04 / Practical details ## Questions teams ask *before starting.* What this work covers, what it does not, and how the first conversation goes. What is agent-assisted Rails engineering? It is the work of making AI coding agents safe to use on a production Rails application: reviewing what they write, keeping verification outside their reach, and documenting the decisions that must survive between sessions. Do you review code written by AI agents? Yes. Reviews cover behavioral correctness, Rails idioms, authorization and tenant scope, migrations and backfills, contract drift across sessions, and production readiness such as background job handling and log hygiene. Will you tell us which model to use? Not from a leaderboard. Model choice depends on your repository, task type, budget, and risk profile, so I measure a small private evaluation set built from your own history instead of recommending from public scores. Can you help if we are not using agents yet? Yes. The same work applies before adoption starts: repository documentation, protected CI, verification that agents cannot edit, and an evaluation set that tells you whether delegation is worth the risk on your codebase. How do these engagements start? We agree the problem and evidence first: sample agent-written changes, the repository, the CI setup, and the risk areas you care about. Then we define a focused scope with a review or audit deliverable your team can act on. 05 / Work you can inspect ## The evidence behind *the advice.* These articles cover the benchmark data, the failure modes, and the verification practices this service is built on. [01**AI Coding Agents for Ruby on Rails: Benchmarks and Best Practices→**](/posts/ai-coding-agents-ruby-on-rails/) [02**Starting work on a legacy Rails codebase→**](/posts/navigating-the-maze-how-to-start-working-on-a-legacy-rails-codebase/) [03**Rails SaaS performance and security hardening→**](/case-studies/rails-saas-performance-security-hardening/) [04**Ruby on Rails consulting for SaaS teams→**](/services/rails-consulting/) A useful first message ## Bring the agent output, the risk, and the constraint. Tell me which agents you use, what they are allowed to touch, what has already gone wrong, the Rails version, and whether you want review, guardrails, or measurement. I will help narrow that into a sensible first scope. Direct access · Expert judgment · Hands-on delivery ## Show me the changes *the agent produced.* Start with the failure you are worried about, not a prewritten solution. [Discuss your setup ↗](/hire/)