Note: Rails Baseline is the production-ready Rails foundation I tested here. It gives a new SaaS application and the coding agents working in it clear, conventional patterns to build from.
Instead of spending another week adding starter features I thought somebody might need, I took the actual packaged ZIP, opened it as if I had just bought it, and handed it to fresh coding-agent sessions.
I did not tell them to use Pundit. I did not say to scope records through the current account, use public IDs, put paid access behind Entitlements, or use Solid Queue for background work. Those were all patterns already in the repository, and I wanted to see if the agent would find them without the prompt turning into an architecture checklist.
That sentence is intentionally boring. I was not trying to figure out which model could win a Rails benchmark. I wanted to test the codebase.
Rails Baseline is a normal Rails application, but part of the reason I built it was for coding agents.
I have spent years building SaaS apps and eventually wrote Build A SaaS App in Ruby on Rails 8. A lot of the hard-won stuff from doing that is not a particular controller action or gem install. It is knowing where certain decisions belong and trying not to make a different version of the same decision six months later.
Coding agents make this more obvious because they can produce so much code so quickly.
If the repository has a good pattern, the agent can usually find and continue it. If the repository is silent, the agent still has to build something. At that point it either asks, guesses, or follows whatever general Rails pattern seems reasonable from training.
A starter that claims to work well with agents should probably be tested by giving an agent incomplete product instructions and seeing what happens.
The first test started from the RC1 release ZIP, outside the Rails Baseline source repository. I onboarded it as a new application and gave a fresh Claude session a prompt to build a small feedback board product.
The basic product was pretty normal SaaS stuff. Accounts could create boards, anonymous visitors could leave feedback, feedback had statuses, and plan limits changed how many boards an account could have. Paid accounts also got a CSV export.
I did not say something like: Use Current.account for tenancy. Use Pundit for authorization. Use Entitlements.enabled? for paid capabilities. Use Limits.value for board counts. Use HasPublicId for URLs.
The more interesting question was whether Claude would inspect the app and reach those conclusions itself.
The board records were account-owned. Authorization followed the existing policy shape. The free and paid board counts went through the application's plan-limit boundary instead of being scattered through controllers. The paid CSV feature used the entitlement layer. Public URLs followed the existing public-ID convention.
There was also a policy-scope mistake during the build. Claude caught it and fixed it during its own pass.
Good. That is much closer to what I actually want from an agent session than a first pass that looks impressive but quietly breaks account isolation.
It would have been easy to react by adding Active Storage, S3 setup, an Export model, and some generic file-delivery service to the starter. That felt like exactly the kind of thing I did not want Baseline to become.
A lot of products do need durable generated files. Plenty do not. A CSV that can be generated quickly and downloaded immediately may not need to be stored at all.