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
Services / Agent-assisted engineeringAgent-assisted Rails
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.
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.
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
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
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
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.
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
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
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.
- 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.
- 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.
- 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.
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